Belajar System Engineer - Backup & Restore

#Pendahuluan

Di episode 10 kita memastikan sistem bisa "dilihat" lewat monitoring. Sekarang kita membahas keamanan terakhir yang tidak boleh dilupakan: backup. Ini topik yang aneh — dianggap penting oleh semua orang, tetapi praktiknya paling sering diabaikan. Banyak tim baru sadar nilai backup saat data hilang dan ternyata file backup-nya korup atau belum pernah diuji.

Mengapa episode ini penting? Karena backup tanpa restore yang teruji bukanlah backup — hanya ilusi keamanan. Episode ini mengajarkan cara berpikir strategis: menentukan target RPO/RTO, memilih tool yang tepat, mengotomasi backup, dan — yang paling penting — membangun disiplin verifikasi dan restore drill.

#Konsep Dasar: RPO dan RTO

Sebelum memilih tool, kalian harus bisa menjawab dua pertanyaan bisnis:

RPO menentukan frekuensi backup (makin kecil RPO, makin sering backup). RTO menentukan seberapa cepat restore harus berjalan. Server web dengan data pengguna yang terus berubah butuh RPO kecil; server sekunder dengan data statis bisa RPO besar. Putuskan ini bersama pemilik layanan sebelum membangun apa pun.

#Strategi 3-2-1

Strategi paling terkenal dan masih relevan:

• 3 salinan data (1 produksi + 2 backup).
• 2 media berbeda (misal disk lokal + object storage cloud).
• 1 salinan di luar lokasi (off-site, terpisah dari lokasi produksi).

Pertimbangkan juga varian 3-2-1-1-0: tambah 1 salinan immutable (tidak bisa diubah/dihapus, pelindung dari ransomware) dan 0 kesalahan restore (dijamin lewat verifikasi).

#Memilih Tool Backup

Contoh praktis dengan restic ke penyimpanan remote (S3-compatible):

# 1. Inisialisasi repository
export RESTIC_REPOSITORY=s3:s3.amazonaws.com/bucket-backup/app
export RESTIC_PASSWORD="sangat-rahasia"
restic init
 
# 2. Backup direktori penting
restic backup /srv/app /etc/nginx --tag nightly
 
# 3. Lihat snapshot
restic snapshots

Restic melakukan deduplication dan enkripsi — data yang sama tidak disimpan dua kali, dan isinya tidak bisa dibaca tanpa password. Ini pasangan yang bagus dengan prinsip immutable backup (snapshot tidak bisa diubah).

#Memverifikasi Backup

Verifikasi bukan sekadar "file ada" — tapi "file bisa dipulihkan dan isinya benar". Jenis verifikasi:

# Cek integritas repository
restic check
 
# Simulasikan restore ke direktori sementara
restic restore latest --target /tmp/restore-test
 
# Bandingkan isi (contoh: hash file)
diff -r /srv/app /tmp/restore-test/srv/app

Untuk database, verifikasi berarti restore lalu cek data:

pg_restore -d appdb_restore_test /backup/app.dump
psql -d appdb_restore_test -c "SELECT count(*) FROM users;"

#Otomasi dan Monitoring Backup

Backup harus berjalan otomatis (episode 8) dan hasilnya dipantau (episode 10):

#!/bin/bash
set -euo pipefail
 
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/bucket-backup/app"
export RESTIC_PASSWORD_FILE="/etc/restic/passwd"
 
if restic backup /srv/app /etc/nginx --tag nightly 2>>/var/log/restic.log; then
    curl -fsS -X POST "https://hooks.slack.com/services/XXXX" \
        -d '{"text":"[OK] Backup berhasil"}' || true
else
    curl -fsS -X POST "https://hooks.slack.com/services/XXXX" \
        -d '{"text":"[ALERT] Backup GAGAL! Cek /var/log/restic.log"}' || true
    exit 1
fi

Jadwalkan dengan cron/systemd timer, dan pastikan kegagalan terlihat — bukan hanya tertulis di log yang tidak dibaca.

#Restore Drill: Latihan yang Menyelamatkan

Restore drill adalah latihan penuh: restore dari backup, pastikan aplikasi berjalan, ukur waktunya. Panduan pelaksanaan:

1. Buat VM sementara terpisah dari produksi.
2. Restore data dan konfigurasi sesuai runbook (episode 2).
3. Verifikasi aplikasi benar-benar berfungsi (bukan sekadar data ada).
4. Catat durasi dan kendala; perbaiki runbook.

# 1. Ambil snapshot terakhir
restic snapshots --latest
 
# 2. Restore ke lokasi test
restic restore <snapshot-id> --target /restore-lab
 
# 3. Verifikasi
ls -la /restore-lab
# 4. Catat: mulai ... selesai ... durasi ... kendala ...

#Kesalahan Umum

1. Backup tanpa verifikasi — file ada, tapi tidak pernah dipastikan bisa direstore.
2. RPO/RTO tidak ditentukan — frekuensi backup asal-asalan, restore lambat.
3. Semua backup di lokasi yang sama — satu kebakaran/ransomware menghabisi semuanya.
4. Backup manual yang sering "lupa" — automation wajib.
5. Kegagalan backup tidak terlihat — tidak ada alert saat backup gagal berhari-hari.

#Penutup

Inti yang harus dibawa pulang:

• Tentukan RPO (seberapa banyak data boleh hilang) dan RTO (seberapa cepat harus pulih) sejak awal.
• Strategi 3-2-1 (tambah immutable untuk anti-ransomware) sebagai panduan arsitektur.
• restic menawarkan dedup + enkripsi + snapshot; database punya tool khusus (pg_dump).
• Verifikasi + restore drill berkala adalah satu-satunya jaminan backup benar-benar bekerja.

Di episode 12 selanjutnya kita mengelola workload yang melayani aplikasi: database & middleware ops — PostgreSQL/MySQL, cache, dan queue. Sampai jumpa di episode 12!