Veri kaybı: En kötü durum senaryosu

ArticleCategory:

System Administration

AuthorImage:[Ein Bild von Dir]

[Photo of the Author]

TranslationInfo:

original in de Detlef Müller 

de to en Orla Shanaghy

en to tr:Erdal Mutlu

AboutTheAuthor:

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.

Abstract:

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.

ArticleIllustration:[Das Titelbild des Artikels]

Mounted nicht

ArticleBody:[The main part of the article]

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:

QtParted hda
2. Resim: SCSI disk olan sda'nın bölmeleri

QtParted hda
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

Konsole Bild 1
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

Üçbirim resmi 2
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? :)

Üçbirim resmi 3
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ı?

Üçbirim resmi 4
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ış.

Üçbirim resmi 5
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.

Üçbirim resmi 6
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.