smartctl ve smartmontools: Eksiksiz Linux Sürücü Sağlığı İzleme Kılavuzu

smartctl, HDD’ler, SSD’ler ve NVMe sürücülerin firmware’ine gömülü S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) verilerini sorgulamak, test etmek ve yorumlamak için tasarlanmış smartmontools paketinin birincil komut satırı arayüzüdür. İşletim sisteminin standart I/O yolları aracılığıyla açığa çıkarmadığı ham tanısal telemetriyi ortaya çıkarmak için ATA, SCSI veya NVMe arayüzleri üzerinden doğrudan sürücü firmware’iyle iletişim kurar.

Fiziksel veya sanal depolamayı yöneten herhangi bir Linux yöneticisi için — ister bare-metal sunucuda, ister Dedicated Server‘da, ister yerel olarak bağlı bir disk dizisinde olsun — smartctl, kurtarılamaz veri kaybına yol açmadan önce yaklaşan sürücü arızasını tespit etmek için tek en güvenilir araçtır.

S.M.A.R.T. Nedir ve Neden Önemlidir

S.M.A.R.T., 1996 sonrasında üretilen neredeyse her tüketici ve kurumsal depolama cihazına yerleştirilmiş bir izleme sistemidir. Firmware düzeyinde çalışarak onlarca dahili parametreyi sürekli takip eder: okuma/yazma hata oranları, mekanik stres göstergeleri, NAND aşınma seviyeleri, yeniden tahsis edilmiş sektör sayıları ve termal okumalar.

Çoğu kılavuzun gözden kaçırdığı kritik ayrım: S.M.A.R.T. verileri reaktif değil, öngörücüdür. Bir sürücü, dosya sistemi kontrolünden geçebilir ve I/O’ya normal şekilde hizmet edebilirken aynı anda istatistiksel olarak haftalar içinde arızayı öngören bir hızda yeniden tahsis edilmiş sektörler biriktirebilir. smartctl bu gizli bozulma durumunu ortaya çıkarır.

S.M.A.R.T. üç depolama arayüzü ailesi üzerinde çalışır:

• ATA/SATA — orijinal S.M.A.R.T. spesifikasyonu, en zengin öznitelik içeriğine sahip
• SCSI/SAS — farklı bir öznitelik modeli kullanır (Informational Exceptions log sayfaları)
• NVMe — sağlık verilerini NVMe Health Information Log (Log Page 0x02) aracılığıyla sunar; mevcut yedek kapasite, kullanım yüzdesi ve güvensiz kapanmalar gibi metrikler içerir

Linux’ta smartmontools Kurulumu

smartmontools paketi, her büyük Linux dağıtımının resmi depolarında mevcuttur. Ortamınıza uygun sürümü yükleyin:

Debian / Ubuntu:

“`bash

sudo apt-get update && sudo apt-get install smartmontools

“`

CentOS / RHEL 7:

“`bash

sudo yum install smartmontools

“`

CentOS Stream / RHEL 8+ / AlmaLinux / Rocky Linux:

“`bash

sudo dnf install smartmontools

“`

Fedora:

“`bash

sudo dnf install smartmontools

“`

Arch Linux:

“`bash

sudo pacman -S smartmontools

“`

openSUSE:

“`bash

sudo zypper install smartmontools

“`

Kurulumdan sonra sürümü doğrulayın ve NVMe desteğinin derlendiğini onaylayın:

“`bash

smartctl –version

“`

Desteklenen cihaz türleri listesinde `NVMe` ifadesini arayın. 6.6 öncesi sürümlerde NVMe desteği eksiktir — NVMe SSD çalıştıran modern sunucularda smartmontools 7.x veya sonraki bir sürümü kullandığınızdan emin olun.

Depolama Cihazlarınızı Tanımlama

Herhangi bir smartctl komutu çalıştırmadan önce doğru cihaz düğümünü belirleyin. Çok diskli bir sistemde cihaz tanımlayıcılarını karıştırmak yaygın ve maliyetli bir hatadır.

“`bash

lsblk -d -o NAME,SIZE,MODEL,TRAN

“`

Bu komut, cihaz adlarını aktarım türüyle birlikte (sata, nvme, usb) çıktılar; bu da hangi smartctl bayraklarına ihtiyaç duyacağınızı doğrudan belirler. NVMe cihazlar için düğüm `/dev/nvme0`, `/dev/nvme1` vb. şeklinde görünür — `/dev/sdX` şeklinde değil.

Donanım RAID denetleyicileri (LSI MegaRAID, Adaptec, HP Smart Array) için sürücüler denetleyicinin arkasında gizlidir ve aşağıdaki gelişmiş bölümde ele alınan açık geçiş bayrakları gerektirir.

Temel smartctl Komutları

Cihaz Kimlik Bilgilerini Görüntüleme

“`bash

sudo smartctl -i /dev/sda

“`

Bu komut, cihazın IDENTIFY DATA sayfasını sorgular ve model numarası, seri numarası, firmware revizyonu, kapasite, sektör boyutu (512 baytlık mantıksal ile 4096 baytlık fiziksel — hizalama için önemli) ve S.M.A.R.T. yetenek bayraklarını döndürür. NVMe cihazlarda:

“`bash

sudo smartctl -i /dev/nvme0

“`

Tam Sağlık Değerlendirmesi Çalıştırma

“`bash

sudo smartctl -H /dev/sda

“`

Tek satırlık bir karar döndürür: `PASSED` veya `FAILED`. `FAILED` sonucu, sürücünün kendi firmware’inin bir veya daha fazla kritik eşiğin aşıldığını belirlediği anlamına gelir. FAILED rapor eden bir sürücü arızalı olarak değerlendirilmelidir — daha fazla onay beklemeyin.

Ancak `PASSED` sonucu sürücünün sağlıklı olduğu anlamına gelmez. Yalnızca hiçbir eşiğin resmi olarak aşılmadığı anlamına gelir. Bu nedenle ham öznitelik analizi zorunludur.

Tüm S.M.A.R.T. Özniteliklerini Görüntüleme

“`bash

sudo smartctl -A /dev/sda

“`

Bu, rutin kullanımda en yoğun bilgi içeren komuttur. Çıktı tablosu, kesin yorumlama gerektiren birkaç sütun içerir:

Öncelikli olarak analiz etmeniz gereken değer RAW_VALUE‘dur. Normalleştirilmiş VALUE/WORST/THRESH sistemi otomatik eşik tespiti için kullanışlıdır ancak yanıltıcı olabilir — bazı üreticiler standart dışı normalleştirme eğrileri kullanır.

Kapsamlı Çıktı: Bayrakları Birleştirme

Tek bir komutla eksiksiz bir görünüm elde etmek için bilgi, sağlık ve öznitelik bayraklarını birleştirin:

“`bash

sudo smartctl -a /dev/sda

“`

Küçük harf `-a` bayrağı `-H -i -c -A -l error -l selftest` ile eşdeğerdir. Bu, tanıdık olmayan bir sürücüyü teşhis ederken çalıştırılacak standart komuttur.

Tüm log sayfalarını içeren daha ayrıntılı bir çıktı için:

“`bash

sudo smartctl -x /dev/sda

“`

Kritik S.M.A.R.T. Öznitelikleri ve Bunların Yorumlanması

Tüm S.M.A.R.T. öznitelikleri eşit tanısal ağırlık taşımaz. Aşağıdakiler, deneyimli depolama mühendislerinin birincil arıza göstergeleri olarak değerlendirdiği özniteliklerdir:

Yüksek Öncelikli Arıza Göstergeleri

Reallocated_Sector_Ct (ID 5)

Sürücünün okuma/yazma/doğrulama hataları nedeniyle yedek alana yeniden eşlediği sektörlerin sayısı. İki yaşından küçük bir sürücüde sıfırdan farklı herhangi bir değer derhal dikkat gerektirir. Bir ay içinde 1’den 5’e bile olsa sürekli artan bir sayı, yaklaşan arızanın güçlü bir öngörücüsüdür. Kurumsal sürücülerde, üreticinin spesifikasyonuna bağlı olarak küçük bir sayı kabul edilebilir olabilir.

Current_Pending_Sector (ID 197)

Kararsız olarak işaretlenmiş ve yeniden eşleme bekleyen sektörler. Bu sektörler okuma sırasında hata üretmiş ancak henüz başarıyla yeniden eşlenememişlerdir. Burada sıfırdan farklı bir değer, sürücünün veri okumakta aktif olarak zorlandığı anlamına gelir. Bekleyen bir sektör daha sonra başarıyla yazılırsa yeniden eşlenebilir veya temizlenebilir — ancak altta yatan medya şüphelidir.

Uncorrectable_Sector_Count (ID 198) / Offline_Uncorrectable

ECC tarafından düzeltilememiş ve yeniden eşlenemeyen sektörler. Bu en ciddi özniteliktir. Burada sıfırdan farklı bir değer, o sektörlerden verinin zaten kaybolduğu anlamına gelir. Tek uygun yanıt, derhal yedek almak ve sürücüyü değiştirmektir.

Reported_Uncorrect (ID 187)

Modern sürücülerde bu, sürücünün dahili ECC’sinin düzeltemediği hataları sayar. Yüksek değerler ciddi medya bozulmasına işaret eder.

Spin_Retry_Count (ID 10)

HDD’ler için, plakaları çalışma hızına döndürmedeki tekrarlanan başarısızlıklar. Mil motoru veya yataklardaki mekanik stresi gösterir. Yoğun kullanımdaki bir sürücüde sıfırdan farklı herhangi bir değer kırmızı bayraktır.

Command_Timeout (ID 188)

Zaman aşımı nedeniyle iptal edilen komutların sayısı. Yüksek değerler genellikle medya arızasından ziyade arayüz sorunlarını (kablo, denetleyici veya güç dağıtımı) gösterir — ancak toplam sürücü arızasından önce de ortaya çıkabilirler.

İkincil İzleme Öznitelikleri

Raw_Read_Error_Rate (ID 1)

Sıklıkla yanlış okunur: Seagate sürücülerinde bu öznitelik, 48 bitlik bir alanda kodlanmış bir oranı temsil ettiğinden tasarım gereği çok yüksek ham değere sahiptir. Seagate sürücüsünde birkaç milyon ham değer normaldir. Western Digital ve diğer üreticilerde ham değer sıfıra yakın olmalıdır. Bu öznitelik için alarm vermeden önce her zaman üreticinin belgelerine başvurun.

Power_On_Hours (ID 9)

Toplam çalışma saati. Tüketici HDD’leri genellikle 20.000–25.000 saat (yaklaşık 2–3 yıl kesintisiz çalışma) için derecelendirilmiştir. Kurumsal sürücüler 55.000+ saat için derecelendirilmiştir. Diğer öznitelik değerlerini bağlamlandırmak için bunu kullanın.

Temperature_Celsius (ID 194)

Mevcut sürücü sıcaklığı. Çoğu HDD için optimum çalışma aralığı 25–45°C’dir. 55°C’nin üzerinde sürekli sıcaklıklar yatak aşınmasını ve manyetik medya bozulmasını hızlandırır. SSD’ler için termal tolerans genellikle daha yüksektir, ancak 70°C’nin üzerinde sürekli sıcaklıklar NAND aşınmasını hızlandırır. Yeterli hava akışı olmayan sunucularda — yoğun raf dağıtımlarında yaygın bir sorun — termal kısıtlama, sıcaklık özniteliği herhangi bir resmi eşiği geçmeden önce kendini I/O gecikmesi olarak gizleyebilir.

Wear_Leveling_Count (ID 177) / Media_Wearout_Indicator (ID 233)

NAND dayanıklılık tüketimini izleyen SSD’ye özgü öznitelikler. Normalleştirilmiş VALUE, THRESH değerine yaklaştığında SSD, derecelendirilen yazma dayanıklılığına yaklaşıyor demektir. Değiştirmeyi proaktif olarak planlayın.

Power_Cycle_Count (ID 12)

Sık güç döngüsü, HDD’lerde mekanik strese (kafa park etme/park kaldırma, mil motoru stresi) ve daha az ölçüde SSD’lerde elektriksel strese neden olur. Power_On_Hours’a göre alışılmadık derecede yüksek sayılar, kararsız bir güç ortamına işaret edebilir.

Tanısal Öz-Testleri Çalıştırma

S.M.A.R.T. öz-testleri, işletim sistemi tarafından değil, sürücünün kendi firmware’i tarafından yürütülür. Sürücü test sırasında I/O’ya hizmet etmeye devam eder (küçük bir performans etkisiyle), bu da bu testlerin üretim sistemlerinde çalıştırılmasını güvenli kılar.

Kısa Öz-Test

“`bash

sudo smartctl -t short /dev/sda

“`

Süre: genellikle 1–5 dakika. Elektriksel ve mekanik bileşenleri ve disk yüzeyinin küçük bir yüzdesini test eder. Hızlı bir akıl sağlığı kontrolü için kullanışlıdır. Tamamlandıktan sonra sonuçları görüntüleyin:

“`bash

sudo smartctl -l selftest /dev/sda

“`

Uzun Öz-Test (Genişletilmiş Test)

“`bash

sudo smartctl -t long /dev/sda

“`

Süre: sürücü kapasitesiyle orantılı — tipik bir 7200 RPM HDD’de terabayt başına yaklaşık 1 saat, çoğu SSD’de 20–60 dakika bekleyin. Her sektörün tam yüzey taramasını gerçekleştirir. Bu, tüm medya yüzeyindeki bozuk sektörleri tespit etmek için kesin testtir.

Tamamlanmasını beklemeden ilerlemeyi izleyin:

“`bash

sudo smartctl -c /dev/sda

“`

Çıktı, tamamlanma yüzdesi ve tahmini bitiş zamanı içerir.

Taşıma Öz-Testi

“`bash

sudo smartctl -t conveyance /dev/sda

“`

Çoğu ATA sürücüsünde mevcuttur. Nakliye veya fiziksel taşıma sırasında oluşan hasarı tespit etmek için tasarlanmıştır. Mekanik şoktan kaynaklanan sorunları kontrol eder. Süre genellikle 5 dakikadır. Bu test yeterince kullanılmıyor — yeni donanım devreye alınırken veya bir sunucu fiziksel olarak taşındıktan sonra özellikle değerlidir.

Seçici Öz-Test

“`bash

sudo smartctl -t select,0-1000000 /dev/sda

“`

Tüm sürücü yerine belirli bir LBA aralığının test edilmesine olanak tanır. Dosya sistemi kontrolleri belirli bir bölgede hata işaretlediğinde ve altta yatan medyanın sorumlu olup olmadığını doğrulamanız gerektiğinde çok değerlidir.

NVMe’ye Özgü Sağlık İzleme

NVMe sürücüler temelden farklı bir öznitelik modeli kullanır. Birincil sağlık komutu:

“`bash

sudo smartctl -a /dev/nvme0

“`

İzlenecek NVMe’ye özgü temel alanlar:

• Available Spare: Kalan yedek NAND bloklarının yüzdesi. %10’un altı, değiştirme planlamasını gerektirir.
• Available Spare Threshold: Üreticinin tanımladığı, altında sürücünün düşük güvenilirlik bildirebileceği eşik.
• Percentage Used: Tüketilen derecelendirilen yazma dayanıklılığının tahmini yüzdesi. %100’de sürücü, derecelendirilen TBW’sine (Yazılan Terabayt) ulaşmıştır — çalışmaya devam edebilir, ancak güvenilirlik garantileri artık geçerli değildir.
• Data Units Read / Written: 512.000 baytlık birimler halinde kümülatif I/O. Gerçek iş yükünü derecelendirilen TBW ile karşılaştırmak için kullanışlıdır.
• Media and Data Integrity Errors: NVMe denetleyicisi tarafından tespit edilen kurtarılamaz medya hataları veya veri bütünlüğü hataları. Sıfırdan farklı herhangi bir değer ciddidir.
• Number of Error Information Log Entries: Hata günlüğü girişlerinin sayısı. Hızla artan bir sayı kalıcı sorunlara işaret eder.
• Power State: Mevcut NVMe güç durumu — sürücünün derin güç tasarrufu durumunda olabileceği gecikmeye duyarlı iş yükleri için ilgilidir.

Donanım RAID ve Geçiş Erişimi

Sürücüler bir donanım RAID denetleyicisi aracılığıyla bağlandığında, işletim sistemi fiziksel sürücüleri değil denetleyicinin sanal diskini görür. smartctl, sürücü firmware’ine doğrudan ulaşmak için açık geçiş gerektirir.

LSI MegaRAID:

“`bash

sudo smartctl -a /dev/sda -d megaraid,0

sudo smartctl -a /dev/sda -d megaraid,1

“`

HP Smart Array (hpsa sürücüsü):

“`bash

sudo smartctl -a /dev/sda -d cciss,0

“`

3ware RAID:

“`bash

sudo smartctl -a /dev/twa0 -d 3ware,0

“`

Hangi geçiş türünü kullanacağınızdan emin değilseniz, smartctl otomatik algılamayı deneyebilir:

“`bash

sudo smartctl –scan

“`

Bu, algılanabilir tüm depolama cihazlarını tarar ve her biri için önerilen cihaz yolunu ve tür bayrağını çıktılar.

S.M.A.R.T.’ı Etkinleştirme ve Devre Dışı Bırakma

S.M.A.R.T., neredeyse tüm modern sürücülerde varsayılan olarak etkindir. Nadir durumlarda — genellikle eski sürücüler veya belirli sanallaştırılmış ortamlar — devre dışı bırakılmış olabilir:

“`bash

sudo smartctl -s on /dev/sda

“`

Devre dışı bırakmak için (belirli test senaryoları dışında önerilmez):

“`bash

sudo smartctl -s off /dev/sda

“`

Not: KVM veya VMware gibi sanallaştırılmış ortamlarda, misafir VM’lere S.M.A.R.T. geçişi hiper yönetici yapılandırmasına bağlıdır. Bir VPS Hosting ortamında, hiper yönetici genellikle fiziksel sürücüyü soyutlar ve misafir içindeki smartctl sınırlı veya hiç veri döndürmeyebilir. Tam S.M.A.R.T. erişimi için fiziksel ana bilgisayar düzeyinde izleme veya bir Dedicated Server gereklidir.

smartd ile Otomatik İzleme

smartd daemon’u, smartmontools’un üretim kalitesindeki bileşenidir. Arka planda çalışarak periyodik olarak sürücüleri sorgular ve zamanlanmış testleri yürütür, ardından eşikler aşıldığında veya test başarısızlıkları oluştuğunda yöneticileri uyarır.

/etc/smartd.conf Yapılandırması

Varsayılan yapılandırma, algılanan tüm sürücüleri temel ayarlarla izler. Üretime hazır sertleştirilmiş bir yapılandırma şöyle görünür:

“`

Monitor all ATA/SCSI/NVMe drives with full attribute checking

Run short test every day at 02:00, long test every Saturday at 03:00

Email alert on any failure or attribute change

DEVICESCAN -a -o on -S on

-s (S/../.././02|L/../../6/03)

-m admin@yourdomain.com

-M exec /usr/share/smartmontools/smartd-runner

“`

Temel direktifler açıklandı:

smartd’yi Etkinleştirme ve Başlatma

“`bash

sudo systemctl enable smartd

sudo systemctl start smartd

sudo systemctl status smartd

“`

Daemon’un aktif olarak izlediğini doğrulayın:

“`bash

sudo journalctl -u smartd -f

“`

E-posta Uyarı Yapılandırması

smartd e-posta uyarılarının çalışması için sistemin çalışan bir MTA’ya (posta aktarım aracısı) ihtiyacı vardır. Minimal sunucu kurulumlarında, aktarım için `postfix` veya `msmtp` yükleyip yapılandırın. Özel bir posta altyapısı kullanıyorsanız, uyarı teslimatının spam filtreleri tarafından engellenmemesini sağlamak için smartd uyarılarını düzgün yapılandırılmış bir Email Hosting hizmetiyle eşleştirmeyi düşünün.

S.M.A.R.T. Öznitelik Karşılaştırması: HDD – SSD – NVMe

Pratik İş Akışı: Şüpheli Bir Sürücüyü Teşhis Etme

Bir sürücü belirtiler gösterdiğinde — `dmesg`’da I/O hataları, dosya sistemi bozulması, olağandışı gecikme — şu tanısal sırayı izleyin:

Adım 1: S.M.A.R.T. kullanılabilirliğini onaylayın

“`bash

sudo smartctl -i /dev/sda | grep -i "SMART support"

“`

Adım 2: Genel sağlık kararını kontrol edin

“`bash

sudo smartctl -H /dev/sda

“`

Adım 3: Hata günlüğünü inceleyin

“`bash

sudo smartctl -l error /dev/sda

“`

Hata günlüğü, zaman damgaları ve LBA adresleriyle birlikte son 5 ATA hatasını kaydeder. Hataların kritik dosya sistemi yapılarını etkileyip etkilemediğini belirlemek için LBA adreslerini `debugfs` veya `xfs_db` kullanarak dosya sistemi blok haritalarıyla çapraz referanslayın.

Adım 4: Kritik öznitelikleri analiz edin

“`bash

sudo smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|Command_Timeout"

“`

Adım 5: Anında onay için kısa test çalıştırın

“`bash

sudo smartctl -t short /dev/sda

sleep 120

sudo smartctl -l selftest /dev/sda

“`

Adım 6: Kısa test geçerse ve belirtiler devam ederse, bakım penceresi sırasında uzun test çalıştırın

“`bash

sudo smartctl -t long /dev/sda

“`

Adım 7: LBA hata adresleri için öz-test günlüğünü inceleyin

“`bash

sudo smartctl -l selftest /dev/sda

“`

Başarısız testler, karşılaşılan ilk hatanın LBA’sını raporlar. Bu, medya hasarının tam konumunu belirler.

Yaygın Tuzaklar ve Uç Durumlar

USB bağlantılı sürücüler: smartctl, USB köprü çipi ATA komutlarını iletmediğinden USB-to-SATA adaptörleri aracılığıyla bağlanan sürücülerle genellikle iletişim kuramaz. `-d sat` veya `-d usb` bayrağını kullanın ya da köprü türünü açıkça belirtin (örn. `-d usb,0x0bc2,0x2312`). `–scan` bayrağı doğru türü otomatik olarak tanımlamaya çalışır.

Sanallaştırılmış ortamlar: KVM veya VMware misafirinin içinde `/dev/sda` sanal bir disktir. smartctl `Device does not support SMART` döndürebilir veya hiper yönetici tarafından iletilen yapay veriler döndürebilir. Paylaşımlı barındırma altyapısında fiziksel sürücü sağlığı değerlendirmesi için misafir içi smartctl çıktısına güvenmeyin.

Raw_Read_Error_Rate’te yanlış pozitifler: Yukarıda belirtildiği gibi, Seagate’in bu özniteliği kodlaması, tamamen normal olan alarmlı ham değerlere neden olur. Bu değer üzerinde işlem yapmadan önce her zaman üreticinin öznitelik belgelerine göre doğrulayın.

Yazılım RAID’in (mdadm) arkasındaki sürücüler: smartctl, RAID cihazına (`/dev/md0`) değil, bileşen sürücülere doğrudan erişir (`/dev/sda`, `/dev/sdb`). Her üye sürücüyü ayrı ayrı izleyin.

NVMe ad alanı ile denetleyici: Sağlık verileri için `/dev/nvme0n1` (ad alanı/blok cihazı) değil `/dev/nvme0` (denetleyici) kullanın. Bazı smartctl sürümleri her ikisini de kabul eder, ancak denetleyici düğümü sağlık günlüğü erişimi için yetkilidir.

Yalan söyleyen sürücüler: Özellikle düşük kaliteli QLC NAND sürücüler olmak üzere bazı tüketici SSD’lerinin, tam ve ani arızaya kadar sağlıklı S.M.A.R.T. öznitelikleri raporladığı belgelenmiştir. S.M.A.R.T. güçlü bir göstergedir ancak garanti değildir — düzenli yedeklemelerin yerini tutmaz.

Sunucu Ortamlarında smartmontools Dağıtımı

Birden fazla fiziksel sunucuyu yöneten yöneticiler için — Dedicated Server‘larda iş yükü çalıştıranlar gibi — S.M.A.R.T. izlemeyi merkezileştirmek zorunludur. Aşağıdaki mimariyi göz önünde bulundurun:

• Prometheus + node_exporter: `node_exporter`, S.M.A.R.T. özniteliklerini Prometheus metrikleri olarak dışa aktaran bir `smartmon` metin dosyası toplayıcı betiği içerir. Bu, Alertmanager aracılığıyla uyarı vermeyi ve Grafana panolarında görselleştirmeyi mümkün kılar.
• Nagios / Icinga2: `check_smart` eklentisi, geleneksel izleme yığınları için S.M.A.R.T. izleme entegrasyonu sağlar.
• Özel smartd betikleri: smartd.conf’taki `-M exec` direktifi, uyarıda herhangi bir betiği tetikleyebilir — PagerDuty, Slack webhook’ları veya özel bilet sistemleriyle entegrasyon için kullanışlıdır.
• Günlük dosyası toplama: smartd’yi syslog’a yazacak şekilde yapılandırın, ardından bir filo genelinde tarihsel eğilim analizi için merkezi bir günlük toplayıcıya (ELK yığını, Loki) iletin.

Kontrol paneli kullanan web barındırma ortamları için, VPS with cPanel dağıtımları, altyapı sağlayıcısı tarafından yapılandırılan ana bilgisayar düzeyinde S.M.A.R.T. izlemeden yararlanır; çünkü cPanel’in kendisi sürücü sağlığı verilerini yerel olarak sunmaz.

Temel Kontrol Listesi

Bunu ön dağıtım ve süregelen operasyonel referans olarak kullanın:

• smartmontools 7.x veya sonrasını yükleyin — tam NVMe ve modern SSD desteğini sağlamak için
• Yeni donanımda `smartctl –scan` çalıştırın — tüm sürücüleri ve gerekli arayüz bayraklarını tanımlamak için
• Önce `-H` sağlık kararını kontrol edin — `FAILED` sonucu, diğer özniteliklerden bağımsız olarak derhal işlem gerektirir
• Sıfırdan farklı herhangi bir Reallocated_Sector_Ct, Current_Pending_Sector veya Uncorrectable_Sector_Count’u arıza sinyali olarak değerlendirin — sayının artmasını beklemeyin
• Yalnızca Raw_Read_Error_Rate’e güvenmeyin — alarm vermeden önce üretici belgelerine göre doğrulayın
• Tüm üretim sürücülerinde smartd aracılığıyla haftalık otomatik uzun testler zamanlayın; kısa testleri günlük
• smartd e-posta uyarılarını yapılandırın ve bunlara güvenmeden önce teslimatı doğrulayın
• Donanım RAID için, her zaman uygun geçiş bayrağını kullanın — sanal diski izlemek, fiziksel sürücüleri izlemeye eşdeğer değildir
• Sanallaştırılmış ortamlarda, S.M.A.R.T. izlemeyi misafir VM’lerin içinde değil, hiper yönetici/ana bilgisayar düzeyinde gerçekleştirin
• S.M.A.R.T. izlemeyi bir yedekleme stratejisiyle eşleştirin — S.M.A.R.T. arızayı öngörür, veri kaybını önlemez
• NVMe sürücüler için, hata sayılarına ek olarak Available Spare ve Percentage Used’ı izleyin
• Çok sürücülü sunucularda, yerel e-posta teslimatına güvenmek yerine smartd’yi merkezi bir uyarı platformuyla entegre edin

Sıkça Sorulan Sorular

smartctl bir VPS veya bulut örneğinin içinde çalışır mı?

Çoğu VPS ortamında, hiper yönetici misafire sanal bir blok cihazı sunar. Misafirin içindeki smartctl ya hiç veri döndürmez ya da fiziksel sürücünün gerçek sağlığını yansıtmayan, hiper yönetici tarafından sentezlenmiş veriler döndürür. Anlamlı S.M.A.R.T. izleme, fiziksel ana bilgisayara erişim gerektirir. Tam sürücü düzeyinde görünürlük için Dedicated Server uygun çözümdür.

`smartctl -a` ile `smartctl -x` arasındaki fark nedir?

`-a` bayrağı standart S.M.A.R.T. veri kümesini çıktılar: cihaz bilgisi, sağlık kararı, yetenek bayrakları, tüm öznitelikler, hata günlüğü ve öz-test günlüğü. `-x` bayrağı, `-a`’ın sağladığı her şeye ek olarak seçici öz-test günlüğü, cihaz istatistikleri günlüğü, bekleyen kusurlar günlüğü ve ATA cihaz istatistikleri dahil ek günlük sayfalarını çıktılar — sürücü geçmişinin daha eksiksiz bir görünümünü sağlar. Kapsamlı teşhis için `-x`; rutin kontroller için `-a` kullanın.

Uzun öz-test ne kadar sürer ve üretim sürücüsünde çalıştırmak güvenli midir?

Süre, sürücü kapasitesine ve hızına bağlıdır: 7200 RPM HDD için terabayt başına yaklaşık 1 saat, çoğu SSD için 20–60 dakika. Test, sürücünün firmware arka planında çalışır ve sürücü test sırasında I/O’ya hizmet etmeye devam eder. Performans etkisi genellikle minimaldir (%5–15 verim azalması). Düşük trafikli dönemlerde üretim sistemlerinde çalıştırmak güvenlidir, ancak gecikmeye duyarlı iş yükleri için bakım penceresi sırasında zamanlamak önerilir.

Current_Pending_Sector sıfırdan farklıyken Reallocated_Sector_Ct artmamışsa ne anlama gelir?

Sürücü, okuma hatası üreten sektörleri tanımlamış ancak henüz başarıyla yeniden eşleyememiştir. Yeniden eşleme, sürücü sektöre yazabildiğinde gerçekleşir — ya bir yazma işlemi ya da çevrimdışı tarama aracılığıyla. Sayı sabit kalıyorsa, sektörler salt okunur bir bölgede olabilir veya sürücünün yeniden eşleme için kullanılabilir yedek sektörü kalmamış olabilir. Reallocated_Sector_Ct sabit kalırken sıfırdan farklı ve artan bir Current_Pending_Sector sayısı, sürücünün yedek sektör havuzunu tükettiğini gösterir — kritik bir arıza durumu.

smartctl, sürücü arızalanmadan önce SSD aşınmasını tespit edebilir mi?

Evet, SATA SSD’ler için Wear_Leveling_Count (ID 177), Media_Wearout_Indicator (ID 233) ve Available_Reservd_Space (ID 232) öznitelikleri NAND dayanıklılık tüketimini takip eder. NVMe SSD’ler için NVMe Health Information Log’undaki Percentage Used ve Available Spare alanları aynı amaca hizmet eder. Available Spare eşiğinin altına düştüğünde veya Percentage Used %100’e ulaştığında, sürücü derecelendirilen yazma dayanıklılığını tüketmiştir. Ani mekanik arızaların aksine, SSD aşınma bozulması kademeli ve son derece öngörülebilirdir — bu da onu proaktif S.M.A.R.T. izlemenin en güçlü kullanım durumlarından biri yapar.