Hızlı Cevap

Linux sunucuda veri kaybı yaşadıysanız en kritik kural şudur: orijinal disk veya birim üzerinde asla fsck ya da onarım komutu çalıştırmayın ve birime yazmaya devam etmeyin. Birimi hemen unmount edin, salt okunur olarak ddrescue ile bire bir imaj alın ve tüm kurtarma denemelerini bu kopya üzerinde yapın. Yanlış bir onarım, kurtarılabilir veriyi kalıcı olarak yok edebilir.

Linux Sunucularda Veri Kaybı Neden Farklıdır

Linux sunucular çoğu kez şirketin en kritik verisini taşır: veritabanları, sanal makine imajları, kaynak kod depoları, müşteri dosyaları ve yedek arşivleri. Bir masaüstü Windows makinesinden farklı olarak burada birden çok dosya sistemi, mantıksal birim yöneticisi ve yazılım RAID katmanları iç içe geçmiştir. Bu yüzden Linux veri kurtarma, tek bir araca değil doğru teşhise ve doğru sırayla yapılan müdahaleye dayanır.

Sorun çoğu zaman donanım arızası değil insan hatasıdır. Yanlış bir komut, panikle çalıştırılan bir onarım ya da hatalı bir dd hedefi, sağlam veriyi dakikalar içinde geri dönülemez şekilde bozabilir. Bu makale ext4, XFS, Btrfs ve LVM üzerinde en sık görülen senaryoları, doğru araçları ve uygulanması gereken sırayı B2B sunucu odaklı olarak anlatır.

İlk ve En Önemli Adım: Salt Okunur İmaj

Herhangi bir kurtarma aracı çalıştırmadan önce yapılacak tek doğru iş, etkilenen birimi devre dışı bırakıp salt okunur bir imaj almaktır. Sunucu üretimdeyse ilgili servisi durdurun, birimi unmount edin, mümkünse diski salt okunur bağlayın.

GNU ddrescue bu iş için standart araçtır. Normal dd den farklı olarak okuma hatalarını atlar, hata haritası tutar ve sorunlu sektörlere sonra geri dönebilir. İmajı her zaman ayrı ve sağlıklı bir diske yazın, asla kaynak diskin üzerine veya aynı fiziksel diske değil. Bir log dosyası tutarak işlemi durdurup kaldığınız yerden devam edebilirsiniz.

İmaj alındıktan sonra orijinal diski bir kenara kaldırın ve bütün denemeleri kopya üzerinde yapın. Bu tek kural, başarılı kurtarma ile kalıcı veri kaybı arasındaki farkın yüzde sekseni demektir.

Dosya Sistemi Bazında Kurtarma

ext4 ve Journaling Neden Geri Almayı Zorlaştırır

ext4 yıllardır sunucuların varsayılan dosya sistemidir. Güvenilirliğini sağlayan journaling özelliği, ne yazık ki silinen dosyaları geri almayı zorlaştırır. Bir dosya silindiğinde ext4, inode içindeki blok işaretçilerini sıfırlar. Bu yüzden klasik undelete yöntemleri ext4 te ext3 e göre çok daha az işe yarar.

Yine de umut tükenmiş değildir. extundelete aracı, journal kayıtlarını tarayarak silme işleminden önce var olan inode bilgilerini yeniden inşa etmeye çalışır. Başarı, silmeden sonra birime ne kadar yazıldığına bağlıdır. Bu nedenle silme fark edilir edilmez yazmayı durdurmak hayati önemdedir. Superblock bozulmasında ise dumpe2fs ile yedek superblock konumları bulunup mount sırasında alternatif superblock ile birim okunabilir, ancak bu da kopya üzerinde denenmelidir.

XFS ve xfs_repair Riskleri

XFS, büyük dosya sistemlerinde ve yoğun iş yükünde tercih edilir, özellikle RHEL tabanlı sunucularda varsayılandır. XFS te en sık görülen sorun, ani güç kesintisi sonrası log yeniden oynatma hatalarıdır. Burada önemli bir tuzak vardır: xfs_repair komutunu L parametresiyle çalıştırmak, log u sıfırlar ve bu işlem bekleyen işlemlerdeki veriyi kalıcı olarak kaybettirebilir.

Doğru yaklaşım, önce diski temiz bir sistemde mount edip log un normal şekilde oynatılmasını denemektir. Bu mümkün değilse xfs_repair i önce n yani salt okuma simülasyon modunda çalıştırıp nelerin yapılacağını görmek gerekir. Agresif log sıfırlamasını ancak son çare olarak ve mutlaka imaj kopyası üzerinde düşünmelisiniz.

Btrfs, Copy on Write ve btrfs restore

Btrfs, copy on write mimarisi sayesinde snapshot ve checksum gibi güçlü özellikler sunar. Bu mimari avantaj sağlar ama metadata bozulmasında sistemi karmaşıklaştırır. Bozuk bir Btrfs birimi çoğu zaman hiç mount olmaz.

Burada en güvenli araç btrfs restore tir. Bu komut birimi mount etmeden, salt okuma mantığıyla ağaçta gezinerek dosyaları başka bir hedefe kopyalar. Hiçbir yazma yapmadığı için mevcut durumu daha kötüye götürmez. btrfs check komutunun repair seçeneğini ise çok dikkatli kullanmak gerekir, çünkü yanlış bir onarım ağacı daha da bozabilir. Eğer birimde snapshot varsa, öncelikle sağlam bir snapshot tan veri okumayı denemek en hızlı yoldur.

LVM Mantıksal Birim Kurtarma

LVM, fiziksel diskleri esnek mantıksal birimlere böler. En yıkıcı hata, lvremove ile yanlış bir mantıksal birimi silmektir. İyi haber şu ki LVM, metadata değişikliklerinin yedeklerini otomatik olarak slash etc slash lvm slash backup ve slash etc slash lvm slash archive altında tutar.

Silinen bir mantıksal birim, üstüne yeni veri yazılmadığı sürece çoğu zaman geri getirilebilir. Önce vgcfgrestore komutu ile arşivlenmiş önceki metadata sürümü geri yüklenir, böylece silinen birimin tanımı tekrar oluşur. Ardından birim aktif edilip salt okunur olarak bağlanır. Yanlış dd ile üzerine yazılmış bir birimde ise bu yöntem işe yaramaz ve veri taşıyıcı seviyesinde tarama gerekir.

mdadm Yazılım RAID Birleştirme Hataları

Linux yazılım RAID inde, mdadm dizisi açılışta birleşemediğinde panik yapmamak gerekir. En tehlikeli hata, dizinin tekrar create edilmesidir, çünkü create işlemi yeni superblock yazarak mevcut veri düzenini bozabilir. Önce mdadm examine ile her üyenin superblock unu inceleyip rol ve sıra numaralarını, olay sayacını öğrenmek gerekir. Çoğu durumda dizi, assemble force ile yeniden birleştirilebilir. Diskler farklı zamanlarda düştüyse en güncel ve tutarlı üyelerle dikkatli bir birleştirme yapılmalıdır, asla bir create denemesiyle değil.

Sık Görülen Nedenler ve Doğru Yaklaşım

Dosya Sistemi / Katman Tipik Arıza Önerilen Yaklaşım
ext4 rm -rf, silinen dosya, bozuk superblock Yazmayı durdur, ddrescue imaj, extundelete, yedek superblock
XFS Güç kesintisi, log oynatma hatası Önce mount dene, xfs_repair i n moduyla incele, L den kaçın
Btrfs Metadata bozulması, mount olmuyor btrfs restore ile kopyala, snapshot tan oku, repair den kaçın
LVM lvremove ile yanlış birim silme vgcfgrestore ile metadata geri yükle, salt okunur mount
mdadm RAID Dizi birleşemiyor mdadm examine, assemble force, asla yeniden create etme
Tüm katmanlar Yanlış dd hedefi Yazmayı durdur, profesyonel taşıyıcı seviyesi tarama

Asla Yapılmaması Gerekenler

Linux veri kurtarmada en çok veriyi onarım girişimleri yok eder. Orijinal birim üzerinde fsck y çalıştırmak, hataları sormadan otomatik kabul eder ve çoğu kez kurtarılabilir yapıları ezer. mkfs ile yeniden biçimlendirmek dosya sistemi metadata sını sıfırlar. Yarım kalmış bir RAID yeniden oluşturma denemesi paritesi bozar. Btrfs te repair, XFS te L, mdadm da create komutları, panikle çalıştırıldığında en çok zarar veren komutlardır. Hepsinin ortak özelliği orijinale yazmasıdır, bu yüzden hepsi önce imaj kopyası üzerinde denenmelidir.

Doğru Kurtarma Sırası

Özetle doğru sıra şudur: ilk olarak yazmayı durdurun ve birimi unmount edin. İkinci olarak ddrescue ile salt okunur bire bir imaj alın. Üçüncü olarak bütün analiz ve denemeleri bu kopya üzerinde yapın. Dördüncü olarak dosya sistemine uygun aracı seçin: ext4 te extundelete, Btrfs te btrfs restore, LVM de vgcfgrestore, genel dosya kurtarmada TestDisk ve PhotoRec. Beşinci olarak emin olmadığınız her noktada durun. Yanlış bir komut, profesyonel bir laboratuvarın bile geri getiremeyeceği hasara yol açabilir.

Ne Zaman Durup Laboratuvara Başvurmalı

Disk fiziksel ses çıkarıyorsa, SMART değerleri kötüleşiyorsa, birden çok RAID üyesi aynı anda düştüyse, ya da imaj alma sırasında okuma hataları hızla artıyorsa kendi kendinize devam etmeyin. Bu durumlarda her yeni okuma denemesi diski daha çok yıpratır. Temiz oda ve profesyonel imajlama donanımı gerektiren bu vakalarda erken durmak, verinin tamamını kurtarma şansını korur.

Sık Sorulan Sorular (SSS)

rm -rf çalıştırdım, veriler kurtulur mu?

Çoğu zaman evet, ancak şart silme anında yazmayı durdurmaktır. ext4 te journaling nedeniyle undelete zordur fakat extundelete ile journal taraması sonuç verebilir. Birime ne kadar çok yazılırsa şans o kadar azalır. Hemen birimi unmount edip imaj alın.

Panikle fsck y çalıştırdım, şimdi ne olur?

fsck y birçok yapıyı sormadan onarmış ve bazı verileri kaybettirmiş olabilir. Yine de pes etmeyin. Birime daha fazla yazmayın, salt okunur imaj alın ve kurtarma araçlarını kopya üzerinde çalıştırın. Profesyonel bir laboratuvar, fsck sonrası durumdan bile çoğu zaman veri çıkarabilir.

lvremove ile yanlış bir LVM birimi sildim, geri gelir mi?

Büyük olasılıkla evet. LVM, metadata yedeklerini slash etc slash lvm slash archive altında tutar. vgcfgrestore ile silmeden önceki sürümü geri yükleyerek birim tanımını geri getirebilirsiniz. Tek şart, silinen alanın üzerine yeni veri yazılmamış olmasıdır.

Btrfs birimim mount olmuyor, ne yapmalıyım?

Önce btrfs restore ile birimi mount etmeden dosyaları başka bir diske kopyalamayı deneyin, bu işlem hiçbir yazma yapmaz. Birimde snapshot varsa sağlam bir snapshot tan okumak en hızlı yoldur. btrfs check repair komutunu son çare olarak ve mutlaka imaj üzerinde düşünün.

Yazılım RAID dizim birleşmiyor, yeniden oluşturmalı mıyım?

Kesinlikle hayır, yeniden create etmeyin. Bu işlem superblock ları ezerek veriyi yok edebilir. Önce mdadm examine ile üyeleri inceleyin, ardından mdadm assemble force ile birleştirmeyi deneyin. Emin değilseniz diziyi olduğu gibi bırakıp uzmana danışın.

DSET Hakkında

DSET, 2003 ten bu yana Ankara Hacettepe Teknokent Beytepe de faaliyet gösteren bir veri kurtarma ve siber güvenlik şirketidir. Linux sunucu, RAID, sanallaştırma ve tüm dosya sistemlerinde uzmanlaşmış ekibimiz, veri kurtarmada yüzde 99.4 başarı oranı ile çalışır. İlk teşhis ücretsizdir ve veri çıkmazsa ücret alınmaz. Hemen ulaşın: +90 536 662 38 09.

İlgili rehberler: RAID 5 çöktü kurtarma | sunucu sanallaştırma VMware Hyper-V kurtarma | veri kurtarma fiyat listesi 2026

Kaynaklar