Kako varnostno kopirati podatkovno bazo aplikacije (in jo tudi res obnoviti)

Za varnostno kopiranje baze podatkov aplikacije jo izvozi v datoteko po urniku (za Postgres je standardno orodje pg_dump), hrani kopije ločeno od baze in redno obnovi eno kopijo v prazno bazo, da dokažeš, da deluje. Tik pred vsako tvegano spremembo naredi dodatno kopijo. Varnostna kopija kode, bodisi repozitorij na GitHubu bodisi izvoz, ne vsebuje tvojih podatkov.

Ta vodnik je namenjen ljudem, ki vodijo majhno aplikacijo in se želijo nehati bati, da jo bodo izgubili. Za primere uporablja Postgres, ker večina aplikacij, zgrajenih z umetno inteligenco, uporablja prav njega, a načela veljajo za katero koli bazo.

Kaj mora varnostna kopija pokrivati

Aplikacija je več kot njena baza podatkov. Vedi, kateri del ščiti posamezna kopija.

Podatki so tisti del, ki ga ni mogoče ponovno ustvariti. Kodo je mogoče napisati znova in nastavitve znova vnesti; naročil tvojih strank pa ne.

1. korak: Odloči, koliko lahko izgubiš

Dve vprašanji določata tvoj načrt varnostnih kopij:

• Koliko nedavnih podatkov si lahko privoščiš izgubiti? Če varnostno kopiraš enkrat na dan in baza odpove zvečer, izgubiš spremembe tistega dne. Pri hobi aplikaciji je to v redu. Pri aplikaciji, ki sprejema naročila, morda ni.
• Koliko časa je lahko aplikacija nedosegljiva, medtem ko obnavljaš? Majhna baza se obnovi v nekaj minutah. Velika lahko traja precej dlje, in to želiš vedeti, preden jo potrebuješ.

Za večino majhnih aplikacij je dobro izhodišče dnevna samodejna kopija in ročna kopija pred tveganimi spremembami. Aplikacije, pri katerih gre za denar ali zdravstvene podatke, zaslužijo pogostejše kopije ali upravljano bazo s časovno obnovo (možnost obnoviti stanje na kateri koli trenutek, ne le na zadnjo kopijo).

2. korak: Preveri, kaj ti ponudnik že omogoča

Mnogi ponudniki upravljanih baz samodejno ustvarjajo varnostne kopije. Ugotovi:

• Ali so varnostne kopije vključene v tvojem paketu in kako pogosto se izvajajo?
• Kako dolgo se hranijo?
• Ali lahko obnoviš stanje na določen trenutek ali samo na dnevni posnetek?
• Ali lahko kopijo preneseš, ali jo lahko obnoviš le znotraj njihovega sistema?

Varnostne kopije ponudnika so uporabne, vendar imajo skupno točko odpovedi z bazo: račun. Če je račun zaprt, suspendiran ali je projekt izbrisan, lahko kopije izginejo skupaj z njim. Zato potrebuješ tudi svojo kopijo.

3. korak: Naredi izpis s pg_dump

pg_dump izvozi bazo Postgres v datoteko. Prebere dosleden posnetek, zato lahko aplikacija med delom še naprej teče.

Tipičen ukaz, ki uporablja povezovalni niz, ki ga tvoja aplikacija že ima v okoljski spremenljivki:

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

Kaj počnejo možnosti:

• --format=custom zapiše stisnjeno datoteko, ki jo lahko bere pg_restore, in kasneje omogoča obnovitev posameznih tabel. Če želiš berljivo datoteko .sql, uporabi --format=plain.
• --no-owner izpusti ukaze za lastništvo, kar olajša obnovitev v drugo bazo.
• Datum v imenu datoteke loči kopije med seboj.

Različica pg_dump naj bo enaka ali novejša od različice Postgresa tvoje baze. Starejši pg_dump se lahko odmakne od zagona.

Če gradiš z umetno inteligenco in se ne želiš ukvarjati z ukazno vrstico, lahko preprosto vprašaš:

Ustvari varnostno kopijo baze podatkov aplikacije z uporabo pg_dump v custom formatu, z današnjim datumom v imenu datoteke. Ne izpisuj povezovalnega niza ali kakršne koli skrivnosti. Ko končaš, mi povej ime datoteke in njeno velikost.

4. korak: Avtomatiziraj

Ročne kopije se pozabijo. Avtomatiziraj jih z:

• Načrtovane varnostne kopije tvojega ponudnika baze, če jih ponuja.
• Načrtovano opravilo na strežniku ali storitvi CI, ki zažene pg_dump in naloži datoteko v shrambo.
• Gostovana storitev za varnostne kopije, ki se poveže z bazo.

Kakršno koli možnost izbereš, poskrbi, da te obvesti, ko kopija ne uspe. Opravilo za varnostno kopiranje, ki je tiho odpovedalo tri mesece, je klasična grozljivka.

5. korak: Hrani kopije na drugem mestu

Pravilo palca se pogosto imenuje 3-2-1: tri kopije podatkov, na dveh različnih vrstah shrambe, ena izven kraja. Za majhno aplikacijo je praktična različica:

• Živa baza podatkov
• Samodejne varnostne kopije ponudnika
• Lastni izpisi v ločeni shrambi, na primer v vedru objektne shrambe na drugem računu

Poleg tega:

• Omeji dostop. Varnostna kopija vsebuje podatke vseh uporabnikov. Obravnavaj jo kot živo bazo.
• Določi pravilnik hrambe. Na primer dnevne kopije za dva tedna in mesečne za leto dni. Stare kopije briši namerno, in ne pozabi, da te zakoni o zasebnosti lahko zavezujejo, da na zahtevo izbrišeš osebne podatke.
• Nikoli ne dodajaj varnostnih kopij v Git. Izpis v repozitoriju je puščanje podatkov, ki čaka, da se zgodi.

6. korak: Preizkusi obnovitev

Varnostna kopija je le toliko dobra, kolikor je tvoja zadnja uspešna obnovitev. Vsaj vsakih nekaj mesecev in po vsaki spremembi postopka varnostnega kopiranja:

1. Ustvari novo, prazno bazo. Nikoli ne obnavljaj preko žive baze, ko preizkušaš.
2. Obnovi zadnjo varnostno kopijo vanjo:

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

Za navadno datoteko .sql uporabi namesto tega psql "$TEST_DATABASE_URL" -f backup.sql.

1. Preveri, ali obstaja vsaka tabela, primerjaj števila vrstic z živo bazo in preglej nekaj zadnjih zapisov.
2. Če lahko, usmeri kopijo aplikacije nanjo in se prijavi.
3. Zapiši, koliko časa je trajala obnovitev. To je tvoj pravi čas okrevanja.

7. korak: Varnostno kopiraj pred tveganimi spremembami

Tik pred naslednjimi koraki naredi svežo kopijo:

• Zagon migracije baze, ki briše ali preimenuje stolpce
• Množični uvoz podatkov
• Dovolitev agentu z umetno inteligenco, da naredi velike spremembe podatkovnega modela
• Brisanje starih zapisov

V aplikaciji, zgrajeni z umetno inteligenco, lahko agent spremeni strukturo tabel kot del funkcije. Kontrolne točke in nadzor različic povrnejo tvojo kodo, vendar ne obnovijo izbrisanih vrstic. Pol minute varnostnega kopiranja pred veliko spremembo je poceni zavarovanje.

Pogoste napake

• Predpostavka, da je Git ali izvoz kode varnostna kopija. Vsebuje kodo, ne podatkov.
• Obnovitev nikoli ni bila preizkušena. Mnoge varnostne kopije se izkažejo za prazne, nepopolne ali nečitljive šele takrat, ko jih potrebuješ.
• Hranjenje kopij na istem računu kot baza. En ogrožen ali zaprt račun izgubi oboje.
• Pozabljene naložene datoteke. Baza hrani pot do datoteke; sama slika je v shrambi.
• Skrivnosti v skriptih za varnostno kopiranje. Povezovalni niz preberi iz okoljske spremenljivke, nikoli iz besedila skripta. Glej kako varno hraniti API ključe.

Varnostne kopije in Mythex

Projekti v Mythexu lahko imajo namensko bazo Postgres, njeni podatki za povezavo pa so vneseni v delovni prostor in objavljeno aplikacijo. Dokumentacija Mythexa ne opisuje funkcije varnostnega kopiranja ali obnovitve baze, zato načrtuj svojo: od agenta zahtevaj izpis, ga prenesi in hrani na varnem, zlasti pred velikimi spremembami. Izvoz projekta (Pro) vsebuje tvojo kodo, brez skrivnosti in mape node_modules; ne vsebuje vrstic iz baze. Glej Database in Data ownership v dokumentaciji. Za več o sami bazi preberi kaj je Postgres.

Kontrolni seznam za varnostne kopije

• Odločeno, koliko podatkov si lahko privoščiš izgubiti in koliko časa lahko aplikacija ne deluje
• Preverjeno, katere samodejne varnostne kopije ponuja tvoj ponudnik baze
• Lastni izpis teče po urniku in napake te opozorijo
• Kopije so shranjene ločeno od baze, z omejenim dostopom
• Pravilnik hrambe je zapisan
• Naložene datoteke so varnostno kopirane skupaj z bazo
• Obnovitev je preizkušena v prazni bazi, števila vrstic so preverjena
• Varnostna kopija je narejena pred vsako tvegano spremembo

Vprašanja