Paano I-back Up ang Database ng App Mo (at Siguradong Maibabalik Ito)

Para i-back up ang database ng app mo, i-export ito sa file ayon sa iskedyul (sa Postgres, ang standard na tool ay pg_dump), itago ang mga kopya sa lugar na hiwalay sa database, at regular na i-restore ang isa sa isang walang lamang database para mapatunayang gumagana ito. Gumawa ng dagdag na backup bago ang anumang mapanganib na pagbabago. Ang backup ng code mo, GitHub repository man o export, ay hindi kasama ang data mo.

Para ito sa mga taong nagpapatakbo ng maliit na app at gustong huwag nang mag-alala na mawala ito. Gumagamit ang gabay ng Postgres sa mga halimbawa, dahil karamihan ng AI-built na app ay gumagamit nito, pero pareho ang mga prinsipyo sa anumang database.

Ano ang dapat saklawin ng backup

Higit pa sa database ang isang app. Alamin kung aling bahagi ang pinoprotektahan ng bawat backup.

Ang data ang bahaging hindi mo na maibabalik kapag nawala. Maaaring isulat ulit ang code at muling ilagay ang mga setting; hindi na maibabalik ang mga order ng mga customer mo.

Hakbang 1: Alamin kung gaano karami ang kaya mong mawala

Dalawang tanong ang humuhubog sa backup plan mo:

• Gaano karaming kamakailang data ang kaya mong mawala? Kung isang beses lang sa isang araw ang backup at bumagsak ang database sa gabi, mawawala ang mga pagbabago ng araw na iyon. Para sa hobby na app, ayos lang iyon. Para sa app na tumatanggap ng order, maaaring hindi.
• Gaano katagal puwedeng mawala ang app habang nire-restore? Mabilis mag-restore ang maliit na database, sa loob ng ilang minuto. Ang malaki ay maaaring abutin nang mas matagal, kaya dapat mo itong malaman bago mo kailanganin.

Para sa karamihan ng maliliit na app, magandang simula ang araw-araw na automatic backup at isang manual na backup bago ang mapanganib na pagbabago. Ang mga app na may kinalaman sa pera o health data ay nangangailangan ng mas madalas na backup, o ng managed database na may point-in-time recovery (ang kakayahang mag-restore sa anumang sandali, hindi lang sa huling backup).

Hakbang 2: Tingnan kung ano na ang ginagawa ng host mo

Maraming managed database provider ang awtomatikong gumagawa ng backup. Alamin ang mga ito:

• Naka-on ba ang backup sa plan mo, at gaano kadalas tumatakbo?
• Gaano katagal itinatago ang mga ito?
• Puwede ka bang mag-restore sa isang partikular na sandali, o daily snapshot lang?
• Puwede mo bang i-download ang backup, o sa loob lang ng sistema nila ito maibabalik?

Kapaki-pakinabang ang backup ng provider, pero may iisang single point of failure ang mga ito kasama ng database mo: ang account. Kapag na-close, na-suspend ang account, o nabura ang project, maaaring kasama ring mawala ang mga backup. Kaya gusto mo rin ng sarili mong kopya.

Hakbang 3: Gumawa ng dump gamit ang pg_dump

Iniluluwas ng pg_dump ang Postgres database sa file. Binabasa nito ang isang konsistenteng snapshot, kaya puwedeng tumakbo pa rin ang app habang ginagawa ito.

Isang karaniwang command, gamit ang connection string na nasa environment variable na ng app mo:

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

Ang ginagawa ng mga option:

• --format=custom ay nagsusulat ng compressed na file na kayang basahin ng pg_restore, at puwede mong i-restore ang isang table lang sa susunod. Gamitin ang --format=plain kung gusto mo ng nababasang .sql file.
• --no-owner ay inaalis ang mga ownership command, para mas madaling i-restore sa ibang database.
• Ang petsa sa pangalan ng file ang naghihiwalay sa mga backup.

Dapat pareho o mas bago ang bersyon ng pg_dump kaysa sa bersyon ng Postgres ng database mo. Maaaring tumanggi ang mas lumang pg_dump na tumakbo.

Kung gumagawa ka gamit ang AI at ayaw mong galawin ang command line, puwede mong itanong:

Gumawa ng backup ng database ng app gamit ang pg_dump sa custom format, may petsa ngayon sa pangalan ng file. Huwag i-print ang connection string o anumang secret. Sabihin mo sa akin ang pangalan ng file at laki nito kapag tapos na.

Hakbang 4: I-automate ito

Nakakalimutan ang manual na backup. I-automate ito gamit ang kung ano ang kaya ng setup mo:

• Scheduled backup ng database provider mo, kung meron sila nito.
• Scheduled job sa server o CI service na nagpapatakbo ng pg_dump at nag-a-upload ng file sa storage.
• Hosted backup service na kumokonekta sa database mo.

Alinman ang piliin mo, gawin itong magsabi sa iyo kapag pumalya ang backup. Ang backup job na tahimik na pumalya nang tatlong buwan ay ang klasikong kuwentong nakakatakot.

Hakbang 5: Mag-imbak ng kopya sa ibang lugar

Ang panuntunan ay madalas tawaging 3-2-1: tatlong kopya ng data, sa dalawang magkaibang uri ng storage, at isang kopya na wala sa mismong site. Para sa maliit na app, ang praktikal na bersyon nito ay:

• Ang live na database
• Ang sariling automatic backup ng provider
• Ang sarili mong dump sa hiwalay na storage, gaya ng object storage bucket sa ibang account

Dagdag pa:

• Limitahan ang access. Naglalaman ang backup ng data ng bawat user. Ituring ito na parang live database.
• Magkaroon ng retention policy. Halimbawa, araw-araw na backup sa loob ng dalawang linggo at buwanang backup sa loob ng isang taon. Burahin ang luma nang sinasadya, at tandaang maaaring hilingin ng mga batas sa privacy na burahin mo ang personal na data kapag hiniling.
• Huwag kailanman i-commit ang backup sa Git. Ang dump sa repository ay naghihintay lang maging data leak.

Hakbang 6: Subukan ang restore

Ang backup ay kasing-ganda lang ng huling matagumpay mong restore. Kahit every ilang buwan, at pagkatapos ng anumang pagbabago sa proseso ng backup:

1. Gumawa ng bagong, walang lamang database. Huwag kailanman mag-restore sa ibabaw ng live database para lang sa test.
2. I-restore ang pinakabagong backup dito:

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

Para sa plain na .sql file, gamitin ang psql "$TEST_DATABASE_URL" -f backup.sql sa halip.

1. Tingnan kung nandoon ang bawat table, ihambing ang bilang ng row sa live database, at tingnan ang ilang pinakabagong record.
2. Ikonekta ang kopya ng app sa restored na database at mag-log in, kung kaya.
3. Isulat kung gaano katagal natapos ang restore. Iyon ang tunay mong recovery time.

Hakbang 7: Mag-backup bago ang mapanganib na pagbabago

Gumawa ng bagong backup bago ang:

• Pagpapatakbo ng database migration na nagbubura o nagpapalit ng pangalan ng column
• Bulk na pag-import ng data
• Pagpapahintulot sa AI agent na gumawa ng malalaking pagbabago sa data model
• Pagbubura ng lumang record

Sa AI-built na app, puwedeng baguhin ng agent ang istruktura ng table bilang bahagi ng isang feature. Ibinabalik ng checkpoint at version control ang code mo, pero hindi nila naibabalik ang mga burang row. Ang tatlumpung segundong backup bago ang malaking pagbabago ay murang insurance.

Mga karaniwang pagkakamali

• Pag-aakalang backup ang Git o code export. Code ang laman nila, hindi data.
• Hindi kailanman pagsubok ng restore. Maraming backup ang lumalabas na walang laman, kulang, o hindi mabasa kapag kailangan na.
• Pagtatago ng backup sa parehong account ng database. Isang na-compromise o na-close na account, at nawawala ang pareho.
• Pagkalimot sa mga na-upload na file. Ang database ang nag-iimbak ng path ng file; nasa storage ang mismong larawan.
• Pag-iiwan ng secret sa mga backup script. Basahin ang connection string mula sa environment variable, hindi mula sa text ng script. Tingnan ang paano itago nang ligtas ang API keys.

Backup at Mythex

Ang mga Mythex project ay puwedeng magkaroon ng nakalaang Postgres database, at ang connection details nito ay ini-inject sa workspace at sa na-publish na app. Walang inilalarawang feature para sa database backup o restore ang Mythex docs, kaya gumawa ka ng sarili mong plano: hilingin sa agent na gumawa ng dump, i-download ito, at itago sa ligtas na lugar, lalo na bago ang malalaking pagbabago. Ang project export (Pro) ay naglalaman ng code mo, na walang secret at node_modules; hindi ito naglalaman ng database rows. Tingnan ang Database at Data ownership sa docs. Para sa higit pa tungkol sa mismong database, basahin ang ano ang Postgres.

Checklist ng backup

• Nakapagpasya kung gaano karaming data ang kaya mong mawala at gaano katagal kang puwedeng mawalan ng app
• Nasuri kung anong automatic backup ang ibinibigay ng database host mo
• Tumatakbo ang sarili mong dump ayon sa iskedyul, at may alerto kapag pumalya
• Nakaimbak ang mga kopya nang hiwalay sa database, may limitadong access
• Nakasulat ang retention policy
• Na-back up din ang mga na-upload na file, hindi lang ang database
• Nasubukan ang restore sa walang lamang database, at nasuri ang bilang ng row
• May backup bago ang bawat mapanganib na pagbabago

Mga tanong