Uji restore: periksa backup Anda sebelumnya

Backup yang belum pernah Anda pulihkan bukanlah backup — itu hanya harapan. Uji pemulihan memakan waktu satu jam setiap kuartal dan mengubah harapan menjadi fakta yang terverifikasi.

Apa yang perlu diperiksa

Tiga pertanyaan yang perlu Anda jawab sebelum insiden terjadi:

1. Kelengkapan. Apakah backup berisi semua yang dibutuhkan untuk memulai: data, pengaturan, kunci, sertifikat, jadwal.
2. Keterbacaan. Apakah arsip dapat dibuka, apakah dump database dapat dipulihkan tanpa error.
3. Waktu. Berapa jam yang dibutuhkan untuk pemulihan penuh. Anda perlu mengetahui angka ini sebelumnya, bukan mengetahuinya saat sedang tertekan.

Cara menjalankan uji pemulihan

Pilihan paling jujur adalah di mesin terpisah, bukan di mesin produksi. Ambil VDS-1 selama sebulan, pulihkan ke sana dari awal, dan catat waktunya.

export RESTIC_REPOSITORY="sftp:backup@backup.example.com:/srv/restic"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic snapshots
restic restore latest --target /restore
ls -la /restore

Pulihkan database:

docker compose up -d db
gunzip -c /restore/var/backups/db.sql.gz | docker compose exec -T db psql -U postgres app
docker compose exec -T db psql -U postgres app -c "select count(*) from users;"

Jalankan aplikasi dan buka di browser — langkah terakhir. Selama halaman belum terbuka, pemulihan belum berhasil.

Pilihan yang lebih ringan namun tetap berguna: pulihkan hanya database ke kontainer terpisah di mesin yang sama dan pastikan datanya ada dan masih baru.

Periksa bukan hanya apakah ekstraksi berhasil, tetapi juga tanggal datanya. Backup yang dibuat dengan andal tetapi berhenti menyertakan direktori yang dibutuhkan sejak sebulan lalu terlihat sepenuhnya normal di daftar snapshot. Bandingkan jumlah record di tabel dan timestamp file terbaru.

Apa yang biasanya terungkap

• File .env terlupakan. Datanya ada, tetapi kata sandinya tidak.
• Sertifikat terlupakan. Situs menyala tetapi tidak merespons melalui HTTPS.
• Jadwal terlupakan. Semuanya berjalan, tetapi backup tidak lagi dibuat — dan Anda baru mengetahuinya sebulan kemudian.
• Urutan startup tidak dicatat. Aplikasi menyala sebelum database dan mengalami crash.
• Kata sandi repositori hanya ada di mesin yang hilang. Backup-nya ada, tetapi tidak ada akses ke sana.
• Pemulihan memakan sepuluh jam, bukan dua. Bandwidth penerima atau rak disk, lihat kecepatan disk.

Tuliskan urutannya

Berdasarkan uji pemulihan, tulis instruksi singkat dan simpan di luar mesin:

1. Pesan mesin dengan tier yang sama atau lebih besar — provisioning memakan waktu sekitar satu menit.
2. Pasang Docker dan pulihkan /opt/myapp dari backup.
3. Pulihkan dump database, periksa jumlah record.
4. Pulihkan /etc/nginx dan sertifikat, jalankan web server.
5. Arahkan domain ke alamat baru.
6. Pulihkan jadwal dari crontab.txt.
7. Periksa: situs terbuka, login berfungsi, backup kembali dibuat.

Poin 5 paling sering diremehkan. Record DNS tidak diperbarui secara instan, dan Anda sebaiknya menurunkan TTL record menjadi 300 detik sebelumnya jika Anda sama sekali mengantisipasi migrasi.

Seberapa sering

Setiap kuartal untuk layanan produksi, setiap enam bulan untuk yang lainnya. Ditambah selalu setelah perubahan besar: database baru, layanan baru, pemindahan direktori. Masukkan uji pemulihan ke kalender, atau itu tidak akan pernah terjadi.

Apa yang harus ada di backup — apa tepatnya yang perlu di-backup. Di mana menyimpannya — backup offsite. Jika insiden sudah terjadi — data hilang.