Belajar Restic - Check & Integrity Verification

#Pendahuluan

Episode 9 dan 10 membuat backup berjalan otomatis. Tapi ada pertanyaan yang lebih dalam: bagaimana kita tahu backup itu benar? Snapshot yang muncul di daftar belum tentu bisa di-restore — bit rot, disk senyap, atau blob hilang bisa merusak repository tanpa gejala apa pun sampai restore dibutuhkan.

Verifikasi bukan pilihan; ia bagian dari definisi "backup yang berfungsi". Episode ini memberi kalian alat dan jadwal untuk membuktikannya.

#restic check: Konsistensi Repository

Perintah pertama memeriksa struktur logis repository:

Check konsistensi repo

restic check

restic check memastikan: semua index terbaca, tiap snapshot merujuk pohon file yang valid, tiap blob yang direferensikan ada, dan tidak ada blob yang hilang. Ini cepat karena tidak membaca seluruh isi blob.

#check --read-data: Verifikasi Seluruh Data

Check dasar tidak mendeteksi blob yang korup tapi masih ada — misalnya disk yang menyimpan bit salah. Untuk itu, baca ulang dan verifikasi MAC seluruh blob:

Baca ulang seluruh data

restic check --read-data

Ini mendownload/membaca semua blob dan memverifikasi checksum-nya — mahal (berjam-jam untuk repo besar), tapi itulah satu-satunya cara membuktikan data benar-benar utuh.

#read-data-subset untuk Repo Besar

Repo besar tidak bisa di---read-data penuh setiap hari. Pecah jadi bagian:

Verifikasi 1/7 bagian tiap hari

restic check --read-data-subset=1/7

Jadwalkan subset 1/7 tiap hari — seluruh repository terverifikasi dalam seminggu tanpa satu pun eksekusi yang membebani.

#Penjadwalan Berkala

Tambahkan ke script otomasi episode 9:

Setiap backup: restic check --quiet — cepat, menangkap korupsi struktural.
Mingguan: restic check --read-data-subset=1/7 — putar subset tiap hari.
Bulanan: restic check --read-data penuh di jam sepi.

Tip

Jalankan check --read-data dari host yang berbeda dari host backup. Tujuannya memvalidasi juga jaringan/backend dari sisi konsumen, bukan hanya sisi penulis.

#Audit dengan restic cat config

Untuk audit yang lebih dalam, intip metadata repository:

Baca config repository

restic cat config

Contoh isi config

version: 2
id: 2223e26e6b...
chunker_polynomial: "xxxxxxxx"
compression: "auto"

Perhatikan compression: "auto" — konfirmasi kompresi default dari episode 6, dan version: 2 menunjukkan versi format repository. Ini berguna saat menyelidiki masalah kompatibilitas antar versi restic.

#Restore Drill: Uji Sesungguhnya

Verifikasi terbaik adalah restore sungguhan ke host lain secara berkala:

Restore drill ke direktori uji

restic restore latest --target /var/restore-test
diff -r /var/restore-test/var/www /var/www
rm -rf /var/restore-test

Uji di host lain memvalidasi bahwa file yang di-restore benar-benar bisa dipakai di luar host sumber — bukan sekadar byte yang cocok. Tambahkan langkah "database dump bisa di-restore" (pg_restore/mysql <) sebagai drill untuk episode 10.

Warning

restic check mendeteksi masalah, tapi tidak memperbaiki. Jika check menemukan blob hilang, solusinya backup ulang dari data yang masih ada — atau pulihkan dari repository cadangan lain. Itu sebabnya strategi backend ganda (episode 7) penting.

#Penutup

restic check: verifikasi struktur repo (index, snapshot, blob ter-referensi).
--read-data: baca & verifikasi seluruh blob — bukti data utuh.
--read-data-subset=1/7: verifikasi bertahap untuk repo besar.
Jadwal: --quiet tiap backup, subset tiap hari, penuh tiap bulan.
restic cat config: audit metadata repo (version, compression).
Restore drill ke host lain adalah uji sebenarnya; check tidak memperbaiki, ia mendeteksi.

Di episode 12 selanjutnya kita memindahkan restic ke lingkungan modern: restic di server/container — image restic/restic dengan volume mount, pola sidecar di Kubernetes, dan membangun rest-server untuk multi-host dengan autentikasi HTTPS + htpasswd.