EXT4 ve XFS Dosya Sistemlerinde Veri Kurtarma Süreci Nasıl İşler?

Günümüz bilişim dünyasında ister devasa ölçekli veri merkezlerini (Data Center) yöneten bir bulut mimarı olun, ister şirketinizin veri depolama ihtiyacını Synology veya QNAP gibi NAS (Network Attached Storage) cihazlarıyla karşılayan bir sistem yöneticisi; verilerinizin arka planında çalışan dosya sistemlerinin yapısını bilmek hayati önem taşır. Windows dünyasında hüküm süren NTFS veya ReFS mimarilerine kıyasla, Linux ekosisteminin iki dev sütunu olan EXT4 (Fourth Extended Filesystem) ve XFS, performans, esneklik ve kararlılık konusunda rakipsiz kabul edilir.

Ubuntu, Debian, CentOS, Red Hat Enterprise Linux (RHEL), SUSE, Rocky Linux gibi dünyayı yöneten işletim sistemlerinden; yüksek hızlı veritabanı sunucularına, sanallaştırma platformlarından (KVM, Proxmox) devasa veri depolama havuzlarına kadar hemen her yerde EXT4 ve XFS dosya sistemleri kullanılır. Ancak bu gelişmiş Linux dosya sistemleri mükemmel bir mühendislik harikası olsalar da; aniden beliren donanımsal disk arızaları, elektrik kesintileri, yanlışlıkla çalıştırılan rm -rf komutları, bozulan RAID dizileri veya hatalı yapılan dosya sistemi onarımları (e2fsck ve xfs_repair) nedeniyle feci veri kayıpları yaşanabilir.

Bir sabah sunucunuza erişmeye çalıştığınızda Kernel Panic, Mount: structure needs cleaning veya Datastore Inaccessible gibi hatalarla karşılaştığınızda kriz anı başlamış demektir. Peki, EXT4 ve XFS dosya sistemlerinde veri kurtarma süreci gerçekte nasıl işler? Silinen bir dosya diskin derinliklerinde nerede saklanır? İşletim sistemi bir dosyayı sildiğinde veri bloğuna ne olur? Bu kapsamlı rehberimizde; EXT4 ve XFS mimarilerinin veri depolama mantığını, Inode ve Extent yapılarını, Allocation Groups kavramını, silme ve bozulma anındaki alt seviye (low-level) blok davranışlarını ve en önemlisi profesyonel Linux veri kurtarma laboratuvarında uygulanan mühendislik adımlarını tüm teknik detaylarıyla inceleyeceğiz.

1. EXT4 Dosya Sistemi Mimarisi ve Veri Depolama Mantığı

EXT4, Linux dünyasının en köklü ve en yaygın kullanılan dosya sistemi ailesinin (EXT2, EXT3) dördüncü nesil evrimidir. 2008 yılında kararlı sürüme ulaşan EXT4,1 Exabyte(1018 byte) büyüklüğündeki veri alanlarını ve 16 Terabyte boyutundaki tekil dosyaları destekleyebilecek şekilde tasarlanmıştır.

EXT4 dosya sisteminde veri kurtarmanın nasıl mümkün olduğunu anlamak için, bu dosya sisteminin disk üzerindeki anatomisini bilmemiz gerekir.

1. Genel Disk Düzeni Bileşenleri

• Boot Block (1 KB): Diskin en başında yer alan 1024 baytlık özel alandır. Sistem ön yükleyicisinin (x86 MBR vb.) yerleşimi için ayrılmıştır; EXT4 dosya sistemi tarafından doğrudan kullanılmaz.
• Block Groups (Blok Grupları - Group 0, 1, 2... N): EXT4 diski büyük veri blokları gruplarına böler. Disk kafasının hareketini minimize etmek ve performansı artırmak için ilgili verileri aynı grup içinde tutmayı amaçlar.

2. Blok Grubu İç Yapısı (Block Group Interior)

• Superblock (1 Blok / Genelde 4 KB): Dosya sisteminin genel yapılandırma bilgilerini tutar (toplam inode/blok sayısı, blok boyutu, boş alan miktarı, dosya sistemi durumu vb.). Kritik bir bileşen olduğu için diğer bazı blok gruplarında yedekleri (Backup Superblock) bulunur.
• Group Descriptors / GDT (Grup Tanımlayıcıları): Diskteki tüm blok gruplarının durumunu ve ilgili gruptaki bitmap ile inode tablosunun konumlarını belirten meta verileri içerir.

Başlık	Açıklama
Data Block Bitmap (1 Blok)	Blok grubundaki veri bloklarının hangilerinin dolu, hangilerinin boş olduğunu gösteren bit haritasıdır (her bit 1 bloğu temsil eder).
Inode Bitmap (1 Blok)	Blok grubundaki Inode indekslerinin hangilerinin kullanımda, hangilerinin serbest olduğunu takip eden bit haritasıdır.
Inode Table (Çoklu Bloklar)	Dosyaların meta verilerini (dosya boyutu, izinler, sahiplik, erişim zamanları, veri bloklarının adresleri) barındırır. Standart olarak her inode 256 bayt büyüklüğündedir.
Data Blocks	Kullanıcı verilerinin (dosya içerikleri, dizin bilgileri) fiziksel olarak depolandığı asıl veri alanıdır.

A. Blok Grupları (Block Groups) ve Superblock

EXT4, sabit disk bölümünü (partition) Block Group (Blok Grubu) adı verilen eşit büyüklükteki parçalara böler. Genellikle her bir blok grubu 32 MB ile 128 MB arasında değişen blok alanlarını yönetir.

Başlık	Açıklama
Superblock	Dosya sisteminin kimlik kartıdır. Toplam blok sayısı, toplam Inode sayısı, blok boyutu (genellikle 4096 Byte yani 4 KB), son mount edilme tarihi, dosya sisteminin durumu (Clean/Dirty) ve blok gruplarının adresleri burada saklanır. Superblock bozulursa dosya sistemi mount edilemez. Bu yüzden EXT4, belirli blok gruplarında Superblock'un yedeklerini (Backup Superblocks) otomatik olarak saklar.
Block Group Descriptor Table (GDT)	Her blok grubunun içindeki bitmap ve Inode tablolarının nerede başlayıp nerede bittiğini gösteren haritadır.
Block Bitmap ve Inode Bitmap	Hangi veri bloklarının veya hangi Inode numaralarının dolu, hangilerinin boş olduğunu gösteren 0 ve 1 değerlerinden oluşan bit haritalarıdır.

B. Inode (Index Node) Mantığı

EXT4 dosya sisteminde dosya ismi ile dosyanın içeriği birbirinden tamamen ayrı yapılardır.

Bir dosyanın adı ve hangi klasörün altında durduğu bilgisi Directory Entry (Dizin Kaydı) içinde saklanırken; dosyanın boyutu, erişim izinleri (chmod), sahibi (UID/GID), oluşturulma/değiştirilme zamanları (atime, mtime, ctime, crtime) ve verinin diskteki hangi bloklarda durduğu bilgisi Inode adı verilen veri yapısında tutulur. Her Inode varsayılan olarak 256 Byte boyutundadır.

C. Extents Mimarisi (EXT3'ten En Büyük Farkı)

Eski nesil EXT3 dosya sisteminde, bir dosyanın blok adresleri Inode içinde "Pointer" (işaretçi) mantığıyla tek tek listelenirdi. Bu durum devasa boyuttaki bir video veya veritabanı dosyasının yüz binlerce blok adresini tutmayı gerektiriyor ve dosya parçalanmasını (fragmentation) artırıyordu.

EXT4 ile birlikte Extents (Erimler) mimarisine geçildi. Extent, yan yana duran ardışık blokları tek bir adres aralığı olarak tanımlar:

Extent= {Başlangıç Mantıksal Bloğu, Blok Sayısı, Fiziksel Başlangıç Bloğu}

Örneğin, 100 MB boyutundaki bir dosya diskte parçalanmamışsa, EXT4 bu dosya için yüz binlerce işaretçi tutmak yerine tek bir Extent tanımı yazar: "Mantıksal 0. bloktan itibaren 25600 adet bloğu, fiziksel 52000. bloktan başlayarak oku."

İşte bu Extent Tree (Erim Ağacı) yapısı, veri kurtarma operasyonlarında hem en büyük avantaj hem de en büyük zorluk kaynağıdır.

D. JBD2 Journaling (Günlük Tutma)

EXT4, veri güvenliğini sağlamak için JBD2 (Journaling Block Device 2) adı verilen bir günlük mekanizması kullanır. Diske bir veri yazılmadan önce, yapılacak işlem önce Journal alanına kaydedilir, ardından gerçek veri alanına yazılır ve işlem "tamamlandı" olarak işaretlenir. Elektrik kesintisi durumunda sisteme yeniden güç geldiğinde, EXT4 tüm diski taramak yerine sadece Journal kaydına bakarak yarım kalan işlemleri tamamlar veya geri alır (Rollback).

2. XFS Dosya Sistemi Mimarisi ve Yüksek Performanslı Yapısı

1990'lı yıllarda Silicon Graphics (SGI) tarafından IRIX işletim sistemi için geliştirilen, 2001 yılında Linux kerneline entegre edilen XFS, günümüzde Red Hat Enterprise Linux (RHEL 7, 8, 9) ve CentOS sistemlerin varsayılan varsayılan dosya sistemidir. XFS, 64-bit mimariye sahip, muazzam büyüklükteki dosyaları ve yüksek paralel I/O (Okuma/Yazma) yüklerini işlemek üzere tasarlanmış petabyte ölçekli bir dosya sistemidir.

XFS'in dahili mimarisi EXT4'ten radikal biçimde farklıdır.

1. Genel Disk Düzeni (XFS Disk Layout)

• Allocation Groups (Tahsis Grupları - AG 0, AG 1, AG 2... AG N): XFS, diski eşit büyüklükte bağımsız sanal bölgelere (Allocation Group) böler. Her AG kendi üst verisini ve alanını yönetir. Bu sayede sistem, birden fazla işlem parçacığının (thread) diske aynı anda paralel yazma yapmasına olanak tanır ve kilitlenmeleri (lock) önler.

2. AG 0 İç Yapısı (Allocation Group Interior)

Başlık	Açıklama
Superblock (AG Header - İlk 512 Bayt)	Her Tahsis Grubu'nun (AG) ilk 512 baytında yer alan başlık bilgisidir. Blok boyutu, toplam AG sayısı, dosya sistemi UUID'si gibi kritik dosya sistemi meta verilerini saklar. AG0'daki ana yapıdır, diğer AG'lerdeki kopyaları yedek işlevi görür.
AGF (Allocation Group Free Space Header)	Tahsis grubundaki boş alanların yönetiminden sorumludur. Boş veri bloklarını takip etmek için iki ayrı B+ Tree (B+ Ağacı) yapısının kök adreslerini tutar (biri blok offset'ine göre, diğeri blok uzunluğuna göre sıralıdır).
AGI (Allocation Group Inode Header)	Tahsis grubundaki Inode yönetimini sağlar. Tahsis edilmiş ve boş olan Inode'ları takip eden B+ Tree yapılarının kök bilgilerini içerir.
AGFL (Allocation Group Free List)	B+ Tree yapılarının kendisi genişlerken veya küçülürken ihtiyaç duyacağı iç blokları önceden hazır tutan serbest alan listesidir. Ağaç operasyonlarında alan tükenmesini engeller.

• Dynamic Inodes & Data Blocks (Dinamik Inode ve Veri Blokları): XFS, Inode'ları disk kurulumunda sabit olarak oluşturmaz; ihtiyaç duyuldukça veri bloklarının içerisinde dinamik olarak (kümeleme şeklinde) oluşturur. Gerçek veri blokları ve bu verilerin dizilimini yöneten B+ Tree düğümleri (B-Nodes) bu alanda saklanır.

A. Allocation Groups (Tahsis Grupları - AG)

XFS, tüm disk alanını Allocation Group (AG) adı verilen tamamen bağımsız sanal alt disklere böler. Bir XFS dosya sisteminde diskin boyutuna bağlı olarak genellikle 4 ile 64 (veya daha fazla) AG bulunur.

Her bir Allocation Group kendi içinde şunları barındırır:

#	Başlık	Açıklama
1.	AG Superblock	O gruba ait boyutu ve yapısal bilgileri tutar.
2.	AGF (Allocation Group Free Block Info)	Grubun içindeki boş alanları takip eden iki adet B+ Tree (B-Ağacı) yapısını yönetir.
3.	AGI (Allocation Group Inode Info)	Grubun içindeki Inode tahsislerini takip eden B+ Tree yapısını tutar.
4.	AGFL (Allocation Group Free List)	B+ Tree düğümlerinin genişlemesi için ayrılmış hazır boş blok listesidir.

Sistem Yöneticisi Açısından Avantajı: Farklı işlemci çekirdekleri (CPU Cores) veya farklı disk kanalları, birbirini beklemeden (Locking mekanizmasına takılmadan) aynı anda farklı Allocation Group'lara okuma/yazma yapabilir. Bu da XFS'i devasa veritabanlarında ve yüksek hızlı NVMe SSD dizilerinde rakipsiz kılar.

B. Dinamik Inode Tahsisi (Dynamic Inode Allocation)

EXT4'te dosya sistemi formatlanırken diskin başında sabit sayıda Inode oluşturulur (örneğin 10 milyon Inode). XFS'te ise önceden ayrılmış sabit bir Inode tablosu yoktur!

XFS ihtiyaca göre disk üzerinde dinamik olarak yeni Inode blokları oluşturur ve bunları B+ Tree yapılarıyla bağlar. Diskte yer olduğu sürece Inode tükenmesi sorunu yaşanmaz. Her bir XFS Inode'u varsayılan olarak 256 Byte ile 2048 Byte arasındadır.

C. B+ Tree Ağaç Yapıları ve Adres Haritalama

XFS, veritabanı motorlarına benzeyen karmaşık bir B+ Tree (B-Ağacı) veri indeksleme algoritması kullanır. XFS içinde neredeyse her şey bir B+ Tree ile yönetilir:

Başlık	Açıklama
Free Space by Block (cntbt)	Boş blokları büyüklüklerine göre indeksleyen B+ Tree.
Free Space by Start Block (bnobt)	Boş blokları başlangıç adreslerine göre indeksleyen B+ Tree.
Inode B+ Tree (inobt)	Dinamik oluşturulan Inode'ların yerini tutan B+ Tree.
Extent B+ Tree (bmbt)	Bir dosyanın parçalanmış blok adreslerini tutan B+ Tree.

Bir dosya aşırı derecede parçalansa (fragmentation) dahi, XFS B+ Tree yapısı sayesinde o verinin adreslerine nanosaniyeler içinde ulaşabilir.

3. EXT4 vs XFS: Veri Kaybı ve Kurtarma Dinamiklerinin Karşılaştırması

İki dosya sistemi arasındaki mimari farklar, bir veri kaybı felaketi yaşandığında kurtarma başarısını doğrudan etkiler. Aşağıdaki teknik karşılaştırma tablosu, alt seviye (low-level) mühendislik farklarını ortaya koymaktadır:

<table><tbody><tr><td><strong>Mimarisi &amp; Senaryo</strong></td><td><strong>EXT4 Dosya Sistemi</strong></td><td><strong>XFS Dosya Sistemi</strong></td><td><strong>Veri Kurtarma Açısından Etkisi</strong></td></tr><tr><td><strong>Inode Yapısı</strong></td><td>Statik (Format anında diske sabitlenir).</td><td>Dinamik (İhtiyaç duyuldukça AG içine dağıtılır).</td><td>EXT4'te Inode konumları sabittir; XFS'te Inode'ları bulmak için B+ Tree taranmalıdır.</td></tr><tr><td><strong>Dosya Silme (rm Komutu)</strong></td><td>Inode sıfırlanır, Extents haritası silinir, Directory Entry kalabilir.</td><td>Inode un-link edilir, B+ Tree düğümü silinir, Extent listesi sıfırlanır.</td><td>Her iki sistemde de silme anında metadata sıfırlanır. Ancak EXT4 Journal taraması daha yüksek sonuç verir.</td></tr><tr><td><strong>Dizin / Klasör Mimarisi</strong></td><td>Hash tabanlı H-Tree veya Lineer dizin blokları.</td><td>Shortform, Block, Leaf ve Node formunda B+ Tree dizinleri.</td><td>XFS klasör yapısı bozulduğunda dosya isimlerini (filenames) yeniden oluşturmak daha zordur.</td></tr><tr><td><strong>Superblock Bozulması</strong></td><td>Sabit yedekler (32768, 98304 vb.) bloklarda durur.</td><td>AG0, AG1, AG2... her bir AG girişinde yedek Superblock vardır.</td><td>XFS, Allocation Group yapısı sayesinde Superblock tamirinde oldukça dayanıklıdır.</td></tr><tr><td><strong>Journal Mekanizması</strong></td><td>JBD2 (Dairesel Log Buffer).</td><td>Metadata Log (Internal veya External CIL Log).</td><td>EXT4 Journal alanından silinen dosyaların eski Inode kayıtları kurtarılabilir.</td></tr><tr><td><strong>e2fsck / xfs_repair Tepkisi</strong></td><td>Yetim dosyaları /lost+found klasörüne toplar.</td><td>Tutarsız B+ Tree düğümlerini siler/sıfırlar (-L parametresi log'u yok eder).</td><td>xfs_repair -L komutu bilinçsizce kullanılırsa tüm veriyi kalıcı olarak silebilir!</td></tr></tbody></table>

4. EXT4 Dosya Sisteminde Veri Kaybı Olayları ve Kurtarma Metodolojisi

EXT4 dosya sisteminde yaşanan bir kriz anında, sorunun kaynağına göre uygulanan adımlar değişkenlik gösterir.

1. Kaza / Bozulma Anı Oluşumu

• 1.Olay: rm -rf Komutu (Veri Silinmesi)
  • Directory Entry Unlink: Dosya adı ile Inode arasındaki bağlantı koparılır.
  • Inode Deallocation: Inode "kullanılmıyor" (boş) olarak işaretlenir.
  • Bitmap Update: Veri ve Inode bit haritaları (bitmaps) "Free" (serbest) şeklinde güncellenir.
• 2.Olay: Metadata Bozulması (Sistem / Donanım Hasarı)
  • Superblock / GDT Hasarı: Ana yapılandırma blokları veya Grup Tanımlayıcı Tablosu bozulur.
  • Structure Needs Cleaning: İşletim sistemi dosya yapısında uyumsuzluk tespit ederek hata verir.
  • Mount Edilemez Durum: Diskteki bölüm (partition) sisteme normal yollarla bağlanamaz hale gelir.

2. Kurtarma Metodolojisi

• 1.Olay için Kurtarma Adımları:
  1. JBD2 Journal Log Taraması: EXT4 günlük (journal) kayıtları incelenerek silinme öncesine ait Inode haritası tespit edilmeye çalışılır.
  2. Unallocated Space Carving: Boş olarak işaretlenmiş disk alanları taranarak bilinen dosya türlerinin imza (Magic Header/Footer) bilgileri bulunur.
  3. Extent Tree Re-stitching: Veri blokları, Extent ağaç yapısı mantığıyla takip edilerek doğru sırayla birleştirilir.
• 2.Olay için Kurtarma Adımları:
  1. Backup Superblock Tespiti: mke2fs -n veya dumpe2fs gibi araçlarla diske dağıtılmış olan yedek Superblock konumları belirlenir.
  2. Virtual GDT Reconstruction: Hasar gören Grup Tanımlayıcı Tablosu, yedek yapılandırma blokları kullanılarak sanal olarak yeniden inşa edilir.
  3. Read-Only Mount & Extraction: Oluşturulan sanal harita ve ham bit-stream imajı üzerinden disk "Salt Okunur" olarak bağlanarak sağlam veriler dışarı aktarılır.

1.Olay: Yanlışlıkla rm -rf ile Dosya veya Klasör Silinmesi

Bir Linux kullanıcısı veya script yanlışlıkla rm -rf /var/www/html/projeler komutunu çalıştırdığında EXT4 arka planında şu 3 işlem gerçekleşir:

#	Başlık	Açıklama
1.	Dizin Kaydı Temizliği	Dosyanın adı ile Inode numarası arasındaki bağ (Hard link count) koparılır. Link sayısı 0 olduğunda dosya erişilemez hale gelir.
2.	Inode Temizliği	İşletim sistemi söz konusu Inode kaydına gider, i_size (boyut) bilgisini 0 yapar, Extent ağacının kök düğümünü siler ve Inode Bitmap üzerinde bu Inode numarasını "Kullanılabilir" (0) olarak işaretler.
3.	Block Bitmap Güncellemesi	Dosyanın daha önce kullandığı fiziksel bloklar Block Bitmap üzerinde "Boş" (0) olarak işaretlenir. ANCAK, verinin kendisi (0 ve 1 baytları) disk bloklarından hemen silinmez! Üzerine yeni veri yazılmadığı sürece o veri bloklarda durmaya devam eder.

EXT4 Silinen Dosyayı Kurtarma Mühendisliği:

EXT4 üzerinde silinen bir dosyayı geleneksel yöntemlerle kurtarmak zordur çünkü Inode içindeki Extent ağacı temizlenmiştir. Ancak profesyonel veri kurtarma yazılımları ve DrDisk Lab mühendisleri şu 3 ileri seviye tekniği kullanır:

#	Başlık	Açıklama
1.	JBD2 Journal Mining (Günlük Madenciliği)	Silme işlemi gerçekleşmeden birkaç saniye veya dakika önceki Inode durumları JBD2 Journal alanında henüz ezilmemiş olabilir. Journal alanı taranarak silinen dosyanın orijinal Extent haritası (hangi bloklarda durduğu bilgisi) ve orijinal dosya adı bulunarak veri %100 oranında klasör yapısıyla kurtarılır.
2.	Directory Entry Reconstruction	Dizin blokları tamamen ezilmemişse, silinmiş olan dizin kayıtları (Unlinked Directory Entries) hex-level analiz edilerek Inode numaralarıyla eşleştirilir.
3.	Raw Signature Carving	Eğer Inode ve Journal ezilmişse, dosya sisteminden bağımsız olarak ham bloklar taranır. Örneğin bir PDF dosyasının başlangıç imzası (%PDF-1.) ve bitiş imzası (%%EOF) arasındaki bloklar birleştirilerek dosya kurtarılır.

2.Olay: Superblock ve Block Group Descriptor Bozulması

Elektrik kesintisi veya disk üzerindeki bir bad sector, ana Superblock alanını ( adresi) bozabilir. Bu durumda Linux sistemi diski mount edemez ve şu hatayı verir:

mount: /dev/sdb1: can't read superblock

Çözüm ve Mühendislik Adımları:

Asla panikle e2fsck -y /dev/sdb1 komutunu çalıştırmayın! Bu komut yedek superblockları bulamazsa diskin mantıksal yapısını tamamen yok edebilir.

Doğru yaklaşım:

1. dumpe2fs /dev/sdb1 | grep -i superblock veya mke2fs -n /dev/sdb1 komutuyla (buradaki -n parametresi diske hiçbir şey yazmadan sadece simülasyon yapar) alternatif Superblock konumları belirlenir.
2. Örneğin 32768 bloğunda bir yedek Superblock olduğu tespit edilirse, özel donanımsal okuyucular veya salt-okunur komutlar kullanılarak dosya sistemi bu yedekten sanal olarak ayağa kaldırılır:
   e2fsck -b 32768 /dev/sdb1 (Not: Bu işlem sadece diskin birebir imajı alındıktan sonra kopyalanmış imaj üzerinde denenmelidir!)

XFS Dosya Sisteminde Veri Kaybı Olayları ve Kurtarma Metodolojisi

XFS dosya sistemi, devasa veritabanları ve kurumsal sanallaştırma sistemleri (VMware ESXi, KVM, Proxmox) için mükemmel bir performans sunarken; veri kaybı yaşandığında mantıksal karmaşıklığı nedeniyle en zor müdahale edilen dosya sistemlerinden biridir.

1.Olay: XFS Üzerinde Dosya Silinmesi ve Truncate İşlemleri

XFS üzerinde bir dosya silindiğinde veya bir veritabanı tablosu TRUNCATE edildiğinde, XFS'in B+ Tree motoru derhal devreye girer:

1. Söz konusu dosyaya ait Extent B+ Tree düğümleri silinir.
2. AGF ve AGI başlıklarındaki B+ Tree ağaçları güncellenerek bu alanlar "Boş Bloklar B+ Ağacına" (freestanding btrees: cntbt ve bnobt) dahil edilir.
3. Inode B+ Tree (inobt) içindeki ilgili Inode kaydı "Free" durumuna getirilir.

XFS Silinen Dosyayı Kurtarma Zorluğu:

EXT4'ün aksine, XFS'te B+ Tree düğümleri silindiğinde dosyanın parçalanmış blok haritası anında dağılır. Eğer dosya disk üzerinde tek bir bitişik blok dizisi (contiguous extent) halinde saklanmışsa kurtarma başarısı son derece yüksektir. Ancak dosya parçalanmışsa (fragmented), B+ Tree kök düğümlerinin laboratuvar ortamında Deep AG Scanning (Derin Allocation Group Taraması) yapılarak B-Ağacı kalıntılarından sanal olarak yeniden inşa edilmesi gerekir.

2.Olay: XFS Metadata Bozulması ve Ölümcül xfs_repair -L Tuzağı!

XFS dosya sisteminde sunucunun aniden kapanması veya RAID kartının çökmesi sonucu Metadata tutarsızlığı (corruption) oluştuğunda, sistem yöneticiye şu mesajı verir:

XFS (sdb1): Metadata corruption detected at xfs_agf_read_verify

Sistem yöneticileri genellikle çözüm ararken internetteki forumlarda önerilen şu komutu çalıştırırlar:

xfs_repair /dev/sdb1

Bu komut çalıştığında XFS log alanında temizlenmemiş işlemler olduğunu görür ve kullanıcıya şu uyarıyı basar:

ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log...

If you intend to use the -L option to destroy the log, then be aware that you may lose data.

İşte dananın kuyruğunun koptuğu yer burasıdır! Kullanıcı panikle uyarılara dikkat etmeden xfs_repair -L /dev/sdb1 komutunu çalıştırır.

-L (Force Log Zeroing) Parametresi Neden Tehlikelidir?

-L parametresi, XFS log (Journal) alanını Sıfırlar ve Yok Eder! Log alanında yazılmayı bekleyen henüz commited edilmemiş tüm Inode değişiklikleri, B+ Tree güncellemeleri ve dosya indeksleri çöpe atılır.

xfs_repair -L komutu çalıştırıldıktan sonra sistem diski mount edebilir duruma gelir, ancak kullanıcı diskin içine girdiğinde dosyalarının %50'sinin yok olduğunu, kalanların ise isimlerinin silinerek /lost+found veya jenerik Inode isimlerine dönüştüğünü dehşetle görür!

HAYATİ UYARI: Hasarlı bir XFS veya EXT4 diski üzerinde kesinlikle bilinçsizce 'xfs_repair -L' veya 'e2fsck -y' komutlarını çalıştırmayın. Bu komutlar dosya sistemini çalıştırmayı amaçlar; sizin VERİLERİNİZİ KURTARMAYI DEĞİL! Sistem, diski açabilmek için bozuk gördüğü tüm dosyalarınızı tereddüt etmeden siler.

Linux Veri Kurtarmada Hayati Uyarılar ve Ölümcül Hatalar

Bir Linux sunucusunda veya NAS cihazında veri kaybı fark edildiği an atılacak ilk birkaç adım, verinin kurtarılabilirlik kaderini çizer.

Kaçınılması Gereken 5 Ölümcül Hata:

1. Canlı Disk Üzerinde Çalışmaya Devam Etmek: Veri kaybı yaşanan partition (örneğin /dev/sda3) canlı işletim sisteminin kurulu olduğu kök dizin (/) ise, işletim sistemi arka planda log yazmaya (/var/log), geçici dosyalar oluşturmaya (/tmp) ve swap alanını kullanmaya devam eder. Arka planda yazılan her bir bayt, silinen verilerinizin üzerine yazılır (Overwriting).
2. Arızalı Diske Kurtarma Yazılımı Kurmak: Silinen dosyaları kurtarmak için internetten indirilen bir Linux kurtarma aracını, verinin silindiği diskin içine yüklemek! Kurulan yazılımın paketleri silinen fotoğraflarınızın veya veritabanınızın üzerine yazılacaktır.
3. Mount Parametrelerine Dikkat Etmemek: Hasarlı bir diski incelemek için sisteme bağlarken standart mount /dev/sdb1 /mnt komutu kullanılmamalıdır. İşletim sistemi mount anında atime (access time) güncellemeleri yapar ve Journal kaydını oynatır (replay). Disk mutlaka Read-Only (Salt Okunur) modda ve Journal oynatması engellenerek bağlanmalıdır:
   mount -o ro,norecovery /dev/sdb1 /mnt (XFS için)
   mount -o ro,noload /dev/sdb1 /mnt (EXT4 için)
4. Fiziksel Hasarlı Diske Yazılımsal Taramalar Yapmak: Diskten "tık tık" sesi geliyorsa veya okuma kafası vuruyorsa (Click of Death), donanımsal arıza var demektir. Bu durumda yazılımsal tarama yapmak okuma kafasının manyetik plakaları (Platters) dairesel olarak çizmesine ve verilerin toz haline gelerek yok olmasına neden olur.
5. Disk Sırasını Karıştırıp RAID Yapısını Bozmak: NAS veya Linux Software RAID (mdadm) kullanan yapılarda disklerin yerlerini rastgele değiştirmek veya mdadm --create --force komutuyla diziyi bilmeden yeniden oluşturmaya çalışmak RAID blok haritasını tamamen çökertir. 

DrDisk Lab Laboratuvarında Linux (EXT4/XFS) Veri Kurtarma Adımları

DrDisk Lab Linux Veri Kurtarma Laboratuvar Süreci

• 1. Fiziksel ve Donanımsal Teşhis (Hardware Write-Blocker)
  • Diskin elektriksel, mekanik ve okuyucu kafa (Head Stack) durumu analiz edilir.
  • Fiziksel bir hasar tespit edilirse Class 100 Cleanroom (temiz oda) ortamında müdahale edilerek tamir edilir.
• 2. Sektör Düzeyinde Birebir Klonlama (Bit-Stream Imaging)
  • PC-3000 gibi profesyonel donanımsal imaj alma cihazları ile diskin %100 birebir kopyası çıkarılır.
  • Orijinal disk üzerindeki verilerin riske atılmaması için kilitlenerek koruma kasasına kaldırılır.
• 3. Sanal Reconstruction ve Low-Level Analysis
  • EXT4: JBD2 Journal mining (günlük taraması) ve Extent Tree Re-stitching (ağaç yapısını birleştirme) işlemleri yapılır.
  • XFS: Allocation Group (AG) B+ Tree yapıları sanal olarak yeniden inşa edilir.
  • Karmaşık disk yapılarına ait RAID, LVM, LVM2 ve Thin Provisioning katmanları çözümlenerek ham veriye ulaşılır.
• 4. Veri Doğrulama ve Güvenli Teslimat
  • Kurtarılan veritabanı (MySQL, PostgreSQL vb.) ve kritik dosyalar bütünlük testinden geçirilir.
  • Oluşturulan sağlamlık raporu müşteriye sunulur ve onay alınmasının ardından veriler güvenli bir şekilde teslim edilir.

Veri kaybı yaşayan bir Linux sunucusu, NAS cihazı veya kurumsal sanal sunucu imajı DrDisk Lab Veri Kurtarma Merkezi laboratuvarına ulaştığında, süreç uluslararası standartlara (ISO 27001) uygun olarak şu mühendislik adımlarıyla yürütülür:

Donanımsal Yazma Engelleyici (Hardware Write-Blocker) ile Bağlantı

Diskler doğrudan standart bir bilgisayara takılmaz. Özel adli bilişim (forensic) donanımları olan Hardware Write-Blocker cihazlarına bağlanır. Bu cihazlar diske gidebilecek en ufak bir "Yazma" (Write) sinyalini donanımsal olarak engeller.

Bit-Stream (Bit-Bit) İmaj Alma

Orijinal disk üzerinde asla arama, tarama veya kurtarma işlemi yapılmaz!

PC-3000 Portable III / SAS / NVMe gibi endüstri standardı adli kopya cihazları kullanılarak diskin 0.sektöründen son sektörüne kadar birebir bit-stream imajı alınır. Orijinal disk kasaya kaldırılır; tüm mühendislik işlemleri bu yedek imaj üzerinde gerçekleştirilir.

LVM (Logical Volume Manager) ve Sanal Katmanların Çözülmesi

Linux sistemlerde genellikle diskler doğrudan kullanılmaz; LVM, LVM2, MDADM RAID (RAID 0, 1, 5, 6, 10) veya Ceph/GlusterFS gibi soyutlama katmanlarının üzerine EXT4 veya XFS kurulur.

Mühendislerimiz sanal yazılımlar yardımıyla öncelikle bu LVM haritasını ve RAID parametrelerini (Stripe Size, Parity Order, Block Offset) manuel olarak çözer.

Sanal Inode ve B+ Tree Haritasının Oluşturulması

Bozulmuş olan EXT4 Inode tabloları veya dağılmış XFS B+ Tree ağaçları, laboratuvarımızdaki özel mühendislik algoritmalarıyla taratılır. Boş alanlarda (Unallocated Space) kalan Inode parçaları ve dizin kalıntıları birleştirilerek, dosya sisteminin silinmeden önceki orijinal klasör hiyerarşisi sanal olarak yeniden inşa edilir.

Eğer sistem bir NAS cihazına aitse, arka plandaki özel Linux RAID mimarisini anlamak için NAS veri kurtarma ve RAID Veri Kurtarma rehberimizdeki adımlar da bu sürece entegre edilir.

Sıkça Sorulan Sorular (SSS)

1. EXT4 dosya sisteminde rm -rf ile silinen veriler %100 kurtarılabilir mi?

Eğer silme işleminden hemen sonra disk üzerindeki yazma faaliyetleri durdurulmuş ve bilgisayar/sunucu kapatılmışsa, JBD2 Journal kayıtları ve unallocated blok taraması sayesinde veri kurtarma oranı %90 - %98 seviyesindedir. Ancak diski kullanmaya devam etmek başarı oranını düşürür.

2. XFS dosya sisteminde xfs_repair -L çalıştırdım, verilerim geri gelir mi?

xfs_repair -L komutu log alanını ve bazı B+ Tree düğümlerini sıfırlar. Bu durum klasik dosya sistemi kurtarmayı zorlaştırsa da, laboratuvar ortamında Deep Allocation Group (AG) Carving ve ham imza taraması yapılarak verilerin çok büyük bir kısmı klasör isimleri olmasa dahi içerik olarak kurtarılabilmektedir.

3. Synology veya QNAP NAS cihazımdaki EXT4/XFS diski söküp Windows bilgisayara bağlasam dosyalarımı görebilir miyim?

Hayır. Windows işletim sistemi varsayılan olarak EXT4 ve XFS dosya sistemlerini tanımaz ve diski bağladığınızda size "Diski kullanabilmeniz için önce biçimlendirmeniz gerekiyor" uyarısı verir. Bu uyarıya kesinlikle 'Evet' dememelisiniz! Aksi takdirde diske format atılır ve kurtarma süreci karmaşıklaşır. (Benzer bir durumla karşılaştıysanız detaylar için Format Atılan Disk Kurtarma rehberimize göz atabilirsiniz).

4. Linux SSD sürücülerde (NVMe M.2) silinen veri kurtarılabilir mi?

SSD sürücülerde TRIM komutu aktifse, işletim sistemi silinen verilerin hücrelerini arka planda 0 ile doldurur. Ancak arızalanan veya çöken NVMe SSD'lerde mühendislik cihazlarıyla kontrolcü Techno Moduna alınarak veriler kurtarılabilir. Detaylı bilgi için NVMe SSD Veri Kurtarma makalemizi inceleyebilirsiniz.

Linux Verilerinizi Güvenle Geleceğe Taşıyın

EXT4 ve XFS dosya sistemleri, sundukları muazzam performans, yüksek ölçeklenebilirlik ve kararlılık ile bilişim dünyasının vazgeçilmez motorlarıdır. Ancak karmaşık Inode, Extent, B+ Tree ve Allocation Group mimarileri nedeniyle; bu sistemlerde yaşanan veri kayıpları standart kullanıcı düzeyindeki programlarla çözülemeyecek kadar ciddi mühendislik uzmanlığı gerektirir.

Bilinçsizce çalıştırılan komutlar (xfs_repair -L, e2fsck -y), hasarlı diske müdahale etmeye çalışmak veya üzerine yeni veriler yazmak, şirketinizin yıllarlık birikimini veya kritik veritabanlarını kalıcı olarak kaybetmenize yol açabilir.

Bir Linux sunucu çökmesi, NAS arızası veya veri kaybı ile karşılaştığınızda yapacağınız en güvenli adım; cihaza daha fazla elektrik vermeden sistemin gücünü kesmek ve profesyonel bir veri kurtarma merkezinden destek almaktır.

Türkiye'nin en gelişmiş adli bilişim ve veri kurtarma altyapısına sahip DrDisk Lab Veri Kurtarma Merkezi, uzman mühendis kadrosu ve Class 100 Cleanroom ortamı ile Linux (EXT4/XFS) sistemlerindeki en karmaşık vakalarda yanınızdadır.

Verilerinizi riske atmayın, profesyonel analiz için DrDisk Lab Ücretsiz Ön Analiz Formunu doldurarak uzmanlarımızla hemen iletişime geçin.

---

İlgili hizmetler: RAID ve NAS veri kurtarma · hard disk veri kurtarma