Cara Membuat Sandaran Pangkalan Data Apl Anda (dan Memulihkannya dengan Betul)

Untuk membuat sandaran pangkalan data apl anda, eksportkannya ke fail mengikut jadual (untuk Postgres, alat standard ialah pg_dump), simpan salinan di tempat yang berasingan daripada pangkalan data, dan kerap pulihkan satu salinan ke dalam pangkalan data kosong untuk membuktikan ia berfungsi. Buat sandaran tambahan sejurus sebelum sebarang perubahan berisiko. Sandaran kod anda, sama ada repositori GitHub atau eksport, tidak termasuk data anda.

Panduan ini untuk orang yang menjalankan apl kecil dan mahu berhenti risau tentang kehilangannya. Ia menggunakan Postgres sebagai contoh kerana kebanyakan apl yang dibina dengan AI menggunakannya, tetapi prinsipnya terpakai kepada mana-mana pangkalan data.

Apa yang perlu dilindungi oleh sandaran

Sebuah apl lebih daripada pangkalan datanya. Ketahui bahagian mana yang dilindungi oleh setiap sandaran.

Data ialah bahagian yang tidak boleh dicipta semula. Kod boleh ditulis semula dan tetapan boleh dimasukkan semula; pesanan pelanggan anda tidak boleh.

Langkah 1: Tentukan berapa banyak yang boleh anda kehilangan

Dua soalan menentukan pelan sandaran anda:

• Berapa banyak data terkini yang sanggup anda hilang? Jika anda membuat sandaran sekali sehari dan pangkalan data gagal pada waktu petang, anda kehilangan perubahan hari itu. Untuk apl hobi, itu memadai. Untuk apl yang menerima pesanan, mungkin tidak.
• Berapa lama apl boleh terhenti semasa anda memulihkan? Pangkalan data kecil dipulihkan dalam beberapa minit. Pangkalan data besar mungkin mengambil masa jauh lebih lama, dan anda perlu tahu perkara itu sebelum anda memerlukannya.

Untuk kebanyakan apl kecil, sandaran automatik harian ditambah sandaran manual sebelum perubahan berisiko ialah permulaan yang munasabah. Apl yang melibatkan wang atau data kesihatan patut mempunyai sandaran yang lebih kerap, atau pangkalan data terurus dengan pemulihan titik masa (keupayaan memulihkan ke mana-mana saat, bukan sekadar ke sandaran terakhir).

Langkah 2: Semak apa yang sudah dilakukan oleh hos anda

Banyak pembekal pangkalan data terurus mengambil sandaran automatik. Ketahui:

• Adakah sandaran diaktifkan untuk pelan anda, dan berapa kerap ia dijalankan?
• Berapa lama ia disimpan?
• Bolehkah anda memulihkan ke titik masa tertentu, atau hanya ke snapshot harian?
• Bolehkah anda memuat turun sandaran, atau hanya memulihkannya di dalam sistem mereka?

Sandaran pembekal berguna, tetapi ia berkongsi satu titik kegagalan dengan pangkalan data anda: akaun itu. Jika akaun ditutup, digantung atau projek dipadam, sandaran mungkin turut hilang. Sebab itulah anda juga mahukan salinan sendiri.

Langkah 3: Buat dump dengan pg_dump

pg_dump mengeksport pangkalan data Postgres ke fail. Ia membaca snapshot yang konsisten, jadi apl boleh terus berjalan semasa ia bekerja.

Arahan biasa, menggunakan rentetan sambungan yang sudah ada dalam pembolehubah persekitaran apl anda:

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

Fungsi pilihan-pilihan tersebut:

• --format=custom menulis fail termampat yang boleh dibaca oleh pg_restore, dan membolehkan anda memulihkan jadual tunggal kemudian. Gunakan --format=plain jika anda mahukan fail .sql yang boleh dibaca.
• --no-owner membuang arahan pemilikan, yang memudahkan pemulihan ke pangkalan data yang berbeza.
• Tarikh dalam nama fail memastikan sandaran dipisahkan mengikut hari.

Versi pg_dump hendaklah sama dengan atau lebih baharu daripada versi Postgres pangkalan data anda. pg_dump yang lebih lama mungkin enggan berjalan.

Jika anda membina dengan AI dan tidak mahu menyentuh baris arahan, anda boleh bertanya:

Buat sandaran pangkalan data apl menggunakan pg_dump dalam format tersuai, dengan tarikh hari ini dalam nama fail. Jangan papar rentetan sambungan atau sebarang rahsia. Beritahu saya nama fail dan saiznya apabila selesai.

Langkah 4: Automatikkannya

Sandaran manual sering dilupakan. Automatikkan dengan apa jua yang disokong oleh persediaan anda:

• Sandaran berjadual daripada pembekal pangkalan data anda, jika ia menawarkannya.
• Tugas berjadual pada pelayan atau perkhidmatan CI yang menjalankan pg_dump dan memuat naik fail ke storan.
• Perkhidmatan sandaran yang dihoskan yang menyambung ke pangkalan data anda.

Apa pun pilihan anda, pastikan ia memberitahu anda apabila sandaran gagal. Tugas sandaran yang gagal secara senyap selama tiga bulan ialah cerita seram yang klasik.

Langkah 5: Simpan salinan di tempat lain

Peraturan ibu jari sering dipanggil 3-2-1: tiga salinan data, pada dua jenis storan yang berbeza, dengan satu salinan di luar lokasi. Untuk apl kecil, versi praktikalnya ialah:

• Pangkalan data hidup
• Sandaran automatik pembekal
• Dump anda sendiri dalam storan berasingan, seperti baldi storan objek dalam akaun yang berbeza

Juga:

• Hadkan akses. Sandaran menyimpan data setiap pengguna. Layannya seperti pangkalan data hidup.
• Tetapkan polisi pengekalan. Contohnya, sandaran harian selama dua minggu dan sandaran bulanan selama setahun. Padam sandaran lama dengan sengaja, dan ingat bahawa undang-undang privasi mungkin menghendaki anda memadam data peribadi atas permintaan.
• Jangan sekali-kali commit sandaran ke Git. Dump dalam repositori ialah kebocoran data yang menunggu untuk berlaku.

Langkah 6: Uji pemulihan

Sandaran hanya sebaik pemulihan berjaya terakhir anda. Sekurang-kurangnya setiap beberapa bulan, dan selepas sebarang perubahan pada proses sandaran:

1. Buat pangkalan data baharu yang kosong. Jangan sekali-kali memulihkan ke atas pangkalan data hidup untuk menguji.
2. Pulihkan sandaran terkini ke dalamnya:

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

Untuk fail .sql biasa, gunakan psql "$TEST_DATABASE_URL" -f backup.sql sebaliknya.

1. Semak bahawa setiap jadual wujud, bandingkan bilangan baris dengan pangkalan data hidup, dan lihat beberapa rekod terkini.
2. Tunjuk salinan apl ke arahnya dan log masuk, jika boleh.
3. Catatkan berapa lama pemulihan mengambil masa. Itulah masa pemulihan sebenar anda.

Langkah 7: Buat sandaran sebelum perubahan berisiko

Buat sandaran baharu sejurus sebelum:

• Menjalankan migrasi pangkalan data yang memadam atau menamakan semula lajur
• Mengimport data secara pukal
• Membenarkan ejen AI membuat perubahan besar pada model data
• Memadam rekod lama

Dalam apl yang dibina dengan AI, ejen boleh menukar struktur jadual sebagai sebahagian daripada satu ciri. Checkpoint dan kawalan versi memulihkan kod anda, tetapi ia tidak membatalkan pemadaman baris. Sandaran selama tiga puluh saat sebelum perubahan besar ialah insurans yang murah.

Kesilapan biasa

• Menganggap Git atau eksport kod sebagai sandaran. Ia mengandungi kod, bukan data.
• Tidak pernah menguji pemulihan. Banyak sandaran ternyata kosong, separuh atau tidak boleh dibaca hanya apabila diperlukan.
• Menyimpan sandaran dalam akaun yang sama dengan pangkalan data. Satu akaun yang dikompromi atau ditutup menghilangkan kedua-duanya.
• Terlupa fail yang dimuat naik. Pangkalan data menyimpan laluan fail; imej itu sendiri berada dalam storan.
• Meninggalkan rahsia dalam skrip sandaran. Baca rentetan sambungan daripada pembolehubah persekitaran, jangan daripada teks skrip. Lihat cara memastikan kunci API selamat.

Sandaran dan Mythex

Projek Mythex boleh mempunyai pangkalan data Postgres khusus, dan butiran sambungannya disuntik ke dalam ruang kerja dan apl yang diterbitkan. Dokumentasi Mythex tidak menerangkan ciri sandaran atau pemulihan pangkalan data, jadi rancang sandaran anda sendiri: minta ejen membuat dump, muat turunnya, dan simpan di tempat selamat, terutamanya sebelum perubahan besar. Eksport projek (Pro) mengandungi kod anda, dengan rahsia dan node_modules ditinggalkan; ia tidak mengandungi baris pangkalan data. Lihat Database dan Data ownership dalam dokumentasi. Untuk maklumat lanjut tentang pangkalan data itu sendiri, baca apa itu Postgres.

Senarai semak sandaran

• Telah memutuskan berapa banyak data yang sanggup hilang dan berapa lama boleh terhenti
• Telah menyemak sandaran automatik yang disediakan oleh hos pangkalan data
• Dump sendiri berjalan mengikut jadual, dan kegagalan memberi amaran kepada anda
• Salinan disimpan berasingan daripada pangkalan data, dengan akses terhad
• Polisi pengekalan telah ditulis
• Fail yang dimuat naik turut disandarkan bersama pangkalan data
• Pemulihan telah diuji ke dalam pangkalan data kosong, dan bilangan baris telah disemak
• Sandaran dibuat sebelum setiap perubahan berisiko

Soalan lazim