Linux Dosya Sisteminde Hata Tespiti ve Kurtarma: fsck ve debugfs Kullanımı
Gecen ay bir müşterinin production sunucusunda tam gece yarısı paniğe yol açan bir durum yaşadım. Ext4 dosya sistemi bozulmuş, sistem açılmıyor, servisler ayağa kalkmıyor. Sabahın dördüne kadar fsck ve debugfs ile cebelleştim. O gece öğrendiklerimi ve yıllar içinde biriktirdiğim bilgileri burada paylaşmak istedim çünkü bu araçlar hakkında Türkçe kaynak gerçekten az.
Dosya Sistemi Bozulması Neden Olur?
Önce düşmanı tanıyalım. Dosya sistemi bozulması genellikle şu senaryolarda karşımıza çıkar:
- Ani güç kesintisi: En klasik neden. Disk yazma işlemi ortasında güç giderse journal bile her zaman kurtaramaz.
- Donanım sorunları: Hatalı RAM, bozulan disk sektörleri veya SATA kablolarındaki gevşeklik.
- Kernel panik veya sistem donması: Dosya sistemi unmount edilmeden sistem kapanıyor.
- Disk dolması: Full disk durumunda bazı metadata yazımları yarım kalabiliyor.
- Bug’lı sürücüler veya firmware: Özellikle eski SSD’lerde firmware bug’ları ciddi hasara yol açabiliyor.
Bozulmanın derecesi değişir. Kimi zaman sadece bir inode hatalı, kimi zaman superblock tamamen gitmş, kimi zaman orphaned inode’lar birikmiş. Her durum için yaklaşım farklı.
fsck’a Giriş: Temel Mantık ve Güvenlik
fsck (file system check) aslında bir wrapper. Arka planda fsck.ext4, fsck.xfs, fsck.btrfs gibi dosya sistemi özelinde araçları çağırıyor. Bu yüzden dosya sisteminizin türünü bilmek kritik.
Şunu çok net söyleyeyim: fsck’ı asla mount edilmiş bir dosya sistemi üzerinde çalıştırmayın. Bu kural o kadar temel ki, ama acil durumlarda insanlar unutuyor. Mount edilmiş sistemde fsck çalıştırmak bozulmayı düzeltmez, daha da kötüleştirir.
Hangi dosya sistemine hangi fsck’ın bakacağını görmek için:
ls -la /sbin/fsck*
# Çıktı:
# /sbin/fsck -> /bin/fsck
# /sbin/fsck.ext2
# /sbin/fsck.ext3
# /sbin/fsck.ext4
# /sbin/fsck.minixSisteminizdeki disklerin dosya sistemi türlerini öğrenmek için:
lsblk -f
# veya
blkid /dev/sda1Temel fsck Kullanımı
Sistemi rescue mode’a veya live USB’ye aldıktan sonra, hedef partitionı kesinlikle unmount edin ve ardından:
# Temel kontrol, sadece raporla düzeltme
fsck /dev/sdb1
# Otomatik düzeltme modu (evet/hayır sormadan)
fsck -y /dev/sdb1
# Ayrıntılı çıktı ile
fsck -v /dev/sdb1
# Dosya sistemi türünü elle belirt
fsck -t ext4 /dev/sdb1
# Dosya sistemi clean olsa bile zorla kontrol et
fsck -f /dev/sdb1Önemli parametreler:
- -y: Tüm sorulara otomatik “yes” cevabı verir. Prod sistemlerde dikkatli kullanın, bazen yanlış düzeltme yapabilir.
- -n: Salt okunur mod, sadece sorunları raporlar, hiçbir şeyi değiştirmez. Durum tespiti için mükemmel.
- -f: Force check. Dosya sistemi clean flag taşısa bile kontrolü zorlar.
- -c: Bad block taraması yapar ve bad block listesini günceller.
- -b superblock_no: Alternatif superblock kullanır. Bozuk superblock durumunda hayat kurtarır.
- -p: Preen modu. Güvenli düzeltmeleri otomatik yapar, tehlikeli olanlarda durur.
Superblock Bozulması: En Kötü Senaryo
Superblock dosya sisteminizin beyin merkezi. Burada inode tablosu konumu, block boyutu, UUID gibi kritik bilgiler var. Superblock bozulursa sistem diski tanıyamaz. Ama ext4 bu senaryoyu düşünmüş: yedek superblock’lar var.
Yedek superblock konumlarını bulmak için:
# Disk mount edilmemişse
dumpe2fs /dev/sdb1 | grep -i superblock
# Çıktıdan bir yedek block numarası alın, örneğin 32768
fsck -b 32768 /dev/sdb1
# Alternatif olarak mke2fs ile hesaplayabilirsiniz
mke2fs -n /dev/sdb1Gerçek hayatta bu komutu bir production ext4 sisteminde kullandım ve 8192 numaralı yedek superblock’tan kurtarma yapabildim. Sistem tekrar açıldı. O his tarifsiz.
fsck Çıktısını Okumak
fsck çalıştırdığınızda çıktı biraz karmaşık gelebilir. Şöyle bir çıktıyla karşılaşabilirsiniz:
fsck.ext4 -f /dev/sdb1
# e2fsck 1.46.5 (30-Dec-2021)
# Pass 1: Checking inodes, blocks, and sizes
# Inode 2849 has illegal block(s). CLEARED.
# Pass 2: Checking directory structure
# Pass 3: Checking directory connectivity
# Pass 4: Checking reference counts
# Pass 5: Checking group summary information
# Block bitmap differences: -(98305--98306)
# Fix? yes
# /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
# /dev/sdb1: 15/65536 files (0.0% non-contiguous), 8721/262144 blocks“FILE SYSTEM WAS MODIFIED” mesajını görürseniz, fsck bir şeyler düzeltti demek. Bu durumda fsck’ı bir kez daha çalıştırmanızı öneririm. İlk geçişte düzeltilen hatalar bazen ikincil sorunları tetikler.
lost+found Dizini
fsck bazen dosyaları kurtarır ama nereye koyacağını bilemez çünkü dizin bilgisi kaybolmuştur. Bu dosyalar /lost+found dizinine inode numarasıyla düşer. Örneğin #34521 gibi bir isimle.
ls -la /lost+found/
# Çıktı:
# drwx------ 2 root root 16384 Oca 15 03:22 .
# drwxr-xr-x 24 root root 4096 Oca 15 03:22 ..
# -rw-r--r-- 1 root root 8192 Oca 14 23:45 #34521
# -rw-r--r-- 1 root root 2048 Oca 14 23:45 #34522Bu dosyaların ne olduğunu anlamak için:
# Dosya tipini kontrol et
file /lost+found/#34521
# İçine bak
cat /lost+found/#34521
# String içeriği aramak için
strings /lost+found/#34521 | head -50Genellikle bu dosyaların çoğu işe yaramaz parçalardır ama kimi zaman kritik konfigürasyon dosyaları, loglar veya veri dosyaları çıkabilir.
debugfs: Dosya Sistemi Cerrahisi
debugfs fsck’ın daha cerrahi bir aleti. Ext2/3/4 dosya sistemleri için geliştirilmiş, düşük seviyeli bir debugger. Bu araçla silinen dosyaları kurtarabilir, hasar görmüş inode’ları inceleyebilir ve hatta elle düzeltmeler yapabilirsiniz.
Dikkat: debugfs yazma modunda açıldığında gerçekten tehlikeli olabilir. Eğer sadece inceleme yapacaksanız mutlaka read-only modda açın.
# Read-only modda aç (tavsiye edilen)
debugfs -R 'ls' /dev/sdb1
# Yazma modunda aç (dikkatli olun)
debugfs /dev/sdb1
# Journal'ı da açmak için
debugfs -c /dev/sdb1debugfs Komutları: Temel Repertuvar
debugfs interaktif modda çalışır. Açtıktan sonra bir prompt gelir:
debugfs /dev/sdb1
debugfs 1.46.5 (30-Dec-2021)
debugfs:En çok kullandığım komutlar:
# Dizin listele
debugfs: ls /home/kullanici
# Inode bilgilerini göster
debugfs: stat <inode_no>
# veya
debugfs: stat /etc/nginx/nginx.conf
# Silinen inode'ları listele
debugfs: lsdel
# Belirli bir dosyayı dışa aktar
debugfs: dump <inode_no> /tmp/recovered_file
# Inode'dan dosya adını bul
debugfs: ncheck <inode_no>
# Bir bloğun içeriğini göster
debugfs: block_dump <block_no>
# Journal'ı incele
debugfs: logdump -aSilinen Dosyaları Kurtarma: Gerçek Senaryo
Bir geliştirici rm -rf /var/www/html/uploads/ dedi, yedeği yoktu, ve bana geldi. Bu tam debugfs’in parladığı an.
Önce disk üzerindeki silme işlemini analiz etmek için:
debugfs /dev/sda1
debugfs: lsdelBu komut silinmiş inode’ları listeler. Çıktı şuna benzer:
Inode Owner Mode Size Blocks Time deleted
89231 0 100644 4521 2/2 Thu Jan 15 22:31:48 2024
89232 0 100644 12048 4/4 Thu Jan 15 22:31:48 2024
89233 0 100644 8192 2/2 Thu Jan 15 22:31:48 2024Silme zamanları eşleşiyorsa bunlar büyük ihtimalle aynı anda silinen dosyalardır. Her birini kurtarmak için:
debugfs: dump <89231> /tmp/recovered_89231
debugfs: dump <89232> /tmp/recovered_89232Daha büyük ölçekli kurtarma için bir script yazabilirsiniz:
# Tüm silinmiş inode'ları kurtarma scripti
debugfs -R 'lsdel' /dev/sda1 2>/dev/null | awk 'NR>1 && $1 ~ /^[0-9]+$/ {print $1}' | while read inode; do
debugfs -R "dump <$inode> /tmp/recovery/$inode" /dev/sda1 2>/dev/null
echo "Kurtarıldı: $inode"
doneBu scripti çalıştırmadan önce /tmp/recovery/ dizinini oluşturun ve hedef diskte yeterli alan olduğundan emin olun.
Inode Bilgilerini Derinlemesine İnceleme
Bir dosyanın neden erişilemiyor olduğunu anlamak için inode incelemesi çok değerli:
debugfs /dev/sdb1
debugfs: stat /etc/passwd
# Çıktı şuna benzer:
# Inode: 12 Type: regular Mode: 0644 Flags: 0x80000
# Generation: 3849234234 Version: 0x00000000:00000001
# User: 0 Group: 0 Project: 0 Size: 2847
# File ACL: 0
# Links: 1 Blockcount: 8
# Fragment: Address: 0 Number: 0 Size: 0
# ctime: 0x65a4b2c1:00000000 -- Mon Jan 15 10:22:25 2024
# atime: 0x65a4b2c1:00000000 -- Mon Jan 15 10:22:25 2024
# mtime: 0x65a4b2c1:00000000 -- Mon Jan 15 10:22:25 2024
# EXTENTS:
# (0): 98305Link count 0 olan ama boyutu 0’dan büyük olan inode’lar orphaned durumda demektir. Bunlar fsck’ın lost+found’a taşıdığı dosyalar olur.
dumpe2fs ile Dosya Sistemi Analizi
debugfs’i tamamlayan bir araç daha var: dumpe2fs. Bu araç dosya sisteminin genel sağlık durumunu ve metadata’sını gösterir.
# Tüm bilgileri göster
dumpe2fs /dev/sdb1
# Sadece superblock bilgisi
dumpe2fs -h /dev/sdb1
# Group descriptor bilgisi
dumpe2fs /dev/sdb1 | grep -A5 "Group 0:"Özellikle şu bilgilere bakın:
dumpe2fs -h /dev/sdb1 | grep -E "Filesystem state|Last mount|Last checked|Mount count|Maximum mount count|Errors"Filesystem state: clean görüyorsanız genel olarak iyi durumdasınız demektir. Errors detected görüyorsanız acil müdahale gerekiyor.
Boot Sırasında Otomatik fsck
/etc/fstab dosyasındaki son iki sayı (dump ve pass) fsck davranışını etkiler:
cat /etc/fstab
# UUID=xxxx-xxxx / ext4 defaults 1 1
# UUID=yyyy-yyyy /home ext4 defaults 1 2
# UUID=zzzz-zzzz /data ext4 defaults 1 2- Pass 0: fsck bu partitionu hiç kontrol etmez
- Pass 1: Root partition için, ilk kontrol edilir
- Pass 2: Diğer partitionlar, sonra kontrol edilir (paralel çalışabilir)
Systemd kullanan modern sistemlerde systemd-fsck devreye girer. Durumunu şöyle görebilirsiniz:
systemctl status [email protected]
journalctl -u [email protected]Önleyici Tedbirler ve İzleme
Bozulma olduktan sonra müdahale etmek yerine önceden önlem almak her zaman daha iyidir.
Disk sağlığını düzenli izlemek için:
# SMART verileri kontrol et
smartctl -a /dev/sda
# Kısa self-test başlat
smartctl -t short /dev/sda
# Uzun self-test (saatler alabilir)
smartctl -t long /dev/sda
# Test sonuçları
smartctl -l selftest /dev/sdaDosya sistemi hata istatistiklerini izlemek için:
# Ext4 hata sayaçları
tune2fs -l /dev/sda1 | grep -i error
# Kernel mesajlarında disk hataları
dmesg | grep -i -E "error|I/O|ata|sd[a-z]" | tail -30
# Systemd journal'dan disk hataları
journalctl -k | grep -i -E "ata|scsi|nvme" | grep -i errorPeriyodik fsck için bir cron job yerine tune2fs ile mount sayacı veya zaman bazlı otomatik kontrol ayarlayabilirsiniz:
# Her 30 mount'ta bir fsck zorla
tune2fs -c 30 /dev/sdb1
# Her 30 günde bir fsck zorla
tune2fs -i 30d /dev/sdb1
# Mevcut ayarları görüntüle
tune2fs -l /dev/sdb1 | grep -E "Mount count|Check interval|Next check"XFS Dosya Sistemleri İçin
Eğer XFS kullanıyorsanız (RHEL/CentOS varsayılanı artık XFS), araçlar farklı:
# XFS dosya sistemi kontrol ve onarım
xfs_repair /dev/sdb1
# Salt okunur kontrol
xfs_repair -n /dev/sdb1
# XFS bilgi göster
xfs_info /dev/sdb1
# XFS debug
xfs_db /dev/sdb1XFS’te bir önemli not: xfs_repair mount edilmiş dosya sistemi üzerinde çalışmaz ve çalıştırılmamalıdır. Aynı kural geçerli.
Kurtarma Senaryosu: Root Partition Bozulması
En korku senaryosu: root partition bozulmuş, sistem açılmıyor. Adım adım yaklaşım:
# 1. Live USB ile boot et
# 2. Hangi disk olduğunu bul
lsblk
fdisk -l
# 3. Dosya sistemi türünü belirle
blkid /dev/sda1
# 4. Kesinlikle mount etme, direkt fsck çalıştır
fsck -f -y /dev/sda1
# 5. Hata devam ediyorsa yedek superblock dene
dumpe2fs /dev/sda1 | grep "Backup superblock"
fsck -b 32768 -y /dev/sda1
# 6. fsck temiz rapor verene kadar tekrar çalıştır
fsck -f /dev/sda1
# 7. Temizse mount et ve kontrol et
mount /dev/sda1 /mnt
ls /mnt
# 8. Kritik dosyaları yedekle
rsync -av /mnt/etc /backup/
rsync -av /mnt/home /backup/Sonuç
fsck ve debugfs Linux sistem yönetiminin olmazsa olmaz araçlarıdır. Yıllar önce bu araçları öğrenmek için mükemmel bir zamanım olmasını dilerdim, çünkü ilk ciddi disk bozulmasıyla karşılaştığımda saatlerce boşa harcadım.
Birkaç temel kural aklınızda kalsın: mount edilmiş dosya sistemi üzerinde asla fsck çalıştırmayın, -n parametresiyle önce salt okunur kontrol yapın, ve bir düzeltme işleminden önce mümkünse disk imajı alın (dd if=/dev/sdb1 of=/backup/sdb1.img). Yedek superblock bilgilerini önceden not edin, çünkü bozulma anında o bilgiye erişemeyebilirsiniz.
En önemlisi: bu araçları bir kriz anında ilk kez denemeyin. Test ortamında kasıtlı olarak dosya sistemi bozulması simüle edin, üzerinde pratik yapın. Sanal makine üzerinde ext4 formatlanmış bir disk alın, loop device ile bağlayın, birkaç byte’ı hex editörüyle bozun ve sonra kurtarmayı deneyin. O pratik sizi gerçek krizde saatler kurtarır.