Belajar RAID - Backup & Disaster Recovery

#Pendahuluan

Di episode 1 kami menyebut pepatah yang akan terus diulang: RAID bukan backup. Episode 12 ini membuktikannya sekaligus memberi resep lengkap untuk bertahan dari bencana. RAID melindungi dari satu jenis kehilangan data — disk mati — tapi tidak melindungi dari penghapusan yang salah, ransomware, atau kebakaran gedung.

Solusinya adalah pertahanan berlapis: RAID sebagai fondasi ketersediaan, snapshot untuk kesalahan manusia, replication untuk bencana lokal, dan backup offsite untuk bencana menyeluruh. Mari kita bedah setiap lapisan dan cara merakitnya.

#Mengapa RAID Bukan Backup

#Tiga Skenario yang Tidak Ditangani RAID

Pikirkan tiga skenario berikut:

• Kalian mengetik rm -rf /mnt/raid/proyek secara tidak sengaja — RAID tidak berbuat apa-apa, file hilang permanen.
• Ransomware mengenkripsi seluruh isi array — semua salinan mirror ikut terenkripsi.
• Ruang server kebakaran — seluruh disk array hangus bersama.

Ketiganya menegaskan: RAID menjaga hardware tetap berjalan, bukan menjaga data tetap aman dari kesalahan. Backup adalah lapisan yang bertugas pada domain tersebut.

#Definisi Kerja Backup

Sebuah backup yang benar memenuhi aturan 3-2-1: tiga salinan data, di dua media berbeda, dengan satu salinan di lokasi berbeda. RAID bisa menyumbang salinan pertama di lokasi pertama, tapi dua salinan lainnya harus datang dari snapshot, replication, dan backup offsite.

#Lapisan Pertahanan

#Snapshot ZFS dan btrfs

Snapshot adalah salinan instan dari keadaan data pada satu titik waktu. Pada ZFS, snapshot hampir tanpa biaya karena hanya mencatat perbedaan blok:

sudo zfs snapshot tank/data@2026-08-10
sudo zfs list -t snapshot

Perintah zfs snapshot tank/data@2026-08-10 menandai keadaan dataset. Output zfs list -t snapshot menampilkan snapshot yang tersimpan. btrfs punya mekanisme serupa dengan btrfs subvolume snapshot. Snapshot melindungi dari kesalahan manusia — cukup rollback ke snapshot terakhir.

#Replication ke Mesin Lain

Snapshot juga jadi bahan bakar replication: mengirim selisih data ke server lain. Di ZFS, replication memakai zfs send dan zfs receive:

sudo zfs send tank/data@2026-08-10 | ssh backup-host sudo zfs receive backup/data

Perintah zfs send mengirim snapshot melalui ssh dan zfs receive menyimpannya di host lain. Proses ini hanya mengirim blok yang berubah sejak snapshot terakhir — efisien untuk data yang bertambah sedikit setiap hari.

#Backup Offsite

Lapisan terakhir adalah salinan di lokasi berbeda. Bisa berupa:

• Tape atau harddisk terenkripsi yang disimpan di tempat lain.
• Object storage cloud (S3, R2) memakai tool seperti restic atau rclone.
• Replication lintas region untuk data yang benar-benar kritis.

Pilih sesuai anggaran dan kebutuhan. Yang penting: ada salinan yang selamat meski satu lokasi fisik hilang.

#Prosedur Reassemble dan Rebuild Order

#Reassemble Setelah Kegagalan Parsial

Saat mesin reboot setelah beberapa disk bermasalah, urutan pemulihan yang benar adalah:

sudo mdadm --detail --scan
sudo mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Perintah mdadm --assemble merakit array secara eksplisit dari disk yang tersedia. Jangan pernah langsung memakai --force tanpa memeriksa dulu — kekuatan assemble harus dipakai hanya ketika kalian yakin disk mana yang benar.

#Urutan Rebuild yang Benar

Setelah array aktif, ikuti urutan ini:

1. Cek state: pastikan tidak ada disk yang salah di-assemble.
2. Ganti disk yang gagal: --fail, --remove, lalu --add pengganti.
3. Tunggu rebuild selesai: pantau /proc/mdstat sampai 100%.
4. Verifikasi: mdadm --detail harus menampilkan semua device aktif.

while true; do cat /proc/mdstat; sleep 60; done

Perintah cat /proc/mdstat dalam loop memantau progres sampai selesai. Setelah [UUU] penuh dan state clean, barulah kalian boleh menambah beban kerja normal.

#Menguji Rencana Recovery

#Latihan Restore

Sebuah backup yang tidak pernah diuji bukanlah backup. Jadwalkan latihan restore berkala:

sudo zfs rollback -r tank/data@2026-08-10

Perintah zfs rollback -r mengembalikan dataset ke titik snapshot. Latih restore di mesin cadangan, catat waktu yang dibutuhkan, dan ukur RTO (Recovery Time Objective) serta RPO (Recovery Point Objective) kalian. Angka inilah yang menjadi kontrak layanan kalian pada saat krisis.

#Penutup

Episode 12 menegaskan bahwa RAID adalah fondasi, bukan pengganti backup. Kalian kini tahu cara menyusun pertahanan berlapis — snapshot ZFS dan btrfs untuk kesalahan manusia, replication jarak jauh untuk bencana lokal, backup offsite untuk bencana menyeluruh — plus prosedur reassemble dan urutan rebuild yang benar setelah kegagalan parsial.

Inti yang harus dibawa pulang:

• RAID tidak melindungi dari penghapusan salah, ransomware, atau bencana fisik.
• Gunakan aturan 3-2-1: tiga salinan, dua media, satu di lokasi lain.
• Snapshot ZFS atau btrfs melindungi dari kesalahan manusia secara instan.
• Replication memakai zfs send dan zfs receive untuk cadangan jarak jauh.
• Jangan --force assemble tanpa analisis; ikuti urutan rebuild yang benar.
• Uji restore secara rutin dan ukur RTO serta RPO kalian.

Di episode 13 selanjutnya kita akan membahas failure detection & monitoring — memantau disk dengan smartctl, memprediksi kegagalan lewat atribut SMART, serta membangun monitoring stack dengan mdadm monitor, node_exporter, dan Prometheus plus dashboard. Kalian akan membangun radar dini untuk storage.