Detlef Müller <detlef_mue/at/web.de>
Yazar hakkında:
Her ne kadar Tux işletim sistemiyle iki yıldan beri çalışıyorsam da İnternet kafede beni 'Linux' diye çağırıyorlar.
Belki bir de BSD kullanmanın zamanı gelmiştir...
Şu anda iş yok, ama ben bir gün bir Linux işi ile uğraşmak istiyorum. Benim için Linux ek iş olmakla birlikte,
aynı zamanda da hobidir.
2004 yılının başından beri benim diğer hobim Attac olmuştur.
Linux'a bu alanda katkıda bulunmak isterim.
İlk çalışmam ...
Vizyonum: İnternet üzerinden herkesin oy kullanmasına olanak sağlayan, tabii ki serbest yazılım araçlarıyla
yazılmış bir e-demokrasi sistemi dir.
Türkçe'ye çeviri:
Erdal Mutlu <erdal(at)linuxfocus.org>
İçerik:
|
Veri kaybı: En kötü durum senaryosu
Özet:
Linux hakkında şimdiye kadar aldığım en önemli karar günlüklü dosya sistemi (journalıng filesystem) kullanmak
olmuştur.
Bu kararın doğruluğu dün çok etkili bir şekilde ispatlandı. Hatalı bir kopyalama işlemi, bir Linux projesinin
yeraldığı
bir diskbölmesini tamamen doldurdu ve böylece diskbölmesini bağlanamaz hale getirdi.
Bu diskbölmesinin biçimi ReiserFS günlüklü dosya sistemi idi.
Linux altında güvenli çalışmayı sağlayan iyi özelliklerden biri, günlük bilgilerine sahip dosya sistemleridir.
Günlüklü dosya sistemleri, bilgisayarın yeniden başlat (reset) tuşuna basıldığında kötü sonuçlara
yol açılmayacağının garantisini vermektedir.
'Bit ve byteların' Linux altındaki profesyonel bir araç olan
'reiserfsck'nın sayesinde mutlu sonla biten kurtuluşunu anlatan, gerçek hayattan olan bu
deneyimin gösterdiği gibi, günlüklü dosya sistemlerinin bile bazen kötü sonuçlar doğurabileceğidir.
_________________ _________________ _________________
|
Linux ile tanışmam
Bilgisayarlarımda Tux yaklaşık iki yıldan beri vardır. Şu anda üç adet penguen bilgisayarımda
yaşamaktadır. Bunlardan ikisi SuSE cinsinden, biri Debian cinsi, ana tarafından Knoppix.
Herşey E-Bay'den aldığım SuSE 7.3 ile başladı. Linux hakkında o kadar çok şey duymuştum ki, artık bir Linux
uzmanı olmaya karar vermiştim. Bu da benim başlama şeklim oldu.
Çaylak olarak yaşadığım sorunlar ...
İlk adımla kesinlikle kolay olmadı. Sık sık ve genellikle açıklaması yapılmamış bir sürü yeni teknik terimlerle
boğuşmak zorunda kaldım.
Almanca Linux dağıtıcısının belgelerindeki ilk satırları okumaya başlar başlamaz, KDE, YaST, Bash vs
bir sürü terim karşınıza çıkmaktadır. Daha önceleri isim yapmış bir bilgisayar dergisi, bu dağıtımın
en iyi belgelere sahip olduğunu yazmıştı. Faydası yok, hiçbir şey göründüğü kadar basit değildir.
Herneyse, konumuza kaldığımız yerden devam edelim.
EISA 486 üzerinde ReiserFS
Bu SuSE 7.3 EISA veriyolu olan bir 486 bilgisayar üzerinde geldi (Evet, böyle şeyler hala var.)
İlk yeniden başlatma tuşuna basmanın ardından gelen sorunlar ortaya çıkmaya başladı.
Dosya sistemine olan erişim yok ve diske sadece okunabilir kipte erişim sağlanabiliyordu.
'Bunun anlamı ne olmalıydı?'
Anlamı bir sürü iş demektir. Onarım denemeleri sonuç vermedi ve ben sonunda tüm SuSE'yi baştan yükledim.
Bu 5 veya 6 defa devam etti. SuSE'nin kurtarma sistemiyle bilgisayarı her başlattığımda, e2fsck ile ext2
dosya sistemlerini tamir ettim, bir defasında sefil vi metin işlemcisiyle /etc/fstab dosyasında
değişiklik bile yaptım. Daha sonra dosya sistemi düzeldi veya belkide düzelmedi. Sonunda Linux'u yeniden
yükledim. Bu aşamada bir gün geçti gitti bile. Böyle uğraşlar çaylakların çok fazla zamanını almaktadır.
C't dergisinde, YaST ile günlüklü dosya sistemini yükleme üzerine olan bir yazıdan ilham aldım ve yükledim.
Ondan sonra kurtarma sistemiyle bilgisayarı ikide bir açmaktan kurtulmuş oldum.
Eğer, bilgisayar düzgün kapanmamış olursa, sistem açılışınta 'replayed nnn transactions in ...'
gibi iletiler verip, düzgün bir şekilde sistemi başlatmaktaydı.
Harika. Bence böylesi daha iyi. Bundan sonra ext2 yok, artık sadece günlüklü dosya sistemi kullanacağım!
Sistemin açılışında çetele dosyasında görülen ReiserFS'in 'Journal replay' iletileri:
.....
reiserfs: found format "3.6" with standard journal
reiserfs: checking transaction log (sd(8,4)) for (sd(8,4))
reiserfs: replayed 109 transactions in 10 seconds
reiserfs: using ordered data mode
.....
Dayanıklılık deneyi
Ama ben kesin bilmek istiyordum
Günlüklü dosya sistemiyle tanışık olduğumda bir dayanıklılık deneyi yaptım.
Çok sıkı bir deneme tam teşeküllü bir masaüstü çalışırken yeniden başlat tuşuna basarak yapıldı.
KDE'yi birçok program ile birlikte çalıştırdım, metin işlemcisiyle dosyalar açtım ve ondan sonra
yeniden başlat tuşuna bastım. Deney başarı oldu. Dosya sistemi bunu gerçekten başarıyla atlattı.
Kopyalama sırasında bile 'acil çıkış' yapıldığında herhangi bir sorun yaşanmadı.
486 SCSI sistemi birkaç sorun yarattı, ancak ReiserFS verdiği sözü tuttu ve dosya sistemini
kullanabilir tutarlı bir duruma geri getirdi. Açık olan dosyalar tekrar eski durumlarına getirildiler.
Sonraları, ext2'nin günlüklüsü olan ext3 dosya sistemiyle yaptığım deneyler de başarılı oldular
ext3 kullanıldığında sistemin açılışında alınan iletiler çetele dosyasında açağıdaki gibi gözükmekteydi:
.....
Journalled Block Device driver loaded
(recovery.c, 256): journal_recover: JBD: recovery, exit status 0,
recovered transactions 450798 to 451415
(recovery.c, 258): journal_recover: JBD: Replayed 3756 and revoked 6/15 blocks
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal
ext3_orphan_cleanup: deleting unreferenced inode 355953
ext3_orphan_cleanup: deleting unreferenced inode 355952
EXT3-fs: sd(8,1): 2 orphan inodes deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
.....
Diğer günlüklü dosya sistemleri
Bu işin başında olanlardı ...
Ondan sonra ext3 ve XFS dosya sistemlerini de kullandım.
JFS dosya sisteminde henüz yetiri ölçüde güvenli olmadığından uzak durdum. Onun hakkında olumsuz bir
şey söylemiyorum, sadece onu denemedim.
XFS kayboldu. Sorun değil, çünkü onu uzun süreli olarak kullanmadım ve kullandığımda sıralarda da
herhangi bir sorunla karşılaşmamıştım.
ext3 dosya sistemini kullanmaya devam ediyorum. Şu anda Debian (sağlam olmayan) Linux olan 486 makinamda çalışıyor.
ext2 dosya sistemini üzerinde veri bulunduğunda ve de sistem çalışırken ext3 dosya sistemi
haline dönüştürmek olasıdır. Ben denedim ve çalışyor!
Bilgisayarıma Knoppix'in 3.4 sürümünü yüklediğimde yine ext3 kullandım.
Sadece PIII/500 olan kişisel bilgisayarımdaki diskin çoğunu ReiserFS oluşturmaktadır.
Çalışma bilgisayarımın nasıl bölümlendiği aşağıda gösterilmektedir:
2. Resim: SCSI disk olan sda'nın bölmeleri
3. Resim : hda'nın bölmeleri
O gün
Yaklaşık 9 aydır Linux için bir belgelendirme CD üzerine çalışıyorum. Bu işte, nasıl dosyaları, kılavuzlar, sıkça sorulan
sorular, herbir biçin için arşivler ve aynı hacimde güncellemeler gibi büyük hacimli verilerle uğraşmak gerekmektedir.
Ayrıca, CD hakkında genel bir bakış sağlayabilmek için kendim de bazı HTML dosyaları yazıyorum.
Son birkaç haftadır da çok iş vardı. CD'nin parasız sürümü yakında çıkmalıydı. İste, CD'ye yazılacakları biraraya
getirmek için birkaç satırlık betik yazmak, ki bu CD yazımı işi için olan KDE'deki programdan daha hızlıdır,
herşeyi diskime yarleştirmek gibi işlerle uğraşıyordum. Verilerimi 60 GB'lik IDE diskindeki /dev/hda5
bölümüne yerleştirdim. Bu bölme 20 Gb'lik olmasına karşın %80'ninden fazlası dolu durumdaydı. Anlayacağınız,
uzun çalışmanın ürünü olan ve hepsi önemli bit ve byte'lardı. Eğer, bunun başına herhangi bir şey gelecek
olsa ... eee ne de olsa bu Windows'un FATxx dosya sistemi değil.
Yedek alma biçok kez aklıma geldi ama bu güne kadar hiç almamıştım. Ayrı bir diskte birkaç kopyam var ve onları orada
bırakıyordum.
Dün akşam üstü bir İnternet kafede SuSE'nin sanaldoku yöresinden bazı paketler indirdim.
Tümü SuSE'nin 7.3 sürümden 9.0 sürümüne kadar olan ve 2 CD'lik yer tutan belgelerden oluşuyorlardı.
Genelde Debian kullanmama karşın paketler RPM ve SuSE için olduklarından bilgisayarımdaki SuSE 8.1'i
başlattım. İlk 9.0 sürümlü belgeleri yükleyebildim. SuSE'nin 8.* sürümlerine daha yeni sürümlü paketleri
yüklemek sorun değil. O yüzden 9.0 RPM paketlerini yükledim ve yukarıda sözünü ettiğim hda5 bölmesine
kopyaladıktan sonra RPM'lerin yükleme işlemlerini geri aldım. Daha sonra aynı işi 8.0 olan paketler için
yaptım.
KDE'yi kapatmadan bir başka uçbirime geçerek bilgisayarı kapatmak için <CTRL ALT> <DEL> tuşlarına
bastım. Komut satırında, şu anda hatırlayamadığım bir hata iletisi gördüm ve hatırladığım tek şey, bilgisayarımın
ruhunu teslim ettiği oldu. Hiçbir şey yapılamaz oldu...
Peki dedim ve yeniden başlat tuşuna bastım.
Linux'ta bunu yapmaktan artık hiç kormuyorum.
Kötü durum senaryosu
Debian'ı başlattığımda ilk başları hiçbir şey fark etmemiştim. Ne zamanki KDE'yi çalıştırdım:
disk bölmemde hiçbir dizin görünmüyordu.
Ama nasıl olur, burası neredeyse tamamen doluydu ?
Belkide disk bölmesi sisteme bağlanmamıştır. Saçmalıyorum
galibaü bu işlem sistemin açılışında otomatik olarak yapılıyor.
'mount /dev/hda5' komutunu denediğimde ise, 'Çok fazla dosya sistemi veya hatalı süper blok' hata iletisi
oluştu. Artık sıkılmaya başlamıştım...
Yaşadığım olay aslında, gerçek hayatta görülen veri kaybına ilişkin en kötü durum senaryosu idi.
Peki şimdi ne olacak? Hımm .. dosya sistemini tekrar bağlamayı denesem, düzelir mi acaba? İmkanı yok,
ilkinde başarısız olduğuna göre, ikinci denemede de bir sonuç çıkmaz.
Yine de denedim ve ...! Ayların çalışma ürünü olan yazdığım HTML sayfaları, CD yazmak için betikler,
İnternetten indirdiğim DEB ve RPM'ler ile bir sürü başka dosya yok oldu, gitti.
Tabii ki verilen bir kısmı diskte duruyor, ama ben onlara tekrar ulaşabilecek miyim bakalım?
Arkana yasalan ve bir bardak soğuk su için ...
Doğuştan mühendis olarak ilk aklıma gelen verileri onarmak ve geri getirmek geldi. Disk bölmesi ReiserFS dir.
Bir ara c't dergisinde Knoppix hakkında olan bir yazıda bazı araçların varlığını okumuştum. Aslında Debian'ı Knoppix
olarak yüklemiştim ve bu araçlar burada olmalıydı.
Buradalar işte.
reiserfsck'ın acil durumlardaki kullanımı
İlk önce /usr/share/doc/reiser-birşey olan dizinde bulunması gerek belgelere bakmalıyım.
Buradaki 'birşey' reiserfsprogs olmalıydı. Man sayfalarından dönüştürülmüş her araç için birer İngilizce
dosya buldum.
Veri kurtarma hakkındaki araçlar hakkında kısaca bilgi edindikten sonra, 'neşterin' reiserfsck olduğunu
anşadım. Peki, başlayalım bakalım...
İlk önce hiçbir şeyi değiştirmeden -check seçeneği ile programı çalıştırdım. Başlangıçta yapılması
gereken en doğru şey bu olmalıydı. İlk önce teşhis, sonra ameliyat...
# reiserfsck -check
4. Resim : reiserfsck -check
Hepsini anlamadım. Anladığım şey reiserfsck'nın hatalar bulduğu ve bunları düzeltebileceğidir. Kulağa hoş geliyor.
Yaklaşık bir dakika düşündükten sonra, ameliyat yapmaya karar verdim. Elime neşteri aldım...
# reiserfsck --rebuild tree /dev/hda5
5. Resim : reiserfsck --rebuild-tree
Bu beni tedirgin ediyor. Dilek olay. Birazdan gelecek birkaç hafta ne yapacağımı birazdan öğrenmiş olacağım.
'Dosya sistemi şimde onarılsın mı? ... Evet, onarılsın.
Eski güzel 'replaying journal' iletisi gördüm. Bu araç tıpkı bir iyilik meleği gibi, kurtarmayı olası
kılmaktadır. Bir şekil alt bölmeler için
içerik tablosu kullanmaktadır. İki satır sonra reiserfsck hatalı bir null biti haberini vermekte ve onu düzeltmektedir.
Uçbirimde görsel olarak ayrılmış kurtarma işleminin 0. geçiş (Pass 0) aşaması gelmektedir.
Benim 20GB'lik disk bölümümde bu yaklaşık 15 dakika sürmektedir. Gelişmenin yüzde olarak gösterilmesi,
kullanıcının işlemi izleyebilmesine olanak sağlamış oluyor.
2. Resimde bir hata iletisi yer almaktadır. Peki bunun tamam olarak anlamı nedir? Hımm ... bana başka bir sorabilir misiniz? :)
6. Resim : 0. dan 2.'ye kadar olan geçişler, 3. yeni başlıyor
Ooo devam ediyor... 1. geçiş (Pass 1) gerçekten hızlı geçti ve hiç veri hatası iletisi
gelmedi.
2. Geçiş (Pass 2) aynı geçti.
3. Geçişte (Pass 3) bir sürü veri hatası iletisi oluştu. Dosyaları tanıdım, bunlar SuSE'nin belgelerini
kopyalayan işlemden kaynaklanklanmış olmalıdır. Bu da kopyalama işlemi sırasında bir sorun oluştuğunu
ispatlamaktadır. Sorun KDE 3'ün konqueror uygulamasındaydı, yoksa ReiserFS'deki bir hatada mıydı?
7. Resim : 3. geçişin sonu
Açıklamaya göre kayıp dosya ve dizinler için 3a. geçişinde (Pass 3a) bir arama işlemi yapılmış.
8. Resim : 3a. geçiş
Araç, genel olarak aradığını bulmakta, hatayı belirleyip düzeltmekte, 'corrected to ... (ya düzeltildi)' gibi
bir iletiyle satır sonunda bunu bildirmektedir.
Daha sonra da acil kurtarma işlemi hakkında özet bilgiler vermektedir.
4. Geçişte (Pass 4) sadece günlükteki bilgiler ile diskin anuyumlu olduğu iletesini
vermektedir.
9. Resim : 4. geçiş ve son
Şimdi verilerime tekrar ulaşabilmeyi umuyorum
Bu bölmeyi dosya sistemine bağlama sırasında herhangi bir hata iletisi gelmedi, bu da UNIX'te iyiye
işarettir :-)
İyi biten herşey iyidir, öyle değil mi?
Sonunda konqueror hda5 bölmesindeki tanıdık dizinleri göstermektedir. En sonunda herşey
yerli yerinde, yoksa hemen hemen herşey mi demeliyim? Doğal olarak kopyalanmakta olan birkaç dosya
eksik. Hatalı bir işlemden mükemmel bir sonuç bekleyemezsiniz. Dosyaları tekrar kopyalayabilirim.
Bugün, yani olaydan bir gün sonra, henüz hda5'deki tüm verileri denetlemiş değilim. Büyük bir
olasılıkla herşey kurtarıldı. Kurtarma aracı çok profesiyonel iş gördü!
Şu anda o günün ardından bir gün geçti ve saat 16:30'u gösteriyor. Alarm çanları 18 saat önce çalmıştı.
Rapor, yani bu yazı, neredeyse bitiyor. Yani kurtarma operasyonun başarılı olduğuna dair rapor.
Dün kurtarma sırasında uçbirimdeki gelişmeleri kaydettiğime şimdi çok memnunum. Böylece,
gerçek 'kaza resimlerini' yazıda gösterebildim.
Not: İki gün sonra: Veri kaybına dair hiçbir işaret yok. İlgili bölmede sürekli olarak çalışmaya devam ediyorum.
Sonuç
Günlüklü dosya sistemlerinde bile veri kayıpları oluşabilir, ancak kurtarma işleminin başarı oranı çok yüksektir.
Günlüklü dosya sistemleri hem güvenli hem de bakımı kolay olan dosya sistemleridir.
Günlüklü dosya sistemleri her Linux'ta olması
zorunlu dosya sistemleridir. (Serbest
yazılım dünyasında böyle kesin bir düşenceyi ortaya attığım için beni affedersiniz sanırım).
Linux dağıtıcıların çoğu günlüklü dosya sistemini benimsenmiş değer olarak kullanıcıya önermektedir.
Buradan, yedekleme yapmayanların bile sorunsuz çalışabilecekleri sonucu çıkıyor. Ancak, yedekleme yapmayın
sonucu çıkmasın.
Herzaman yedeklerinizi alın!
Referanslar
Günlüklü dosya sistemi yazıları:
Linux için günlüklü dosya sistemleri - 68 sayılı Linux Gazette'in Temmuz 2001 sayısı (de |
en); .. birçok ayrıntı içermektedir.
ReiserFS serüveni - Linux Netmag 4/2000
(de |
en)
Çift günlük tutmak - Linux Magazine 1/2002 (de), günlüklü dosya sistemlerinin karşılaştırılması (sadece Almanca).
Biraz daha fazla mı olmalı? - Linux Magazine 6/2000 (de), ReiserFS'in LVM üzerinden geliştirilmesi (sadece Almanca).
Diskiniz için günlük tutmak - Linux Magazine 4/2000 (de), günlüklü dosya sistemlerinin karşılaştırılması (sadece Almanca).
Bozuk bayramı - Linux Magazine 7/2001 (de) SuSE 7.1 üzerinde XFS (sadece Almanca).
Günlüklü dosya sistemlerinin sanaldoku yöreleri:
ReiserFS - ReiserFS ev yöresi.
ext2 / ext3 - veya bunu deneyin sanaldoku yöresi
XFS - SGI'nın günlüklü dosya sistemi.
JFS - ... IBM'in Açık Kaynak Kodlu projesi.
Yedekleme ile ilgili yazılar:
RSync: Tüm zamanların en iyi yedekleme sistemi - LinuxFocus Mayıs 2004.
storeBackup, alışılmamış yedekleme aracı - LinuxFocus Ocak 2004.
Arkeia, ticari ve profesyonel ağ yedekleme çözümü - LinuxFocus Mayıs 2000.
Bu yazı için görüş bildiriminde bulunabilirsiniz
Her yazı kendi görüş bildirim sayfasına sahiptir. Bu sayfaya yorumlarınızı yazabilir ve diğer okuyucuların yorumlarına bakabilirsiniz.
<--, Bu sayının ana sayfasına gider
2004-07-02, generated by lfparser version 2.43