Cara Membuat Cadangan Database Aplikasi Anda (dan Benar-benar Memulihkannya)

Untuk mencadangkan database aplikasi Anda, ekspor ke sebuah file sesuai jadwal (untuk Postgres, alat standarnya adalah pg_dump), simpan salinan di tempat yang terpisah dari database, dan secara rutin pulihkan salah satunya ke database kosong untuk memastikan cadangan itu benar-benar berfungsi. Buat cadangan tambahan tepat sebelum perubahan berisiko apa pun. Cadangan kode Anda, baik berupa repositori GitHub maupun ekspor, tidak menyertakan data Anda.

Panduan ini ditujukan untuk orang yang menjalankan aplikasi kecil dan ingin berhenti khawatir kehilangannya. Contohnya menggunakan Postgres, karena sebagian besar aplikasi yang dibuat dengan AI memakai Postgres, tetapi prinsipnya berlaku untuk database apa pun.

Apa saja yang harus dicakup cadangan

Sebuah aplikasi lebih dari sekadar database-nya. Ketahui bagian mana yang dilindungi oleh setiap cadangan.

Data adalah bagian yang tidak bisa dibuat ulang. Kode bisa ditulis ulang dan pengaturan bisa dimasukkan lagi; pesanan pelanggan Anda tidak bisa.

Langkah 1: Tentukan seberapa banyak data yang bisa Anda relakan hilang

Dua pertanyaan ini menentukan rencana cadangan Anda:

• Seberapa banyak data terbaru yang bisa Anda relakan hilang? Jika Anda mencadangkan sekali sehari dan database gagal di sore hari, Anda kehilangan perubahan hari itu. Untuk aplikasi hobi, itu tidak masalah. Untuk aplikasi yang menerima pesanan, mungkin tidak bisa diterima.
• Berapa lama aplikasi boleh mati selama pemulihan? Database kecil pulih dalam hitungan menit. Database besar bisa jauh lebih lama, dan Anda perlu tahu hal itu sebelum benar-benar membutuhkannya.

Untuk sebagian besar aplikasi kecil, cadangan otomatis harian ditambah cadangan manual sebelum perubahan berisiko adalah awal yang masuk akal. Aplikasi yang melibatkan uang atau data kesehatan sebaiknya dicadangkan lebih sering, atau menggunakan database terkelola dengan pemulihan titik waktu (kemampuan memulihkan ke momen mana pun, bukan hanya ke cadangan terakhir).

Langkah 2: Periksa apa yang sudah dilakukan host Anda

Banyak penyedia database terkelola sudah membuat cadangan otomatis. Cari tahu:

• Apakah cadangan aktif untuk paket Anda, dan seberapa sering dijalankan?
• Berapa lama cadangan disimpan?
• Bisakah Anda memulihkan ke titik waktu tertentu, atau hanya ke snapshot harian?
• Bisakah Anda mengunduh cadangan, atau hanya memulihkannya di dalam sistem mereka?

Cadangan dari penyedia itu berguna, tetapi memiliki satu titik kegagalan yang sama dengan database Anda: akunnya. Jika akun ditutup, ditangguhkan, atau proyeknya dihapus, cadangan tersebut bisa ikut hilang. Karena itu Anda juga perlu salinan milik sendiri.

Langkah 3: Buat dump dengan pg_dump

pg_dump mengekspor database Postgres ke sebuah file. Alat ini membaca snapshot yang konsisten, sehingga aplikasi tetap bisa berjalan selama proses berlangsung.

Contoh perintah, menggunakan string koneksi yang sudah dimiliki aplikasi Anda di variabel lingkungan:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Fungsi opsi-opsinya:

• --format=custom menulis file terkompresi yang bisa dibaca pg_restore, dan memungkinkan Anda memulihkan tabel tunggal nanti. Gunakan --format=plain jika Anda ingin file .sql yang bisa dibaca manusia.
• --no-owner menghilangkan perintah kepemilikan, sehingga pemulihan ke database yang berbeda menjadi lebih sederhana.
• Tanggal pada nama file membuat setiap cadangan terpisah dengan jelas.

Versi pg_dump sebaiknya sama dengan atau lebih baru daripada versi Postgres database Anda. pg_dump yang lebih lama mungkin menolak untuk berjalan.

Jika Anda membangun dengan AI dan tidak ingin menyentuh baris perintah, Anda bisa meminta:

Buat cadangan database aplikasi menggunakan pg_dump dalam format kustom, dengan tanggal hari ini di nama file. Jangan tampilkan string koneksi atau rahasia apa pun. Beri tahu saya nama file dan ukurannya setelah selesai.

Langkah 4: Otomatiskan

Cadangan manual sering terlupakan. Otomatiskan dengan apa pun yang didukung pengaturan Anda:

• Cadangan terjadwal dari penyedia database Anda, jika tersedia.
• Tugas terjadwal di server atau layanan CI yang menjalankan pg_dump dan mengunggah file ke penyimpanan.
• Layanan cadangan hosted yang terhubung ke database Anda.

Apa pun pilihannya, pastikan Anda diberi tahu ketika cadangan gagal. Tugas cadangan yang diam-diam gagal selama tiga bulan adalah cerita horor klasik.

Langkah 5: Simpan salinan di tempat lain

Aturan praktisnya sering disebut 3-2-1: tiga salinan data Anda, di dua jenis penyimpanan yang berbeda, dengan satu salinan di luar lokasi. Untuk aplikasi kecil, versi praktisnya adalah:

• Database yang aktif
• Cadangan otomatis dari penyedia
• Dump milik Anda di penyimpanan terpisah, misalnya bucket penyimpanan objek di akun yang berbeda

Selain itu:

• Batasi akses. Cadangan menyimpan data setiap pengguna. Perlakukan seperti database yang aktif.
• Miliki kebijakan retensi. Misalnya, cadangan harian selama dua minggu dan cadangan bulanan selama setahun. Hapus cadangan lama dengan sengaja, dan ingat bahwa undang-undang privasi mungkin mewajibkan Anda menghapus data pribadi jika diminta.
• Jangan pernah commit cadangan ke Git. Dump di dalam repositori adalah kebocoran data yang tinggal menunggu waktu.

Langkah 6: Uji pemulihan

Cadangan hanya sebaik pemulihan terakhir yang berhasil. Setidaknya setiap beberapa bulan, dan setelah perubahan apa pun pada proses cadangan:

1. Buat database baru yang kosong. Jangan pernah memulihkan di atas database yang aktif untuk pengujian.
2. Pulihkan cadangan terbaru ke dalamnya:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Untuk file .sql biasa, gunakan psql "$TEST_DATABASE_URL" -f backup.sql sebagai gantinya.

1. Periksa bahwa setiap tabel ada, bandingkan jumlah baris dengan database yang aktif, dan lihat beberapa catatan terbaru.
2. Arahkan salinan aplikasi ke database itu dan masuk, jika memungkinkan.
3. Catat berapa lama pemulihan memakan waktu. Itulah waktu pemulihan Anda yang sebenarnya.

Langkah 7: Buat cadangan sebelum perubahan berisiko

Buat cadangan baru tepat sebelum:

• Menjalankan migrasi database yang menghapus atau mengganti nama kolom
• Mengimpor data dalam jumlah besar
• Membiarkan agen AI membuat perubahan besar pada model data
• Menghapus catatan lama

Di aplikasi yang dibuat dengan AI, agen bisa mengubah struktur tabel sebagai bagian dari sebuah fitur. Checkpoint dan kontrol versi memulihkan kode Anda, tetapi tidak mengembalikan baris yang sudah terhapus. Cadangan tiga puluh detik sebelum perubahan besar adalah asuransi yang murah.

Kesalahan umum

• Menganggap Git atau ekspor kode sebagai cadangan. Itu hanya berisi kode, bukan data.
• Tidak pernah menguji pemulihan. Banyak cadangan ternyata kosong, tidak lengkap, atau tidak bisa dibaca justru ketika dibutuhkan.
• Menyimpan cadangan di akun yang sama dengan database. Satu akun yang diretas atau ditutup menghilangkan keduanya.
• Melupakan file yang diunggah. Database menyimpan jalur file; gambarnya sendiri ada di penyimpanan.
• Menyimpan rahasia di dalam skrip cadangan. Baca string koneksi dari variabel lingkungan, jangan dari teks skrip. Lihat cara menjaga kunci API tetap aman.

Cadangan dan Mythex

Proyek Mythex bisa memiliki database Postgres khusus, dan detail koneksinya disuntikkan ke ruang kerja serta aplikasi yang dipublikasikan. Dokumentasi Mythex tidak menjelaskan fitur cadangan atau pemulihan database, jadi rencanakan sendiri: minta agen membuat dump, unduh, dan simpan di tempat yang aman, terutama sebelum perubahan besar. Ekspor proyek (Pro) berisi kode Anda, dengan rahasia dan node_modules dikeluarkan; ekspor itu tidak berisi baris database. Lihat Database dan Kepemilikan data di dokumentasi. Untuk informasi lebih lanjut tentang database itu sendiri, baca apa itu Postgres.

Daftar periksa cadangan

• Menentukan seberapa banyak data yang bisa direlakan hilang dan berapa lama boleh mati
• Memeriksa cadangan otomatis apa yang disediakan host database Anda
• Dump milik Anda berjalan sesuai jadwal, dan kegagalan memberi Anda peringatan
• Salinan disimpan terpisah dari database, dengan akses terbatas
• Kebijakan retensi ditulis dan didokumentasikan
• File yang diunggah dicadangkan juga, bersama database
• Pemulihan diuji ke database kosong, dengan jumlah baris diperiksa
• Cadangan dibuat sebelum setiap perubahan berisiko

Pertanyaan