Disk Health Monitoring

Semua teknologi pada dua chapter sebelumnya — kolam LVM, array RAID — berdiri di atas satu asumsi: disk-disk di bawahnya masih hidup. Disk modern jarang mati mendadak; drive mencatat sendiri gejalanya — pemindahan sektor, percobaan baca yang gagal, suhu — dalam telemetri bernama SMART (Self-Monitoring, Analysis and Reporting Technology). Paket smartmontools membuka telemetri itu lewat perintah smartctl dan menjaganya tetap terpantau lewat daemon smartd. Chapter ini membaca atribut SMART yang benar-benar berarti, memasang pemantauan otomatis, lalu mengenali tanda-tanda awal kegagalan dari kernel log — karena mengganti disk menurut jadwal jauh lebih menyenangkan daripada memulihkan array RAID yang degraded dini hari.

SMART: Telemetri di Dalam Drive #

SMART adalah kumpulan penghitung yang dikelola firmware drive sendiri, bukan oleh Linux. Kernel hanya menyerahkan perintah baca ke drive, dan drive melaporkan angka-angkanya. Dua alat dari paket smartmontools menjadi jembatan kita: smartctl untuk membaca manual, dan smartd untuk memantau tanpa ditinggali. Sebelum memantau, kita perlu tahu drive mana saja yang ada; lsblk menjawabnya dalam sekali lihat:

lsblk -d -o NAME,SIZE,ROTA,TYPE
cat /sys/block/vda/queue/rotational

Output yang Dihasilkan:

NAME   SIZE ROTA TYPE
zram0    0B    0 disk
vda     10G    1 disk
pmem0  384M    0 disk
1

Kolom ROTA memisahkan dua jenis drive: angka 1 berarti piringan berputar (HDD), angka 0 berarti tanpa bagian bergerak (SSD). Baris kedua membaca properti yang sama langsung dari sysfs — 1 untuk vda di lingkungan latihan ini, tempat disk tampil sebagai perangkat virtual. Perlu dicatat: perangkat virtual dan USB kerap tidak meneruskan data SMART, jadi smartctl paling berguna pada disk SATA, SAS, dan NVMe yang terpasang langsung. Daftar kandidatnya bisa dilihat dengan sudo smartctl --scan.

Lima Atribut yang Layak Dipantau #

Laporan smartctl -a menampilkan puluhan atribut, tetapi hanya segelintir yang benar-benar menentukan. Tabel berikut adalah shortlist untuk drive mekanis:

Trio atribut — 5, 197, dan 198 — adalah penanda kematian yang paling sering muncul, sementara suhu dan umur menyediakan konteksnya. Memindai puluhan baris laporan secara manual melelahkan, jadi kita otomatisasi dengan awk. Berikut data contoh yang formatnya mengikuti tabel atribut smartctl:

cat > atribut-smart.txt <<'TABEL'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      RAW_VALUE
  5 Reallocated_Sector_Ct  0x0032   100   100   010    Pre-fail  0
  9 Power_On_Hours         0x0032   097   097   000    Old_age   28431
194 Temperature_Celsius    0x0022   068   054   000    Old_age   33 (0 24 0 0 0)
197 Current_Pending_Sector 0x0012   100   100   000    Old_age   12
198 Offline_Uncorrectable  0x0010   100   100   000    Old_age   12
TABEL
awk '$1==5 || $1==197 || $1==198 {
  print ($NF+0 > 0) ? "PERIKSA: " $2 " (raw = " $NF ")" : "AMAN: " $2 " (raw = " $NF ")"
}' atribut-smart.txt

Output yang Dihasilkan:

AMAN: Reallocated_Sector_Ct (raw = 0)
PERIKSA: Current_Pending_Sector (raw = 12)
PERIKSA: Offline_Uncorrectable (raw = 12)

Bedah baris per barisnya:

1. Baris 1-7 (cat > atribut-smart.txt <<'TABEL'): menulis data contoh berformat tabel atribut SMART — drive ini sudah bermasalah, terlihat dari dua angka 12 di baris 197 dan 198.
2. Baris 8 (awk '$1==5 || $1==197 || $1==198 { ... }'): menyaring hanya baris dengan nomor atribut 5, 197, atau 198.
3. Bagian print: $NF mengambil kolom terakhir (RAW_VALUE); tanda tanya terner memilih kalimat PERIKSA bila nilai tersebut di atas nol, atau AMAN bila nol.

Pada drive sungguhan, sumbernya tinggal diganti: sudo smartctl -A /dev/sda | awk ... — keluarannya persis pola yang sama, dan dua baris PERIKSA di hasil eksekusi kita berarti drive contoh itu layak dicurigai. Tren lebih penting daripada satu angka: Reallocated_Sector_Ct yang naik dari 4 ke 40 dalam sebulan jauh lebih menakutkan daripada angka 4 yang diam bertahun-tahun.

Membaca Laporan smartctl #

Perintah lengkapnya sederhana: sudo smartctl -a /dev/sda menampilkan seluruh telemetri — identitas drive, tabel atribut, riwayat self-test. Akses root umumnya wajib karena pembacaan SMART membutuhkan perintah mentah ke device. Berikut contoh tampilan tabel atribut pada drive yang sehat:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct  0x0032   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours         0x0032   097   097   000    Old_age   Always       -       28431
194 Temperature_Celsius    0x0022   068   054   000    Old_age   Always       -       33 (Min/Max 18/47)
197 Current_Pending_Sector 0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable  0x0010   100   100   000    Old_age   Always       -       0

Empat kolom tengah perlu diterjemahkan: VALUE adalah skor ternormalisasi yang berangkat dari 100 (semakin kecil semakin buruk), WORST adalah skor terendah yang pernah tercatat, THRESH adalah batas gagal dari pabrikan, dan RAW_VALUE adalah penghitung aslinya. Untuk atribut 5, 197, dan 198, kolom RAW_VALUE jauh lebih jujur daripada skor ternormalisasi. Untuk satu kesimpulan cepat, smartctl -H /dev/sda meringkas vonis drive dalam satu baris; berikut contoh tampilannya:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Vonis PASSED berarti firmware tidak melihat kondisi gagal-saat-ini — tetapi vonis itu tidak menutup kemungkinan sektor mulai dipindahkan, jadi tabel atribut tetap harus dibaca. Drive juga bisa menguji dirinya sendiri: sudo smartctl -t short /dev/sda menjalankan tes beberapa menit untuk kondisi mekanis dan elektronik, sedangkan -t long membaca seluruh permukaan piringan dan bisa berlangsung berjam-jam. Hasil keduanya tersimpan di drive dan dibaca ulang dengan smartctl -l selftest.

smartd: Pemantauan Otomatis #

Membaca laporan sekali tidak ada gunanya bila tidak ada yang membacanya besok. Daemon smartd mengecek setiap drive secara berkala dan mengirim laporan bila atribut memburuk atau vonis berubah. Perilakunya diatur di /etc/smartd.conf; baris berikut adalah konfigurasi minimal yang layak dipakai:

DEVICESCAN -m root -s (S/../.././03) -s (L/../../6/03)

Bedah setiap bagiannya: DEVICESCAN memerintahkan smartd memindai semua drive yang ditemukannya, -m root mengirim pesan peringatan ke user root (surel root biasanya diteruskan ke admin), sedangkan dua argumen -s mengatur jadwal self-test — (S/../.././03) menjalankan short test setiap hari pukul 03:00, dan (L/../../6/03) menjalankan long test setiap hari ke-6 dalam seminggu (Sabtu) pada jam yang sama. Setelah konfigurasi beres, daemon diaktifkan dengan:

sudo systemctl enable --now smartd

Di Debian dan turunannya unit systemd-nya bernama smartd; di Arch dan Fedora namanya smartmontools. Log smartd bisa diperiksa lewat journalctl -u smartd — pola yang sama dengan service lain di chapter Monitoring Logs . Rincian arti tiap atribut terdokumentasi di smartctl(8) , sintaks jadwal -s di smartd(8) , dan panduan praktisnya di halaman S.M.A.R.T. wiki Arch.

Tanda Awal di Kernel Log dan badblocks #

SMART bukan satu-satunya sumber gejala. Kernel yang kesulitan membaca disk mencatatnya di log: pesan I/O error, ata ... failed command, atau filesystem yang mendadak di-remount read-only. Perintah journalctl -k -g "I/O error" menyaring hanya pesan kernel tentang kegagalan I/O — muncul berulang berarti media penyimpanan sedang bergulat dengan sektor bermasalah. Gejala fisik juga tidak boleh diabaikan: bunyi klik berulang pada HDD menandakan lengan pembaca menyerah, dan transfer yang tiba-tiba lambat sering kali adalah drive yang sibuk mencoba ulang baca.

Alat klasik badblocks masih relevan untuk pengujian menyeluruh: sudo badblocks -sv /dev/sdb membaca seluruh permukaan disk sambil menampilkan kemajuannya (-s progress bar, -v hitungan error).

Pemantauan memberi kita waktu — tetapi waktu bukan perlindungan. Bila SMART mulai mengirim PERIKSA, langkah berikutnya bukan sekadar mengganti disk, melainkan memastikan data di dalamnya punya salinan di tempat lain. Merancang salinan itu, dari aturan 3-2-1 sampai uji restore rutin, adalah topik chapter berikutnya.