Kesehatan Disk SMART di Home Server Debian - Membaca Peringatan Tanpa Menganggapnya Ramalan

Ditulis oleh Adam Muiz 28 Aug 2026 Diperbarui: 28 Aug 2026 9 menit baca

Home server dapat terus menjawab request HTTP saat salah satu drive diam-diam mengumpulkan error. Hal ini memunculkan pertanyaan praktis: bisakah SMART memberi peringatan cukup awal agar kita sempat bertindak, dan seberapa besar kepercayaan yang pantas diberikan pada laporannya?

Jawaban yang hati-hati bukan "SMART tahu kapan disk akan mati" maupun "SMART tidak berguna." SMART adalah sumber bukti yang dilaporkan perangkat. Sebagian bukti menuntut respons segera, sebagian baru bermakna sebagai tren, dan sebagian sulit dibandingkan antar-vendor. Karena itu, rutinitas monitoring yang berguna perlu menggabungkan SMART dengan backup yang sudah diuji, pemeriksaan filesystem dan aplikasi, serta rencana penggantian storage yang mencurigakan.

SMART adalah bukti, bukan jam hitung mundur

Project smartmontools menyediakan dua tool utama: smartctl untuk memeriksa perangkat dan memulai self-test yang didukung, serta smartd untuk monitoring berkelanjutan. Tool tersebut mencakup storage ATA/SATA, SCSI/SAS, dan NVMe, tetapi bukan berarti setiap perangkat menampilkan field yang sama atau menggunakan makna yang sama.

Perbedaan ini paling penting pada attribute ATA. Menurut manual smartctl, firmware drive menyediakan raw value, normalized value, threshold, dan jenis attribute; smartctl melaporkannya. Konversi raw value menjadi satuan fisik tidak distandardisasi, dan makna attribute menjadi khusus vendor dalam spesifikasi ATA yang lebih baru. Karena itu, angka mentah besar yang disalin dari forum tidak otomatis menjadi ambang kegagalan universal.

Hasil kesehatan keseluruhan tetap berguna. Status gagal yang dilaporkan merupakan sinyal mendesak untuk menyelidiki dan memindahkan data penting ke tempat aman. Kebalikannya lebih lemah: hasil lulus berarti perangkat belum menyatakan kegagalan melalui pemeriksaan tersebut, bukan berarti setiap sector, kabel, controller, filesystem, dan write di masa depan pasti aman.

Sebuah field study yang sering dikutip membantu menjelaskan ketidakseimbangan itu. Dalam Failure Trends in a Large Disk Drive Population, peneliti yang memeriksa lebih dari 100.000 HDD kelas konsumen menemukan bahwa beberapa sinyal SMART berkorelasi dengan kegagalan. Mereka juga menyimpulkan bahwa parameter SMART saja kemungkinan tidak dapat memprediksi kegagalan individual secara akurat karena banyak drive yang gagal tidak menunjukkan sinyal kuat yang mereka teliti. Paper tersebut terbit pada 2007 dan membahas hard drive ATA di lingkungan data center Google. Temuan itu mendukung sikap hati-hati, bukan kalkulator risiko yang presisi untuk SSD, perangkat NVMe, atau home server modern.

Mulai dengan mengenali perangkat yang sebenarnya

Di Debian, package ini tersedia dengan nama smartmontools:

sudo apt update
sudo apt install smartmontools

Jangan memulai dengan menganggap system disk pasti /dev/sda. Linux dapat menampilkan perangkat SATA atau SAS sebagai /dev/sdX, sedangkan controller atau namespace NVMe sebagai /dev/nvmeX atau /dev/nvmeXnY. Nama perangkat juga dapat berbeda antar-mesin atau saat boot. Biarkan tool melakukan scan terlebih dahulu:

sudo smartctl --scan-open

Opsi --scan-open melakukan scan dan mencoba membuka perangkat, yang dapat memperbaiki deteksi jenisnya. Catat model, serial number, dan path whole-device sebelum melanjutkan. Partition seperti /dev/sda1 tidak dapat dipertukarkan dengan perangkat induknya, /dev/sda.

Ada edge case penting: enclosure USB, adapter SATA-to-USB, atau RAID controller mungkin tidak meneruskan command yang dibutuhkan dengan baik. Manual mendokumentasikan bentuk device type untuk bridge dan controller yang didukung, tetapi memaksakan nilai -d berdasarkan tebakan bukan ritual troubleshooting tanpa risiko. Beberapa mode bridge low-level yang didokumentasikan membawa peringatan tegas. Kenali controllernya dan baca dokumentasinya alih-alih mencoba berbagai type secara acak.

Baca laporan secara berlapis

Setelah mengganti /dev/sdX dengan path whole-device yang sudah diverifikasi, minta laporan lengkap:

sudo smartctl -a /dev/sdX

Output persisnya berbeda antara perangkat ATA, SCSI, dan NVMe. Alih-alih mencari satu angka ajaib, bacalah secara berlapis.

1. Identitas dan dukungan

Pertama, pastikan laporan berasal dari model dan serial number yang dimaksud, device type terdeteksi dengan benar, dan informasi kesehatan tersedia. Jika identitasnya salah atau akses SMART tidak didukung, penafsiran berikutnya tidak memiliki dasar yang dapat diandalkan.

2. Kesehatan keseluruhan dan critical warning

Status kesehatan yang gagal atau critical warning NVMe harus segera ditangani. Jangan menghabiskan waktu berjam-jam menyetel dashboard saat satu-satunya salinan data penting masih berada pada perangkat yang mencurigakan. Amankan data lebih dahulu, baru lakukan diagnosis.

3. Error log dan self-test log

Cari error perangkat baru dan self-test yang gagal, termasuk kapan hal itu terjadi. Konteks penting: satu entri lama yang tidak pernah muncul lagi berbeda dengan error yang terus bertambah selama penggunaan normal. Keduanya juga tidak boleh dihapus dari pertimbangan hanya karena status keseluruhan masih mengatakan PASS.

4. Attribute khusus perangkat

Untuk disk ATA, sector yang direalokasi, pending, atau tidak dapat dikoreksi patut diselidiki, terutama saat count baru muncul atau meningkat. Namun, ID attribute, nama, encoding, dan threshold dapat berbeda menurut model. Interface error terkait CRC mungkin mengarah ke kabel atau koneksi, bukan media yang rusak. Temperatur berguna sebagai konteks operasional, tetapi satu pembacaan tidak boleh diubah menjadi prediksi kegagalan universal.

Output kesehatan NVMe menggunakan model berbeda, dengan field seperti critical warning, available spare, percentage used, temperature, media/data-integrity errors, dan error-log entries jika didukung. Memaksakan checklist attribute ATA pada laporan NVMe akan menyesatkan. Dalam kedua kasus, simpan laporan dari waktu ke waktu: perubahan bisa lebih informatif daripada satu nilai asing yang berdiri sendiri.

Jalankan self-test, lalu kembali untuk membaca hasilnya

SMART self-test berjalan di dalam perangkat. Short test biasanya memeriksa fungsi yang terbatas; long atau extended test memeriksa bagian perangkat yang lebih luas dan dapat berlangsung jauh lebih lama. Tinjau capability pada laporan lengkap untuk mengetahui apa yang didukung perangkat dan perkiraan durasi test.

Mulai short test:

sudo smartctl -t short /dev/sdX

Command tersebut memulai test; command itu tidak membuktikan bahwa test selesai dengan sukses. Tunggu hingga perkiraan waktu selesai yang ditampilkan tool, lalu periksa self-test log:

sudo smartctl -l selftest /dev/sdX

Jika hasil short test dan konteks workload membenarkan pemeriksaan lebih dalam, mulai long test dan baca log yang sama setelahnya:

sudo smartctl -t long /dev/sdX
sudo smartctl -l selftest /dev/sdX

Self-test dapat memengaruhi performance, dan dukungannya berbeda menurut perangkat. Jadwalkan long test di luar workload sensitif, tetapi jangan menganggap waktu idle menjamin dampak nol. Ingat juga apa yang benar-benar dibuktikan test sukses: perangkat menyelesaikan test yang didukung pada waktu itu. Hasil tersebut tidak memvalidasi filesystem, memeriksa setiap record aplikasi, atau melakukan restore backup.

Ubah pemeriksaan sesekali menjadi monitoring

Pemeriksaan manual mudah terlupakan. Manual smartd menjelaskan daemon yang secara berkala melakukan polling perangkat, mencatat perubahan dan error melalui syslog, serta dapat menjalankan mekanisme peringatan. Konfigurasinya biasanya dibaca dari /etc/smartd.conf.

Titik awal yang sengaja dibuat minimal adalah:

DEVICESCAN -a

Manual smartd.conf menyatakan bahwa baris ini melakukan scan perangkat yang tersedia dan menerapkan monitoring luas. Minimal bukan berarti benar untuk semua keadaan. Entri eksplisit per perangkat lebih baik ketika server memiliki bridge, controller, removable media, atau disk dengan jadwal berbeda. Validasi konfigurasi dan periksa service log setelah mengaktifkannya; monitoring yang tidak dapat melihat perangkat atau menyampaikan peringatan akan menciptakan rasa aman palsu.

Power management menghadirkan tradeoff lain. Polling rutin dapat membangunkan disk ATA yang sedang sleep. Directive -n standby dapat melewati pemeriksaan saat perangkat berada dalam standby, meskipun deteksi device type atau pemeriksaan power mode yang tidak didukung masih dapat berperilaku berbeda. Operator server perlu memilih antara pengamatan cepat dan mempertahankan perilaku spin-down yang disengaja, bukan menganggap keduanya berlangsung otomatis.

Format konfigurasi juga dapat menjadwalkan short dan long self-test, tetapi sintaks waktu yang mirip regular expression mudah salah ketik. Menyalin jadwal rumit tanpa memahaminya kurang andal dibanding memulai dari monitoring, membaca manual, dan memverifikasi jadwal yang dihitung daemon.

Tanggapi dengan tangga tindakan

Sistem monitoring hanya berguna jika sebuah sinyal mengubah keputusan. Respons yang hati-hati dapat disusun sebagai tangga:

Pastikan identitas dan jalur transport. Pastikan alert merujuk pada perangkat fisik yang benar dan bukan kesalahpahaman passthrough atau kabel.
Amankan data penting. Jika status kesehatan gagal, self-test gagal, data tidak dapat dibaca, atau error serius meningkat, prioritaskan menyalin data yang tidak tergantikan ke storage independen. Jangan membebani disk yang jelas tidak stabil hanya demi mendapatkan laporan yang lebih rapi.
Periksa bukti independen. Tinjau kernel log, laporan filesystem, error aplikasi, status controller, kabel, dan daya. SMART melihat sudut pandang perangkat, bukan seluruh jalur storage.
Verifikasi backup dengan melakukan restore. Pesan keberhasilan backup job adalah bukti yang lebih lemah daripada membaca file hasil restore dari perangkat lain.
Rencanakan penggantian. Bukti masalah media yang berulang atau memburuk seharusnya menurunkan ambang untuk mengganti drive. Menunggu prediksi definitif berarti meminta kepastian yang memang tidak dimiliki SMART.
Dokumentasikan baseline. Simpan laporan bertanggal beserta model dan serial number perangkat agar perubahan selanjutnya dapat dibandingkan pada unit yang sama.

Tangga ini sengaja menghindari rumus universal seperti "ganti pada raw value N." Dokumentasi produsen, warranty diagnostic, toleransi workload, redundancy, dan kualitas backup dapat mengubah keputusan. Drive yang menyimpan cache sekali pakai dan drive yang menyimpan satu-satunya arsip keluarga tidak seharusnya memiliki ambang risiko yang sama.

Apa yang tidak dijawab SMART

SMART tidak dapat memastikan apakah backup bisa dipulihkan. SMART sendiri tidak dapat mendeteksi setiap masalah controller, kabel, RAM, filesystem, encryption, atau tingkat aplikasi. Perangkat dapat gagal tanpa sinyal awal yang berguna, sedangkan perangkat lain dapat terus bekerja setelah suatu attribute berubah. Virtual disk dan beberapa hardware controller mungkin hanya menampilkan abstraksi, bukan setiap drive fisik.

Ada pula masalah seleksi dalam bukti yang tersedia. Studi besar tahun 2007 itu tetap berguna karena menguji asumsi umum terhadap field data, tetapi model HDD, workload, dan lingkungannya bukan armada home server masa kini. Studi tersebut sebaiknya membentuk pertanyaan - "sinyal mana yang muncul, dan dengan apa sinyal itu berkorelasi pada populasi tersebut?" - bukan menyediakan probabilitas abadi untuk perangkat yang berbeda.

Kontra-argumennya adalah bahwa sinyal yang tidak pasti dapat menghasilkan alert fatigue dan penggantian yang tidak perlu. Itu risiko yang nyata. Jawabannya bukan mengabaikan SMART, melainkan mempertahankan konteks: pantau perubahan, bedakan bukti masalah media dari interface error, verifikasi alert, dan pilih tindakan berdasarkan nilai data serta biaya downtime.

Kesimpulan

SMART paling tepat diperlakukan seperti lampu peringatan, bukan bola kristal. Temukan perangkat yang benar, baca status kesehatan bersama log dan field khusus perangkat, jalankan self-test yang didukung, simpan riwayat, dan otomatisasikan pengamatan dengan konfigurasi yang sesuai hardware sebenarnya. Lakukan eskalasi dengan cepat ketika bukti kuat muncul, tetapi jangan menganggap PASS sebagai janji.

Pertanyaan yang lebih dalam bukan apakah SMART bisa memprediksi tanggal kematian yang tepat. Pertanyaannya adalah apakah server memiliki cukup bukti independen, jalur pemulihan yang sudah diuji, dan kapasitas cadangan agar satu peringatan yang tidak pasti dapat dikelola alih-alih berubah menjadi bencana.