Sunucu Diskim Ölüyor mu? SMART Değerleri ve RAID'de Disk Değiştirme

Sunucu iki gündür tuhaf davranıyor. Yedekleme işi normalde 8 dakikada bitiyordu, dün 40 dakika sürdü. Bir MySQL sorgusu ara sıra saniyelerce takılıyor ama top çıktısında CPU boşta, bellek rahat. dmesg çıktısına baktığınızda cevabı buluyorsunuz:

[184223.117] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[184223.119] ata2.00: failed command: READ FPDMA QUEUED
[184223.121] blk_update_request: I/O error, dev sdb, sector 1953514576

Bu satırlar mantıksal bir sorun değil. Disk, kendisinden istenen sektörü okuyamadığını söylüyor. Bu noktada iki soru aynı anda cevap bekler: bu disk gerçekten ölüyor mu, yoksa geçici bir olay mı? Ve eğer ölüyorsa, RAID dizisindeki diski üretimi durdurmadan nasıl değiştirirsiniz?

Bu rehber ölçümden karara giden yolu izliyor. Önce smartctl çıktısında hangi değerin gerçekten alarm olduğunu — ve hangilerinin insanları boş yere paniklettiğini — ayıracağız. Sonra diski kendi kendine test ettireceğiz. Ardından mdadm tarafına geçip diski faulty işaretleme, çıkarma, yenisini bölümleyip ekleme ve rebuild sürecini yöneteceğiz. Sonda, bu işlemin en tehlikeli anını konuşacağız: rebuild sırasında ikinci diskin de ölmesi.

SMART Nedir ve Neyi Söyler, Neyi Söylemez?#

SMART (Self-Monitoring, Analysis and Reporting Technology), diskin kendi içinde tuttuğu bir sayaç ve öz-test altyapısıdır. Disk her okuma hatasında, her yeniden eşleme işleminde, her sıcaklık zirvesinde bu sayaçları günceller; siz de smartctl ile dışarıdan okursunuz.

SMART'ın söylemediğini baştan bilmek önemli. Google'ın veri merkezlerinde yüz binlerce disk üzerinde yaptığı saha çalışması, arızalanan disklerin %56'sının dört güçlü SMART uyarısının hiçbirini vermeden, %36'sının ise hiçbir SMART hatası kaydetmeden öldüğünü gösterdi. Yani temiz bir SMART çıktısı "bu disk sağlam" anlamına gelmez; sadece "disk bir sorun bildirmiyor" anlamına gelir.

Ama tersi çok daha güçlüdür: SMART bir şey söylüyorsa, ciddiye alın. Aynı çalışmada ilk düzeltilemeyen hatadan sonraki 60 gün içinde diskin arızalanma olasılığı 39 kat artmış durumdaydı. SMART düşük duyarlıklı ama yüksek isabetli bir sinyaldir.

Aracı kurup ilk bakışı atalım:

apt install -y smartmontools          # Debian/Ubuntu
dnf install -y smartmontools          # RHEL/Rocky/AlmaLinux

lsblk -d -o NAME,SIZE,ROTA,MODEL      # sistemdeki fiziksel diskler
smartctl -H /dev/sda                  # tek satırlık genel sağlık
smartctl -a /dev/sda                  # tüm öznitelikler ve hata günlüğü

⚠️ Disk bir donanım RAID kartının arkasındaysa /dev/sda diziyi temsil eder, tek bir diski değil. O durumda diskleri kartın üzerinden okumanız gerekir: smartctl -a -d megaraid,0 /dev/sda (LSI/MegaRAID) ya da smartctl -a -d cciss,0 /dev/sda (HP Smart Array). Sanallaştırılmış bir VDS'te ise disk sanal bir aygıttır ve SMART verisi genellikle hiç gelmez — fiziksel katman size ait değilse bu rehberin tespit kısmı sağlayıcınızın işidir.

smartctl Çıktısında Gerçekten Alarm Olan Değerler#

smartctl -a çıktısındaki öznitelik tablosu ilk bakışta korkutucudur, çünkü onlarca satır ve devasa ham değerler içerir. İşin sırrı, tabloya eşit muamele etmemektir. Sadece beş satır gerçekten karar verdirir:

Çıktıyı bu beş satıra indiren pratik komut:

smartctl -A /dev/sda | awk 'NR<8 || /Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|Reported_Uncorrect|Command_Timeout/'

Şöyle bir çıktı:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE     WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  -          0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   -          0
188 Command_Timeout         0x0032   100   100   000    Old_age   -          0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   -          24
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   -          24

Buradaki VALUE 100 sizi yanıltmasın; normalleştirilmiş değer eşiğin (THRESH) çok üstünde ve WHEN_FAILED boş olduğu için smartctl -H büyük ihtimalle PASSED diyecektir. Ama RAW_VALUE sütununda 24 bekleyen ve 24 düzeltilemeyen sektör var. Bu disk ölüyor. Karar RAW_VALUE sütununa bakarak verilir, genel sağlık satırına değil — "SMART PASSED diyor ama disk gitti" hikâyelerinin tamamı bu yanlış anlamadan doğar.

Ham Değeri Yanıltıcı Olan Öznitelikler#

Bazı satırlar milyonluk ham değerler gösterir ve yeni başlayanları paniğe sokar. Bunlar normaldir:

• Raw_Read_Error_Rate (1) ve Seek_Error_Rate (7): Seagate diskler bu alana iki ayrı sayacı paketler; ham değer 200 milyon görünebilir ve disk kusursuzdur. Marka bağımlı olduğu için mutlak sayı hiçbir şey ifade etmez.
• Hardware_ECC_Recovered (195): Diskin normal çalışma sırasında düzelttiği hataları sayar. Düzeltilmiş demek, sorun yok demektir.
• Power_On_Hours (9): Yaş göstergesidir, arıza göstergesi değil. 60.000 saatlik bir disk sağlam olabilir.
• UDMA_CRC_Error_Count (199): Diskin değil, kablonun sorunudur. Artıyorsa SATA kablosunu ya da backplane yuvasını değiştirin; diski değiştirmek bu sayacı durdurmaz.

Tek bir ölçüm de karar verdirmez. Önemli olan eğilimdir. Bugünkü değerleri kaydedin, bir hafta sonra tekrar bakın:

for d in /dev/sd?; do
  echo "== $d"
  smartctl -A "$d" | awk '$1==5 || $1==197 || $1==198 {printf "  %-24s %s\n", $2, $10}'
done

Sabit duran 8 realloc sektör, yıllarca sorun çıkarmayabilir. Bir haftada 8'den 40'a çıkan aynı değer, disk değiştirme kararıdır.

NVMe Disklerde Karşılığı Ne?#

NVMe diskler ATA öznitelik tablosunu kullanmaz; kendi sağlık günlüğünü sunar:

smartctl -a /dev/nvme0
nvme smart-log /dev/nvme0     # nvme-cli paketi

Burada bakılacak alanlar farklıdır:

Percentage Used %100'ü geçtiğinde disk aniden durmaz, ama garanti kapsamı biter ve yazma performansı düşer. SSD ile NVMe arasındaki performans farkının nerede hissedildiğine SSD mi NVMe mi yazımızda ayrıntılı baktık.

Diski Kendi Kendine Test Ettirmek: short ve long#

Öznitelikler geçmişi anlatır. Diskin şu anki durumunu öğrenmek için öz-test çalıştırın. İki tür vardır ve ikisi de üretimi durdurmaz — disk testi arka planda, normal G/Ç'nin arasında yapar:

# Hızlı tarama: 1-2 dakika, elektronik ve baş mekanizması kontrolü
smartctl -t short /dev/sdb

# Tam yüzey taraması: kapasiteye göre 1-8 saat, her sektör okunur
smartctl -t long /dev/sdb

# Süreyi tahmin et
smartctl -c /dev/sdb | grep -A2 'Extended self-test routine'

# Sonuçları oku
smartctl -l selftest /dev/sdb

Sonuç tablosu şuna benzer ve tek bir satır her şeyi söyler:

Num  Test_Description    Status                  Remaining  LifeTime  LBA_of_first_error
# 1  Extended offline    Completed: read failure       70%     41220   1953514576
# 2  Short offline       Completed without error        00%     41218   -

read failure ve bir LBA_of_first_error değeri gördüyseniz tartışma bitmiştir: disk, kendi yüzeyinde okuyamadığı bir yer olduğunu itiraf ediyor. Üstelik dmesg çıktısındaki sektör numarasıyla aynı LBA'yı görüyorsanız, belirtiyle sebep birebir eşleşmiş demektir.

Kısa test hatasız geçip uzun test kalıyorsa, sorun elektronikte değil manyetik yüzeydedir — bu, yavaş yavaş büyüyen tipik disk arızasının imzasıdır.

Sürekli İzleme: smartd#

Tek seferlik kontrol, sorunu ancak siz baktığınızda bulur. smartd servisi sayaçları düzenli izler ve değiştiklerinde e-posta atar:

# /etc/smartd.conf
DEVICESCAN -a -o on -S on -n standby,q \
  -s (S/../.././02|L/../../6/03) \
  -W 4,45,55 \
  -m root -M exec /usr/share/smartmontools/smartd-runner

Bu satır her gün saat 02:00'de kısa, her cumartesi 03:00'te uzun test çalıştırır; sıcaklık 45°C'yi geçtiğinde ve 4 derecelik ani değişimlerde uyarır. systemctl enable --now smartd ile devreye alın. Bir arıza sinyalini erkenden fark etmenin en ucuz yolu budur.

Karar Tablosu: Değiştirmeli miyim?#

Ölçümleri karara çevirmek için pratik bir eşik seti:

"Planlı değiştir" ile "acil değiştir" arasındaki fark önemlidir. Planlı değiştirmede diziyi bozmadan, yedeğiniz tazeyken, düşük trafik saatinde çalışırsınız. Acil durumda ise dizi zaten bozulmuş, tek diskle yürüyorsunuz ve hata payınız yok.

mdadm RAID'de Bozuk Diski Değiştirme#

Yazılım RAID kullanıyorsanız (Linux md), diziyi bozmadan disk değiştirmek yönetilebilir bir işlemdir. Önce durumu okuyun:

cat /proc/mdstat
mdadm --detail /dev/md0

Sağlıklı bir RAID 1 dizisi şöyle görünür:

md0 : active raid1 sdb1[1] sda1[0]
      1952996672 blocks super 1.2 [2/2] [UU]

[UU] iki üyenin de ayakta (Up) olduğunu söyler. Bir disk düştüğünde bu [U_] olur ve satırda (F) işareti belirir:

md0 : active raid1 sdb1[1](F) sda1[0]
      1952996672 blocks super 1.2 [2/1] [U_]

Değişmez kural: rebuild'e başlamadan önce güncel bir yedek alın. Bu bir formalite değil — aşağıda anlatacağımız nedenle rebuild, dizinin ömrü boyunca yaşadığı en riskli iştir ve tam da bozuk bir diskle çalışırken yapılır. Snapshot bunun yerine geçmez; nedenini snapshot mı yedek mi yazısında anlattık.

1. Adım: Diski faulty işaretleyip çıkarın#

Disk henüz kendiliğinden düşmediyse (sayaçlar kötü ama dizi hâlâ [UU]), önce siz işaretleyin:

mdadm --manage /dev/md0 --fail /dev/sdb1
mdadm --manage /dev/md0 --remove /dev/sdb1
cat /proc/mdstat        # [U_] görmelisiniz

Sunucuda birden fazla dizi varsa (/dev/md0 kök, /dev/md1 veri gibi), aynı fiziksel diskin tüm bölümlerini her diziden çıkarmanız gerekir. mdadm --detail --scan ve lsblk çıktısını yan yana koyup eksik bırakmayın.

2. Adım: Diski fiziksel olarak bulun ve değiştirin#

Yanlış diski çekmek, tek diskle çalışan bir dizide veri kaybı demektir. Seri numarasını not edin ve mümkünse LED'i yakın:

smartctl -i /dev/sdb | grep -Ei 'serial|model'
ledctl locate=/dev/sdb      # backplane destekliyorsa yuvayı yakar

Uzak veri merkezinde kendi donanımınız varsa bu adım "uzaktan el" (remote hands) talebine dönüşür; süreç ve maliyet tarafını colocation nedir yazısında ele aldık.

3. Adım: Yeni diskin bölüm tablosunu kopyalayın#

Yeni disk boş gelir. Bölüm düzenini sağlam diskten kopyalayın — elle bölmek hem yavaş hem hataya açıktır:

# GPT diskler
sgdisk --replicate=/dev/sdb /dev/sda    # sda'daki düzeni sdb'ye kopyala
sgdisk --randomize-guids /dev/sdb       # GUID çakışmasını önle

# MBR diskler
sfdisk -d /dev/sda | sfdisk /dev/sdb

partprobe /dev/sdb
lsblk /dev/sdb

⚠️ sgdisk --replicate argüman sırası sezgiye terstir: hedef disk seçeneğin içine, kaynak disk sona yazılır — yani --replicate=YENİ ESKİ. Ters yazarsanız sağlam diskin bölüm tablosunu boş diskin tablosuyla ezersiniz ve elinizde çalışan hiç disk kalmaz. Enter'a basmadan önce iki aygıt adını tek tek doğrulayın. Bölüm tablosu türleri ve araçların davranışı için disk bölümleme rehberi faydalı olacaktır.

4. Adım: Diziye ekleyin ve rebuild'i izleyin#

mdadm --manage /dev/md0 --add /dev/sdb1
watch -n5 cat /proc/mdstat

Rebuild başladığında satır şöyle olur:

md0 : active raid1 sdb1[2] sda1[0]
      1952996672 blocks super 1.2 [2/1] [U_]
      [==>..................]  recovery = 12.4% (242150912/1952996672) finish=189.3min speed=150612K/sec

finish= alanı tahmini kalan süredir. Çekirdek, üretimi ezmemek için rebuild hızını kısıtlar; sunucu boştaysa tavanı yükseltebilirsiniz:

cat /proc/sys/dev/raid/speed_limit_min   # varsayılan 1000 KB/s
cat /proc/sys/dev/raid/speed_limit_max   # varsayılan 200000 KB/s

echo 500000 > /proc/sys/dev/raid/speed_limit_max     # geçici
sysctl -w dev.raid.speed_limit_max=500000            # kalıcı için /etc/sysctl.d/

Kaba bir tahmin için kapasiteyi hıza bölün: 2 TB'lık bir diski 150 MB/s ile yeniden inşa etmek yaklaşık 3,7 saat sürer. Yoğun bir üretim sunucusunda gerçekleşen hız çok daha düşük olabilir; 8 TB'lık diskler için bir günü aşan rebuild süreleri sıradandır.

5. Adım: Önyükleyiciyi unutmayın#

Kök dizini RAID 1 üstündeyse, yeni disk önyüklenebilir değildir. Diğer disk öldüğünde sunucu açılmaz ve bunu ancak o gün fark edersiniz:

# BIOS/MBR
grub-install /dev/sdb

# UEFI: ESP bölümünü kopyalayıp ikinci girdiyi ekleyin
dd if=/dev/sda1 of=/dev/sdb1 bs=1M status=progress
efibootmgr -c -d /dev/sdb -p 1 -L "Ubuntu (disk2)" -l '\EFI\ubuntu\shimx64.efi'

Bu adım atlanırsa RAID'iniz veriyi korur ama açılışı korumaz. Sunucu açılmadığında kurtarma yollarını sunucu açılmıyor: kurtarma modu yazısında bulabilirsiniz.

Rebuild Sırasında İkinci Diskin Ölme Riski#

Rebuild, dizideki sağlam diskin her sektörünü baştan sona okumasını gerektirir. Normal çalışmada haftalarca dokunulmayan sektörler dahil, tamamı. Aynı partiden alınmış, aynı tarihte takılmış, aynı yükü görmüş bir disk için bu, ömrünün en ağır saatleridir — ve tam olarak yedeğiniz yokken gerçekleşir.

Risk iki biçimde ortaya çıkar. Diski tümden ölebilir; bu görülür ve dizi kaybedilir. Ya da tek bir sektörde düzeltilemeyen okuma hatası (URE) verir: RAID 5'te bu tek hata rebuild'i durdurmaya yeter, çünkü eksik veriyi hesaplayacak paritenin kaynağı okunamamıştır. Disk kapasiteleri büyüdükçe bir rebuild sırasında okunan toplam bit sayısı da büyür, dolayısıyla tek bir URE'ye rastlama olasılığı kapasiteyle birlikte artar. Büyük disklerde RAID 5'in artık önerilmemesinin nedeni budur.

Riski azaltmanın pratik yolları:

1. Rebuild öncesi yedek alın. Tek kural buysa bile yeter. Yedek sıklığı kararını ne sıklıkta yedek alınmalı yazısında ele aldık.
2. Kalan diski önce okuyun. smartctl -t long ile sağlam diski test edin; rebuild'in okuyacağı yüzeyi rebuild'den önce siz okumuş olursunuz.
3. RAID 6 veya RAID 10 kullanın. İkisi de rebuild sırasında bir diskin daha kaybını tolere eder.
4. Diskleri farklı partilerden alın. Aynı üretim partisinden diskler benzer zamanda arızalanma eğilimindedir.
5. Düzenli tutarlılık taraması yapın. Aylık check, sessizce bozulmuş sektörleri rebuild anına saklamak yerine erkenden ortaya çıkarır:

echo check > /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cnt     # 0 olmalı

Çoğu dağıtım bunu zaten aylık bir cron ya da systemd timer'ıyla çalıştırır; /etc/cron.d/mdadm dosyasına bakın ve devre dışı bırakmayın.

Son olarak: RAID bir yedekleme değildir. Silinen dosyayı, şifrelenen veriyi ya da bozulan veritabanını her iki diske de aynı anda yazar. Disk arızasına karşı süreklilik sağlar; veri kaybına karşı sizi koruyan şey ayrı bir ortamdaki yedeğinizdir. Bu iki kavramı birbirinin yerine koymak, disk değiştirmeyi öğrenmiş bir yöneticinin yaptığı en pahalı hatadır.

Sıkça Sorulan Sorular#

smartctl PASSED diyor ama disk yavaş, ne yapmalıyım?#

Genel sağlık satırı yalnızca normalleştirilmiş değerlerin üretici eşiğini aşıp aşmadığına bakar ve çoğu zaman iş işten geçene kadar PASSED der. smartctl -A çıktısında Reallocated_Sector_Ct, Current_Pending_Sector ve Reported_Uncorrect satırlarının ham değerlerini okuyun. Ardından smartctl -t long ile tam yüzey taraması çalıştırın; okuma hatası varsa test bunu açıkça bildirir.

Reallocated_Sector_Ct değerim 6, diski hemen değiştirmeli miyim?#

Hemen değil, ama izlemeye alın. Birkaç yeniden eşlenmiş sektör diskin normal ömrü içinde görülebilir ve yıllarca sabit kalabilir. Kritik olan değişimdir: değeri bugün kaydedin, bir hafta ve bir ay sonra tekrar bakın. Sayı artıyorsa yüzey bozulmaya devam ediyor demektir ve planlı bir değişim takvimlemelisiniz. Current_Pending_Sector sıfırdan farklıysa bekleme süresi biter.

RAID 1'de bir disk öldü, sunucuyu kapatmam gerekir mi?#

Hayır. Yazılım RAID ve hot-swap destekli donanımda disk değişimi çalışır durumda yapılır: bozuk üyeyi --fail ve --remove ile diziden çıkarır, diski değiştirir, bölüm tablosunu kopyalar ve --add ile geri eklersiniz. Hot-swap desteği olmayan bir kasada ise kapatmanız gerekir. Her durumda önce yedek alın, çünkü işlem boyunca tek disk üzerinde yürüyorsunuz.

RAID rebuild ne kadar sürer?#

Kaba tahmin, disk kapasitesinin rebuild hızına bölümüdür. Boş bir sunucuda 150 MB/s civarı bir hızla 2 TB yaklaşık 3-4 saat, 8 TB ise 14 saatin üstünde sürer. Üretim yükü altında hız belirgin biçimde düşer; /proc/mdstat çıktısındaki finish= alanı anlık tahmini gösterir. dev.raid.speed_limit_max değerini yükseltmek süreyi kısaltır ama disk G/Ç'sini uygulamalardan çalar.

Rebuild sırasında sunucuyu kullanabilir miyim?#

Kullanabilirsiniz, dizi bu süre boyunca erişilebilir kalır. Ancak disk G/Ç'si rebuild ile paylaşıldığı için uygulamalar yavaşlar ve rebuild uzar. Mümkünse yedekleme, log rotasyonu ve toplu içe aktarma gibi ağır işleri erteleyin. Bu dönemde diziniz yedeksiz çalıştığı için ikinci bir arıza veri kaybı anlamına gelir; süreci kısaltmak güvenliği doğrudan artırır.

VDS kullanıyorum, SMART kontrolü yapmalı mıyım?#

Sanal sunucuda disk sizin değil, sağlayıcının donanımı üzerinde duran sanal bir aygıttır; smartctl genellikle veri döndürmez veya anlamsız değerler verir. Fiziksel katmanı izlemek sağlayıcının sorumluluğundadır. Sizin tarafınızda yapılacak iş, dosya sistemi hatalarını ve dmesg çıktısındaki G/Ç uyarılarını izlemek ve düzenli yedek almaktır; olağandışı bir gecikme gördüğünüzde destek kaydı açın.