Backup Adalah Jaring Pengaman, Bukan Strategi Migrasi

Tim Anda baru saja menjalankan migrasi database yang menghapus tabel orders_archive. Data sudah dipindahkan ke tabel baru, jadi semuanya tampak bersih. Namun, sebuah sistem lama yang tidak diingat siapa pun masih membaca dari tabel tersebut. Sekarang tabelnya hilang, datanya hilang, dan migrasi baru untuk membuat ulang tabel tidak memiliki data yang bisa dipulihkan.

Atau mungkin Anda mengubah kolom price dari INTEGER menjadi DECIMAL, dan sebuah batch job yang berjalan setiap jam masih menulis integer ke kolom tersebut, merusak record secara diam-diam.

Dalam momen seperti ini, insting yang muncul bisa dimengerti: "Kami punya backup. Mari kita restore database ke kondisi sebelum migrasi."

Kedengarannya masuk akal. Namun konsekuensinya seringkali lebih buruk daripada masalah aslinya.

Untuk Apa Sebenarnya Backup Itu

Backup ada untuk skenario bencana. Kebakaran ruang server. Kegagalan storage array. Disk yang korup. Admin yang tidak sengaja menghapus tabel kritis. Dalam situasi tersebut, restore dari backup adalah keputusan yang tepat. Tidak ada opsi lain, dan biaya jika tidak merestore adalah kehilangan data total.

Tetapi migrasi yang gagal bukanlah bencana. Itu adalah kejadian operasional rutin. Dan memperlakukannya seperti bencana justru menciptakan masalah baru.

Dua Masalah dengan Rollback Berbasis Backup

Kehilangan Data

Backup adalah snapshot data Anda pada titik waktu tertentu. Jika Anda mengambil backup jam 2:00 pagi dan migrasi gagal jam 10:00 pagi, ada delapan jam aktivitas pengguna yang hanya ada di database produksi Anda. Pesanan dibuat. Profil diperbarui. Tiket dukungan dibuat. Perubahan konfigurasi dilakukan.

Ketika Anda merestore backup jam 2:00 pagi, semua data itu hilang. Tidak ada cara untuk mendapatkannya kembali kecuali Anda memiliki sumber lain. Celah ini semakin besar seiring waktu antara backup dan restore. Bahkan jika Anda menggunakan point-in-time recovery dan restore ke jam 9:59 pagi, Anda tetap kehilangan apa pun yang terjadi di menit terakhir itu.

Downtime

Merestore database tidaklah instan. Untuk database berukuran ratusan gigabyte, restore bisa memakan waktu berjam-jam. Selama waktu itu, aplikasi Anda tidak bisa melayani traffic secara normal. Data menjadi tidak konsisten, terload sebagian, atau terkunci oleh proses restore.

Bandingkan dengan pendekatan roll-forward, di mana Anda menjalankan migrasi baru yang hanya memakan waktu menit. Atau skrip kompensasi yang menyesuaikan data tanpa menghentikan aplikasi. Rollback berbasis backup memaksa tim Anda memilih antara kehilangan data dan downtime yang berkepanjangan, seringkali keduanya.

Point-in-Time Recovery Mengurangi Tapi Tidak Menyelesaikan

Beberapa tim menggunakan point-in-time recovery (PITR) untuk mengurangi celah data. Alih-alih merestore ke backup penuh terakhir, mereka merestore ke posisi log transaksi tertentu, misalnya satu menit sebelum migrasi dijalankan.

Ini membantu. Anda kehilangan lebih sedikit data. Tapi Anda tetap kehilangan sebagian. Transaksi yang selesai dalam hitungan detik sebelum migrasi tetap hilang. Dan proses restore itu sendiri masih memakan waktu. PITR lebih baik daripada restore backup penuh, tapi itu bukan mekanisme rollback yang bersih.

Di Mana Backup Berada dalam Hierarki Pemulihan Anda

Backup memiliki peran yang jelas dalam pemulihan database: sebagai pilihan terakhir. Jaring pengaman ketika semua hal lain gagal dan Anda bersedia menerima kehilangan data dan downtime karena alternatifnya lebih buruk.

Dalam tim yang matang, backup diambil secara rutin dan diuji secara berkala. Tapi ketika migrasi bermasalah, tim tidak langsung meraih backup terlebih dahulu. Mereka bekerja melalui hierarki:

Diagram alir berikut merangkum proses keputusan ini:

flowchart TD A[Migrasi gagal] --> B{Bisa roll-forward?} B -- Ya --> C[Tulis migrasi baru atau skrip kompensasi] B -- Tidak --> D{Apakah down migration aman?} D -- Ya --> E[Jalankan down migration untuk revert] D -- Tidak --> F[Pertimbangkan restore backup] F --> G[⚠️ Kehilangan data dan downtime diperkirakan]
  1. Roll-forward: Tulis migrasi baru yang membalikkan perubahan atau menambahkan bagian yang hilang.
  2. Skrip kompensasi: Jalankan skrip yang menyesuaikan data tanpa migrasi penuh.
  3. Restore backup: Hanya setelah mengevaluasi trade-off kehilangan data dan downtime.

Checklist Praktis Sebelum Meraih Backup

Sebelum Anda restore dari backup, tanyakan pertanyaan-pertanyaan ini:

  • Bisakah kita menulis migrasi yang menambahkan kembali tabel atau kolom yang dihapus?
  • Bisakah kita menjalankan skrip kompensasi yang merekonstruksi data yang hilang dari log atau sumber lain?
  • Berapa banyak data yang akan hilang jika kita restore dari backup terakhir?
  • Berapa lama proses restore akan berlangsung, dan bisakah bisnis menerima downtime tersebut?
  • Apakah ada cara untuk menjaga aplikasi tetap berjalan sebagian sementara kita memperbaiki data?

Jika jawaban untuk dua pertanyaan pertama adalah "ya," Anda tidak perlu restore backup. Jika jawaban untuk tiga pertanyaan terakhir adalah "tidak bisa diterima," Anda perlu mencari cara lain.

Kesimpulan

Backup adalah jaring pengaman Anda untuk bencana, bukan strategi rollback migrasi Anda. Ketika migrasi gagal, mulailah dengan roll-forward atau skrip kompensasi. Raih backup hanya ketika opsi-opsi tersebut sudah habis dan Anda telah menerima biaya kehilangan data dan downtime. Tim yang memperlakukan backup sebagai rencana rollback default adalah tim yang akan kehilangan data produksi dan tidur nyenyak.