RAID Bukan Backup: Berapa Mahal Sebenarnya Saat Array Gagal

RAID Bukan Backup: Berapa Mahal Sebenarnya Saat Array Gagal

RAID menjaga sistem tetap jalan saat satu disk mati. RAID tidak mengembalikan data yang terhapus, terenkripsi ransomware, atau ikut terbakar bersama kotaknya. Dua kalimat itu memisahkan dua anggaran yang sering dikira satu.

Ambil contoh yang biasa: NAS empat bay di lemari kantor, isinya sepuluh tahun file proyek, jalan dengan RAID 5. Semua orang di kantor percaya datanya aman. Dua disk melaporkan error di minggu yang sama, volume-nya mati, dan penawaran recovery datang dengan angka yang tidak pernah dianggarkan.

Tidak ada yang menyalahi desainnya. RAID 5 tahan satu disk mati. Disk kedua memang tidak pernah masuk hitungan. Celahnya bukan di hardware, tapi di apa yang orang kira sudah dijanjikan hardware itu.

RAID memberi jendela waktu, bukan salinan

Redundansi antar-disk menjawab satu pertanyaan saja: apakah array masih bisa melayani baca-tulis setelah satu drive mati? Itu uptime. Anda dapat jendela waktu untuk mengganti disk yang mati 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.

Untuk semua penyebab kehilangan data yang lain, RAID tidak menolong apa-apa:

• File yang dihapus ikut terhapus di semua disk anggota sekaligus.
• Ransomware mengenkripsi lewat array persis seperti tulisan biasa.
• Tabel yang ke-drop, migrasi yang salah, aplikasi yang menulis sampah — semuanya disalin dengan patuh.
• Korupsi filesystem terjadi di atas lapisan RAID, lalu ikut direplikasi.
• Petir, kebakaran, atau pencurian melenyapkan satu kotak utuh.
• Controller RAID sendiri bisa mati membawa serta array-nya.

Backup adalah salinan yang ada di titik waktu terpisah, di hardware 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

Rebuild adalah operasi paling berat sepanjang umur array, dan dijalankan persis saat redundansinya sudah habis. Tiga hal menumpuk di sana: error baca, durasi, dan kegagalan yang saling berkorelasi.

Setiap datasheet drive mencantumkan angka unrecoverable read error. Untuk disk SATA konsumer, angkanya biasanya kurang dari satu URE per 10^14 bit yang dibaca. Nearline SAS sering mengklaim 10^15. Angka pertama itu artinya kira-kira satu error tiap 12,5 TB pembacaan.

RAID 5 delapan disk dari drive 4 TB harus membaca 28 TB data yang tersisa untuk membangun ulang satu anggota. Itu 2,24 × 10^14 bit, atau sekitar dua error baca menurut spesifikasi konsumer. Semuanya terjadi saat array tidak punya cadangan lagi untuk menyerapnya.

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

Efek error-nya tergantung stack yang Anda pakai. Controller hardware bisa saja mengeluarkan drive itu dari array lalu membatalkan rebuild-nya. Satu disk mati berubah jadi satu volume mati. Linux md lebih pemaaf: sektor buruknya dicatat, prosesnya lanjut, dan Anda kehilangan file yang kebetulan menempati blok itu. Cari tahu sistem Anda termasuk yang mana, jauh sebelum harinya tiba.

Lalu ada faktor durasi. Drive 16 TB yang di-rebuild di 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 bareng cenderung mati bareng. Studi lapangan berskala besar pada populasi produksi menemukan angka penggantian beberapa kali lipat MTBF datasheet, dan kegagalannya menggerombol di waktu berdekatan, bukan menyebar rata. Tetangga disk yang baru mati adalah kandidat berikutnya yang paling mungkin, dan rebuild memberinya minggu terberat seumur hidupnya.

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

Parity adalah data cadangan tersebar yang dipakai menghitung ulang isi disk yang mati. Stripe adalah barisan blok data plus parity yang melintang di seluruh disk. Scrub array RAID 5 akan membaca semua stripe, menghitung ulang parity-nya, lalu mencatat jumlah ketidakcocokan. Angka itu bilang stripe-nya tidak konsisten. Angka itu tidak bisa bilang blok datanya yang salah atau blok parity-nya.

Linux md menyelesaikan kebuntuan itu dengan asumsi. Menulis repair ke /sys/block/md0/md/sync_action membuat parity dihitung ulang dari blok data, lalu ditulis kembali. Benar kalau yang melenceng parity-nya. Menghapus jejak kerusakan kalau yang melenceng datanya. Repair pada RAID 1 menyalin drive pertama ke yang lain. Keduanya bukan bug, cuma memang tidak ada informasi untuk memutuskan mana yang benar.

Write hole itu kekurangan informasi yang sama, cuma muncul di tempat berbeda. Satu update stripe menyentuh blok data dan blok parity. Listrik putus di antara keduanya membuat isi stripe tidak konsisten, dan tidak ada yang mencatat kejadian itu.

Rebuild dari parity itu beberapa bulan kemudian menghasilkan blok rekonstruksi berisi data yang tidak pernah ada. mdadm menutup celah ini dengan write journal atau partial parity log. Controller hardware menutupnya dengan cache ber-baterai, yang bekerja sampai baterainya soak tanpa ketahuan.

Filesystem ber-checksum menghapus kebuntuannya dengan menyimpan hash di setiap blok. ZFS dan btrfs membaca blok, mencocokkan hash-nya, dan saat gagal mereka tahu salinan atau rekonstruksi mana yang benar. Itu batas antara mendeteksi ketidakcocokan dan memperbaiki kerusakan. Ini alasan terkuat memilih ZFS daripada kartu RAID hardware 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

Hasil bukan nol di array RAID 5 adalah kabar yang lebih baik datang di hari biasa yang tenang, bukan di tengah rebuild.

Controller adalah bagian dari format data Anda

Kartu RAID hardware 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. Recovery-nya dimulai dari berburu kartu seri yang sama dengan firmware yang cocok, sebelum apa pun bisa di-mount.

Software RAID tidak punya mode kegagalan itu. Format superblock md Linux terdokumentasi dan host Linux mana pun bisa merakit ulang array-nya. Pool ZFS bisa di-import di mesin mana pun yang menjalankan ZFS, termasuk sistem operasi lain. Untuk bisnis kecil yang tidak punya controller cadangan di rak, portabilitas itu lebih berharga daripada selisih throughput yang jadi alasan beli kartunya.

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 output-nya, model dan versi firmware controller, 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 recovery RAID. Hari ini biayanya lima menit.

Kenapa penawaran recovery-nya berlipat, bukan cuma naik

Satu disk mati itu satu pekerjaan. Image dulu, baru kerjakan image-nya. Itu aturan paling dasar semua recovery.

Array berarti pekerjaan itu dikali jumlah anggotanya, sebelum ada satu file pun dibuka. Semua anggota harus di-image, karena membaca array yang sedang degraded secara langsung mempertaruhkan disk yang masih hidup.

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

Baru sesudah itu stripe-nya bisa dirangkai ulang, dan hasilnya cuma selengkap bahannya. RAID 5 kurang satu anggota bisa direkonstruksi dari parity, dan setiap sektor tak terbaca di disk yang selamat jadi lubang di dalam file. RAID 5 kurang dua anggota, atau stripe RAID 0 kurang satu anggota, adalah hitungan yang tidak punya jawaban.

Kegagalan termahal bukan disk-nya, tapi keputusan di satu jam pertama. Rebuild ke slot yang salah, menyetujui perintah controller untuk initialize array, menjalankan perbaikan filesystem di volume yang sedang degraded. Ketiganya menulis data baru menimpa susunan yang justru jadi tumpuan recovery. Langkah pertama yang benar saat array gagal: matikan dayanya, lalu foto urutan slotnya.

Yang sebaiknya dipakai

Pilih level RAID berdasarkan rebuild-nya, bukan kapasitasnya. Di atas sekitar 4 TB per drive, RAID 6 atau RAID 10 masih menyisakan redundansi selama jendela rebuild yang dilalui RAID 5 tanpa perlindungan sama sekali. Mirror ZFS cuma me-resilver (rebuild versi ZFS) data yang terpakai, jadi selesainya lebih cepat dan bacaan ke disk yang selamat lebih ringan.

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

Pantau array-nya, bukan cuma server-nya. Atribut SMART, mdadm --monitor atau zpool status, dan alert saat array masuk status degraded. Array degraded yang tidak disadari siapa pun adalah babak pembuka klasik menuju kehilangan total. Masukkan pengecekan ini ke setup monitoring minimal yang sama dengan pengecekan uptime 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 storage sesudahnya. Varian modernnya menambah satu salinan offline atau immutable, plus nol error saat verifikasi.

Verifikasi restore-nya, bukan status job-nya. Backup yang belum pernah di-restore itu asumsi yang belum diuji dengan centang hijau di sebelahnya. Restore terjadwal, ke mesin terpisah, lalu periksa isinya. Disiplin yang sama membuat pg_dump jadi backup beneran.

Tulis runbook kegagalan array sebelum dibutuhkan. Matikan daya, jangan initialize, foto slotnya, image semua anggota. Empat baris di dinding ruang server sudah menyelamatkan lebih banyak data daripada fitur controller mana pun.

Ringkasnya

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

Ukur array-nya dari rebuild-nya. Pasang checksum di bawahnya. Scrub terjadwal. Simpan satu salinan di tempat yang tidak terjangkau kebakaran yang sama. Lalu uji restore-nya, karena backup yang bisa dipercaya cuma backup yang pernah Anda kembalikan.