RAID Bukan Pencadangan: Risiko dan Biaya Saat Gagal

RAID menggabungkan beberapa disk agar penyimpanan bisa tetap bekerja saat sebagian disk gagal, sesuai jenis RAID-nya. RAID tidak mengembalikan berkas yang terhapus atau terkena ransomware. Untuk itu Anda butuh pencadangan terpisah yang pernah diuji pemulihannya. Periksa juga prosedur penggantian disk: proses membangun ulang data bisa membuka risiko ketika cadangan antardisk berkurang.

Bayangkan penyimpanan jaringan atau NAS dengan empat slot disk di kantor. RAID 5 menyimpan sepuluh tahun berkas proyek, sehingga staf menganggap datanya aman. Jika dua disk gagal pada minggu yang sama, penyimpanan dapat berhenti bekerja. Biaya pemulihan kemudian muncul tanpa pernah dianggarkan.

RAID 5 dirancang untuk bertahan ketika satu disk gagal. Kegagalan disk kedua berada di luar perlindungan tersebut. Risiko muncul ketika kemampuan perangkat dianggap lebih luas daripada rancangan sebenarnya.

RAID memberi jendela waktu, bukan salinan

Redundansi antardisk menjaga kelompok disk, atau array, tetap melayani baca-tulis setelah satu disk gagal, sesuai jenis RAID-nya. Perlindungan ini menjaga ketersediaan layanan dan memberi waktu untuk mengganti disk tanpa menghentikan pekerjaan.

Bayangkan ban serep. Ban serep menyelamatkan Anda dari satu ban bocor di tengah jalan. Ban serep tidak menolong sama sekali kalau mobilnya dicuri. RAID adalah ban serep.

RAID tidak melindungi data dari kejadian berikut:

• File yang dihapus ikut terhapus di semua disk anggota sekaligus.
• Ransomware mengenkripsi lewat array persis seperti tulisan biasa.
• Tabel yang terhapus, migrasi yang keliru, atau aplikasi yang menulis data rusak — semuanya disalin dengan patuh.
• Korupsi sistem berkas terjadi di atas lapisan RAID, lalu ikut direplikasi.
• Petir, kebakaran, atau pencurian melenyapkan satu kotak utuh.
• Pengendali RAID sendiri bisa mati membawa serta kelompok disknya.

Pencadangan adalah salinan yang ada di titik waktu terpisah, di perangkat keras terpisah, dan tidak bisa dijangkau satu kejadian buruk yang sama. RAID tidak memenuhi ketiganya. Waktunya sama, kotaknya sama, dan satu musibah cukup untuk menghabisi semuanya.

Array paling sering mati justru saat rebuild

Pembangunan ulang data setelah disk diganti, atau rebuild, membebani disk yang masih bekerja. Pada RAID 5, proses ini berjalan ketika tidak ada lagi disk tambahan untuk menanggung kegagalan berikutnya. Perhatikan tiga risiko: galat baca, lama proses, dan kegagalan disk yang terjadi berdekatan.

Setiap lembar spesifikasi disk mencantumkan angka galat baca yang tidak dapat dipulihkan (unrecoverable read error, URE). Untuk disk SATA konsumer, angkanya biasanya kurang dari satu URE per 10^14 bit yang dibaca. Nearline SAS sering mengklaim 10^15. Pada tingkat tersebut, 10^14 bit setara dengan sekitar 12,5 TB pembacaan. Batas spesifikasi ini bukan rata-rata hasil pengukuran.

RAID 5 delapan disk dari disk 4 TB harus membaca 28 TB data yang tersisa untuk membangun ulang satu anggota. Itu 2,24 × 10^14 bit. Volume ini melampaui acuan 10^14 bit, tetapi spesifikasi saja tidak membuktikan bahwa dua galat akan terjadi atau pembangunan ulang akan gagal. Pada tahap ini, RAID 5 tidak memiliki redundansi tersisa.

Angka spesifikasi itu batas atas yang dijamin vendor, bukan hasil pengukuran. Data lapangan umumnya lebih baik dari lembar spesifikasi. Menganggap rebuild pasti gagal itu keliru. Menganggapnya rutinitas biasa juga keliru.

Dampak galat bergantung pada sistem yang digunakan. Pengendali perangkat keras bisa saja mengeluarkan disk itu dari array lalu membatalkan proses pembangunan ulangnya. Satu disk mati berubah jadi satu volume mati. Linux md dapat mencatat sektor buruk lalu melanjutkan proses, dengan kehilangan data pada blok terkait. Periksa perilaku sistem Anda sebelum terjadi kegagalan.

Lalu ada faktor durasi. Disk 16 TB yang dibangun ulang pada kecepatan nyata 150 MB per detik butuh sekitar tiga puluh jam kalau tidak ada beban lain. I/O produksi dan pembatas kecepatan rebuild biasanya memanjangkannya jadi dua sampai tiga hari. Sepanjang jam-jam itu array Anda tanpa redundansi, dan semua disk yang selamat dibaca ujung ke ujung dengan beban penuh.

Disk yang dibeli bersamaan dapat gagal pada waktu berdekatan. Studi lapangan berskala besar pada populasi produksi menemukan angka penggantian beberapa kali lipat MTBF lembar spesifikasi, dan kegagalannya menggerombol di waktu berdekatan, bukan menyebar rata. Disk dari kelompok yang sama perlu diperhatikan ketika satu anggota gagal, karena pembangunan ulang membebani semua disk yang tersisa.

Paritas tahu ada yang tidak cocok, bukan bagian mana yang salah

Paritas adalah data cadangan tersebar yang dipakai menghitung ulang isi disk yang mati. Stripe adalah kelompok blok data dan paritas yang melintang di seluruh disk. Pemeriksaan menyeluruh pada array RAID 5 akan membaca semua stripe, menghitung ulang paritasnya, lalu mencatat jumlah ketidakcocokan. Hitungan ini menunjukkan ketidakkonsistenan dalam kelompok blok, tetapi tidak menentukan apakah blok data atau blok paritas yang salah.

Linux md menyelesaikan kebuntuan itu dengan asumsi. Menulis repair ke /sys/block/md0/md/sync_action membuat paritas dihitung ulang dari blok data, lalu ditulis kembali. Tindakan ini tepat jika paritasnya yang salah. Namun, jika datanya rusak, penulisan tersebut justru menghilangkan bukti ketidaksesuaian. Perbaikan RAID 1 memilih satu salinan cermin tanpa membuktikan bahwa isi salinan itulah yang benar. Keduanya bukan bug, hanya memang tidak ada informasi untuk memutuskan mana yang benar.

Write hole adalah ketidakkonsistenan yang muncul ketika penulisan data dan paritas tidak selesai bersamaan. Satu pembaruan stripe menyentuh blok data dan blok paritas. Listrik putus di antara keduanya membuat isi stripe tidak konsisten, dan tidak ada yang mencatat kejadian itu.

Rebuild dari paritas itu beberapa bulan kemudian menghasilkan blok rekonstruksi berisi data yang tidak pernah ada. mdadm menutup celah ini dengan jurnal penulisan atau catatan paritas parsial. Pengendali perangkat keras mengatasinya dengan memori sementara yang didukung baterai. Perlindungan ini perlu dipantau agar baterai yang melemah tidak luput diketahui.

Sistem berkas dengan pemeriksaan integritas menghapus kebuntuannya dengan menyimpan hash di setiap blok. ZFS dan btrfs membaca blok, mencocokkan nilai hash-nya, dan saat gagal mereka dapat memilih salinan atau rekonstruksi yang benar jika masih ada salinan redundan yang utuh. Tanpa salinan tersebut, pemeriksaan integritas mendeteksi kerusakan tetapi tidak dapat memulihkan data. Itu batas antara mendeteksi ketidakcocokan dan memperbaiki kerusakan. Ini alasan terkuat memilih ZFS daripada kartu RAID perangkat keras untuk data yang memang mau Anda simpan lama.

Apa pun yang Anda pakai, jadwalkan scrub bulanan dan pasang alert di penghitungnya:

cat /sys/block/md0/md/mismatch_cnt

Tindak lanjuti hasil selain nol pada RAID 5 saat kondisi normal, sebelum pembangunan ulang diperlukan.

Pengendali adalah bagian dari format data Anda

Kartu RAID perangkat keras menulis metadata-nya sendiri ke disk anggota: geometri stripe, urutan anggota, status array. Formatnya khas per vendor dan sebagian besar tidak berdokumentasi. Saat kartunya mati, disk Anda utuh tapi tidak bisa dibaca. Pemulihan dapat memerlukan kartu dari seri yang sama dengan versi perangkat tegar yang sesuai sebelum penyimpanan bisa dibaca.

Perangkat lunak RAID tidak punya mode kegagalan itu. Format superblock md Linux terdokumentasi dan komputer Linux yang kompatibel dapat merakit ulang kelompok disknya. Kelompok penyimpanan ZFS dapat diimpor pada sistem ZFS lain yang kompatibel, termasuk sistem operasi berbeda, asalkan implementasinya mendukung fitur format yang aktif. Bagi bisnis kecil tanpa pengendali cadangan, kemudahan memindahkan disk ke mesin lain perlu dipertimbangkan bersama kecepatan pemindahan data.

Apa pun pilihannya, simpan geometrinya sekarang selagi semua masih sehat:

mdadm --detail --scan
for d in /dev/sd[b-i]; do mdadm --examine "$d"; done
lsblk -o NAME,SERIAL,SIZE,MODEL

Simpan keluarannya, model dan versi perangkat tegar pengendali, plus foto yang memperlihatkan nomor seri mana terpasang di slot mana. Taruh di luar array. Menyusun ulang parameter itu setelah array gagal adalah salah satu bagian termahal dari pemulihan RAID. Saat sistem masih sehat, dokumentasi ini dapat dibuat dalam lima menit.

Mengapa pemulihan RAID lebih mahal daripada satu disk

Pemulihan satu disk dimulai dengan membuat salinan utuh atau citra disk. Analisis kemudian dilakukan pada citra tersebut. Itu aturan paling dasar semua pemulihan.

Pada kelompok RAID, citra perlu dibuat untuk setiap disk sebelum berkas dianalisis. Membaca langsung kelompok yang sudah kehilangan redundansi dapat membebani disk yang masih bertahan.

Setelah itu geometrinya harus ditemukan dari image: ukuran kelompok blok, urutan anggota, rotasi paritas (left-symmetric bawaan Linux, pengendali lain beragam), offset data, dan anggota mana yang sudah basi duluan sebelum array berhenti.

Baru sesudah itu kelompok bloknya bisa dirangkai ulang, dan hasilnya hanya selengkap bahannya. RAID 5 kurang satu anggota bisa direkonstruksi dari paritas, dan setiap sektor tak terbaca di disk yang selamat jadi lubang di dalam berkas. RAID 5 kurang dua anggota, atau stripe RAID 0 kurang satu anggota, adalah hitungan yang tidak punya jawaban.

Keputusan pada satu jam pertama dapat memperbesar kerusakan dan biaya pemulihan. Rebuild ke slot yang salah, menyetujui perintah pengendali untuk initialize array, menjalankan perbaikan sistem berkas di volume yang sedang kehilangan redundansi. Ketiganya menulis data baru menimpa susunan yang justru jadi tumpuan pemulihan. Langkah pertama yang benar saat array gagal: matikan dayanya, lalu foto urutan slotnya.

Yang sebaiknya dipakai

Pilih level RAID berdasarkan proses pembangunan ulangnya, bukan kapasitasnya. Di atas sekitar 4 TB per disk, RAID 6 atau RAID 10 dengan susunan yang sesuai dapat mempertahankan toleransi kegagalan lebih besar saat rebuild dibanding RAID 5. Perlindungan RAID 10 bergantung pada anggota pasangan salinan yang gagal. Salinan cermin ZFS hanya membangun ulang (rebuild versi ZFS) data yang terpakai, jadi selesainya lebih cepat dan bacaan ke disk yang selamat lebih ringan.

Campur batch pembelian dan sediakan disk cadangan siap pakai. Tanggal beli atau vendor yang berbeda memutus korelasi kegagalannya. Hot spare memulai rebuild jam 3 pagi, bukan menunggu ada orang membaca email.

Pantau kelompok disknya, bukan hanya server-nya. Atribut SMART, mdadm --monitor atau zpool status, dan peringatan saat array masuk status kehilangan redundansi. Kelompok disk yang kehilangan redundansi yang tidak disadari siapa pun adalah babak pembuka klasik menuju kehilangan total. Masukkan pengecekan ini ke penyiapan pemantauan minimal yang sama dengan pengecekan ketersediaan Anda.

Jalankan 3-2-1. Tiga salinan, di dua jenis media, satu di lokasi lain. Aturan ini lahir dari praktik manajemen aset digital fotografer Peter Krogh, dan tetap relevan melewati semua generasi penyimpanan sesudahnya. Varian modernnya menambah satu salinan luring atau tidak dapat diubah, plus nol galat saat verifikasi.

Uji pemulihan, jangan hanya melihat status pencadangan. Pencadangan yang belum pernah dipulihkan belum membuktikan datanya dapat digunakan kembali. Jadwalkan pemulihan ke mesin terpisah dan periksa isinya. Disiplin yang sama membuat pg_dump jadi pencadangan benar-benar.

Tulis panduan penanganan kegagalan array sebelum dibutuhkan. Matikan daya, jangan initialize, foto slotnya, image semua anggota. Letakkan langkah-langkah ini di tempat yang mudah dibaca dan uji prosedur pemulihan sebelum terjadi insiden.

Pisahkan ketersediaan dari kemampuan pemulihan

RAID menjawab "bisakah kami tetap bekerja saat satu disk mati". Pencadangan menjawab "bisakah datanya kembali". Dua pertanyaan berbeda; jawaban untuk yang pertama tidak pernah otomatis menjawab yang kedua.

Nilai rancangan RAID berdasarkan risiko pembangunan ulang. Gunakan pemeriksaan integritas dan jadwalkan pembacaan menyeluruh untuk menemukan ketidaksesuaian. Simpan salinan terpisah yang tidak terkena kebakaran di lokasi yang sama, lalu uji pemulihannya.