Kako sigurnosno kopirati bazu podataka aplikacije (i stvarno je vratiti)

Da sigurnosno kopiraš bazu podataka svoje aplikacije, izvezi je u datoteku prema rasporedu (za Postgres je standardni alat pg_dump), čuvaj kopije negdje odvojeno od baze i redovito vraćaj jednu u praznu bazu kako bi dokazao da radi. Napravi dodatnu kopiju odmah prije svake rizične promjene. Sigurnosna kopija koda, bilo da je riječ o GitHub repozitoriju ili izvozu, ne uključuje tvoje podatke.

Ovaj vodič je za ljude koji vode malu aplikaciju i žele prestati brinuti hoće li je izgubiti. Za primjere koristi Postgres, jer većina aplikacija izrađenih uz AI koristi upravo njega, ali načela vrijede za bilo koju bazu podataka.

Što sigurnosna kopija mora obuhvatiti

Aplikacija je više od svoje baze podataka. Znaj koji dio svaka kopija štiti.

Podaci su dio koji se ne može ponovno stvoriti. Kod se može ponovno napisati, a postavke ponovno unijeti; narudžbe tvojih kupaca ne mogu.

Korak 1: Odluči koliko podataka možeš izgubiti

Dva pitanja određuju tvoj plan sigurnosnih kopija:

• Koliko nedavnih podataka si možeš priuštiti izgubiti? Ako kopiraš jednom dnevno i baza podataka padne navečer, izgubit ćeš promjene tog dana. Za hobi aplikaciju to je u redu. Za aplikaciju koja prima narudžbe možda nije.
• Koliko dugo aplikacija može biti nedostupna dok vraćaš podatke? Mala baza podataka vraća se za nekoliko minuta. Velika može trajati znatno dulje, a to trebaš znati prije nego ti zatreba.

Za većinu malih aplikacija dobar početak je dnevna automatska kopija uz ručnu prije rizičnih promjena. Aplikacije koje uključuju novac ili zdravstvene podatke zaslužuju češće kopije ili upravljanu bazu podataka s oporavkom na određeni trenutak (mogućnost vraćanja na bilo koji trenutak, a ne samo na posljednju kopiju).

Korak 2: Provjeri što tvoj hosting već radi

Mnogi upravljani pružatelji baza podataka sami prave automatske kopije. Provjeri:

• Jesu li kopije uključene za tvoj paket i koliko često se izvode?
• Koliko dugo se čuvaju?
• Možeš li vratiti podatke na određeni trenutak ili samo na dnevni snimak?
• Možeš li preuzeti kopiju ili je samo možeš vratiti unutar njihovog sustava?

Kopije pružatelja su korisne, ali dijele jednu točku kvara s tvojom bazom podataka: račun. Ako se račun zatvori, obustavi ili se projekt obriše, kopije mogu nestati zajedno s njim. Zato želiš i vlastitu kopiju.

Korak 3: Napravi izvoz pomoću pg_dump

pg_dump izvozi Postgres bazu podataka u datoteku. Čita dosljedan snimak stanja, pa aplikacija može raditi dok on radi.

Tipična naredba, koja koristi vezu koju tvoja aplikacija već ima u varijabli okoline:

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

Što opcije rade:

• --format=custom zapisuje komprimiranu datoteku koju pg_restore može čitati i koja kasnije omogućuje vraćanje pojedinih tablica. Koristi --format=plain ako želiš čitljivu .sql datoteku.
• --no-owner izostavlja naredbe za vlasništvo, što olakšava vraćanje u drugu bazu podataka.
• Datum u nazivu datoteke razdvaja kopije jednu od druge.

Verzija pg_dump treba biti ista ili novija od verzije Postgresa tvoje baze podataka. Stariji pg_dump može odbiti rad.

Ako gradiš uz AI i ne želiš dirati naredbeni redak, možeš zatražiti:

Napravi sigurnosnu kopiju baze podataka aplikacije pomoću pg_dump u prilagođenom formatu, s današnjim datumom u nazivu datoteke. Nemoj ispisivati connection string ni nijednu tajnu. Kad završiš, javi mi naziv datoteke i veličinu.

Korak 4: Automatiziraj to

Ručne kopije se zaborave. Automatiziraj ih onime što tvoje okruženje podržava:

• Zakazane kopije tvog pružatelja baze podataka, ako ih nudi.
• Zakazani posao na poslužitelju ili CI servisu koji pokreće pg_dump i učitava datoteku u pohranu.
• Hostirana usluga za sigurnosne kopije koja se spaja na tvoju bazu podataka.

Bez obzira na izbor, neka te obavijesti kad kopija ne uspije. Posao sigurnosnih kopija koji je tiho zakazao tri mjeseca klasična je horor priča.

Korak 5: Čuvaj kopije na drugom mjestu

Pravilo palca često se naziva 3-2-1: tri kopije podataka, na dvije različite vrste pohrane, s jednom kopijom izvan lokacije. Za malu aplikaciju praktična verzija je:

• Živa baza podataka
• Automatske kopije tvog pružatelja
• Vlastiti izvozi u zasebnoj pohrani, na primjer objektnom bucketu na drugom računu

Prije svega:

• Ograniči pristup. Kopija sadrži podatke svakog korisnika. Tretiraj je kao živu bazu podataka.
• Zapiši pravila zadržavanja. Na primjer, dnevne kopije dva tjedna i mjesečne godinu dana. Stare kopije briši namjerno i zapamti da zakoni o privatnosti mogu zahtijevati brisanje osobnih podataka na zahtjev.
• Nikada ne commitaj kopije u Git. Izvoz u repozitoriju je curenje podataka koje čeka da se dogodi.

Korak 6: Testiraj vraćanje

Sigurnosna kopija vrijedi onoliko koliko i tvoje posljednje uspješno vraćanje. Barem svakih nekoliko mjeseci, i nakon svake promjene postupka sigurnosnih kopija:

1. Napravi novu, praznu bazu podataka. Nikada ne vraćaj preko žive baze radi testa.
2. Vrati najnoviju kopiju u nju:

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

Za običnu .sql datoteku koristi psql "$TEST_DATABASE_URL" -f backup.sql.

1. Provjeri postoji li svaka tablica, usporedi broj redaka sa živom bazom i pogledaj nekoliko nedavnih zapisa.
2. Pokreni kopiju aplikacije nad njom i prijavi se, ako možeš.
3. Zabilježi koliko je vraćanje trajalo. To je tvoje stvarno vrijeme oporavka.

Korak 7: Napravi kopiju prije rizičnih promjena

Napravi svježu kopiju odmah prije:

• Pokretanja migracije baze podataka koja briše ili preimenuje stupce
• Masovnog uvoza podataka
• Dopuštanja AI agentu da napravi velike promjene modela podataka
• Brisanja starih zapisa

U aplikaciji izrađenoj uz AI agent može promijeniti strukturu tablica kao dio neke funkcionalnosti. Checkpointi i verzioniranje vraćaju tvoj kod, ali ne vraćaju obrisane retke. Kopija od tridesetak sekundi prije velike promjene je jeftino osiguranje.

Česte greške

• Pretpostavka da je Git ili izvoz koda sigurnosna kopija. Sadrži kod, a ne podatke.
• Nikad ne testirati vraćanje. Mnoge kopije se pokažu praznima, nepotpunima ili nečitljivima tek kad ih trebaš.
• Držanje kopija na istom računu kao i baza podataka. Jedan kompromitirani ili zatvoreni račun gubi oboje.
• Zaboravljanje učitanih datoteka. Baza podataka pohranjuje putanju do datoteke; sama slika nalazi se u pohrani.
• Ostavljanje tajni u skriptama za sigurnosne kopije. Čitaj connection string iz varijable okoline, nikada iz teksta skripte. Pogledaj kako čuvati API ključeve na sigurnom.

Sigurnosne kopije i Mythex

Mythex projekti mogu imati zasebnu Postgres bazu podataka, a njezini podaci o vezi ubacuju se u radni prostor i objavljenu aplikaciju. Mythex dokumentacija ne opisuje značajku sigurnosnih kopija ni vraćanja baze podataka, pa planiraj svoje: zamoli agenta da napravi izvoz, preuzmi ga i čuvaj na sigurnom, posebno prije velikih promjena. Izvoz projekta (Pro) sadrži tvoj kod, bez tajni i node_modules; ne sadrži retke baze podataka. Pogledaj Database i Data ownership u dokumentaciji. Za više o samoj bazi podataka pročitaj što je Postgres.

Popis za sigurnosne kopije

• Odlučio koliko podataka možeš izgubiti i koliko dugo možeš biti nedostupan
• Provjerio koje automatske kopije nudi tvoj pružatelj baze podataka
• Tvoj vlastiti izvoz radi prema rasporedu, a greške te obavještavaju
• Kopije su pohranjene odvojeno od baze podataka, s ograničenim pristupom
• Pravila zadržavanja su zapisana
• Učitane datoteke su sigurnosno kopirane kao i baza podataka
• Vraćanje je testirano u praznu bazu podataka, s provjerenim brojem redaka
• Kopija je napravljena prije svake rizične promjene

Pitanja