Lewati ke konten utama

Backup dan Restore

Custelio menyimpan data tenant di PostgreSQL, runtime ephemeral di Redis, dan berkas di object storage S3-compatible. Backup yang melindungi data harus mencakup database dan object storage; Redis tidak dijadikan sumber data yang perlu dipulihkan karena bersifat runtime. Prosedur backup dan restore drill di bawah ini bersikap jujur: backup tanpa restore teruji bukan perlindungan.

Tujuan​

Backup berkala tersimpan di lokasi terpisah dan prosedur restore terbukti berhasil melalui drill di lingkungan terpisah, dengan target pemulihan yang disepakati dan diukur.

Untuk siapa​

Operator dan platform admin yang menjalankan deployment self-hosted.

Prasyarat​

  • Akses ke service PostgreSQL dan konfigurasi object storage deployment.
  • Lingkungan terpisah untuk drill (bukan produksi yang sedang dipakai).
  • Tidak ada klaim production-ready: deployment produksi harus melewati gate operasional sendiri. Lihat Deployment dan runtime.
  • Rahasia tidak pernah dicetak ke log; skrip backup memakai placeholder dan secret manager.

Kebijakan RPO/RTO yang aman​

RPO (Recovery Point Objective) dan RTO (Recovery Time Objective) adalah angka yang Anda tetapkan dan ukur, bukan klaim produk. Custelio tidak menjanjikan RPO/RTO tertentu; dokumentasi ini hanya menyediakan prosedur untuk menetapkan target yang aman:

  1. Tentukan RPO dari seberapa banyak data yang boleh hilang (misalnya maksimum 15 menit, 1 jam, atau 1 hari sesuai dampak bisnis).
  2. Tentukan RTO dari batas waktu layanan boleh pulih (misalnya maksimum 4 jam).
  3. Jadwalkan frekuensi backup agar kehilangan maksimum tidak melebihi RPO: interval backup harus lebih pendek dari RPO.
  4. Ukur durasi restore nyata pada drill; bila melebihi RTO, sesuaikan prosedur atau target.
  5. Tinjau ulang target setiap kali cakupan data atau skala deployment berubah. Target yang tidak diukur hanya angan-angan.

Menjalankan backup​

  1. Backup database PostgreSQL dengan dump konsisten (misalnya pg_dump/pg_dumpall sesuai deployment) ke berkas dengan timestamp.
  2. Backup object storage (bucket berkas) ke lokasi terpisah dari host produksi, mencakup seluruh object.
  3. Simpan backup di media/lokasi yang berbeda dari data asli (misalnya storage terpisah atau off-site), dengan akses terbatas dan terenkripsi saat transit.
  4. Verifikasi berkas backup terbaca dan ukuran/checksum masuk akal setelah setiap backup; jangan hanya mengandalkan status job.
  5. Pantau kegagalan backup; backup yang gagal harus terlihat dan diperbaiki, bukan menumpuk diam-diam.

Kredensial database harus konsisten satu sumber; override yang tidak konsisten membuat backup/restore gagal pada service yang salah. Lihat Storage dan Platform.

Restore drill​

Lakukan drill secara berkala di lingkungan terpisah — bukan menunggu insiden di produksi:

  1. Siapkan lingkungan terpisah dengan versi service yang sesuai dan konfigurasi kosong.
  2. Pulihkan dump database terlebih dahulu, lalu object storage.
  3. Jalankan service dalam urutan yang benar dan verifikasi ia membaca data hasil restore.
  4. Validasi data nyata: jumlah tenant, kontak, percakapan, dan berkas harus cocok dengan titik backup; jangan hanya melihat status proses.
  5. Catat durasi tiap tahap untuk mengukur RTO aktual, lalu bandingkan dengan target.

Drill yang gagal adalah temuan yang harus diperbaiki, bukan ditandai selesai. Restore yang belum diuji tidak boleh dianggap sebagai perlindungan. Lihat juga langkah backup/restore pada Troubleshooting.

Restore insiden​

  1. Hentikan penulisan baru ke lingkungan yang rusak bila memungkinkan, agar tidak memperparah keadaan.
  2. Pulihkan dari backup terakhir yang terverifikasi, bukan asumsi backup terbaru baik.
  3. Ikuti urutan service dan validasi yang sama seperti drill.
  4. Bila penyebab insiden adalah konfigurasi/kesalahan aplikasi, perbaiki sumbernya sebelum memulihkan ke produksi.
  5. Setelah restore, verifikasi data nyata dan laporkan titik waktu pemulihan serta selisih data yang hilang (RPO aktual).

Tanda berhasil​

Backup terjadwal tersimpan dan terverifikasi; drill restore terbaru selesai dengan data nyata cocok; durasi restore tercatat dan memenuhi RTO yang ditetapkan.

Jika terjadi masalah​

  • Dump gagal / kredensial salah: periksa konsistensi kredensial satu sumber dan akses jaringan; jangan menyimpan secret di skrip.
  • Restore tidak cocok: bandingkan jumlah entitas dan berkas dengan titik backup; ulangi dari dump yang valid, jangan menambal data.
  • Drill melebihi RTO: perbaiki urutan/langkah, dokumentasikan bottleneck, dan ulangi sampai terukur.
  • Berkas tidak terbaca: periksa bucket/endpoint dan kunci enkripsi environment; pulihkan dari lokasi backup terpisah.

Batasan​

Migrasi database, backup/restore otomatis penuh, dan CI belum menjadi pengganti backup yang diuji. Tidak ada klaim RPO/RTO bawaan produk; angka hanya valid bila diukur dari drill deployment Anda. Recovery harus diuji, bukan diasumsikan.

Tugas terkait​