Kako napraviti sigurnosnu kopiju baze podataka aplikacije (i stvarno je vratiti)

Da biste napravili sigurnosnu kopiju baze aplikacije, izvezite je u fajl po rasporedu (za Postgres, standardni alat je pg_dump), čuvajte kopije na mjestu odvojenom od baze i redovno vraćajte jednu u praznu bazu da biste dokazali da radi. Napravite dodatnu kopiju odmah prije svake rizične promjene. Sigurnosna kopija koda, bilo da je to GitHub repozitorij ili izvoz, ne uključuje vaše podatke.

Ovaj vodič je za ljude koji vode malu aplikaciju i žele da prestanu brinuti da će je izgubiti. Za primjere koristi Postgres, jer većina aplikacija napravljenih uz AI koristi upravo njega, ali principi važe za svaku bazu.

Šta sigurnosna kopija mora pokriti

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

Podaci su dio koji se ne može ponovo napraviti. Kod se može ponovo napisati, a postavke ponovo unijeti, ali narudžbe vaših kupaca ne mogu.

Korak 1: Odlučite koliko možete da izgubite

Dva pitanja određuju vaš plan sigurnosnih kopija:

• Koliko skorašnjih podataka možete da izgubite? Ako pravite kopiju jednom dnevno, a baza otkaže uveče, izgubićete promjene tog dana. Za hobi aplikaciju to je u redu. Za aplikaciju koja prima narudžbe, možda nije.
• Koliko aplikacija može biti nedostupna dok vraćate podatke? Mala baza se vrati za nekoliko minuta. Velika može trajati mnogo duže, a to želite znati prije nego što vam zatreba.

Za većinu malih aplikacija dobar početak je dnevna automatska kopija plus ručna kopija prije rizičnih promjena. Aplikacije u kojima su uključeni novac ili zdravstveni podaci zaslužuju češće kopije ili upravljanu bazu sa oporavkom na tačno određeni trenutak (mogućnost vraćanja na bilo koji trenutak, a ne samo na posljednju kopiju).

Korak 2: Provjerite šta vaš provider već radi

Mnogi provideri upravljanih baza podataka sami prave automatske kopije. Provjerite:

• Da li su kopije uključene za vaš plan i koliko često se prave?
• Koliko dugo se čuvaju?
• Možete li vratiti na tačan trenutak ili samo na dnevni snimak?
• Možete li preuzeti kopiju ili je samo možete vratiti unutar njihovog sistema?

Kopije providera su korisne, ali dijele jednu zajedničku tačku otkaza sa bazom: nalog. Ako je nalog zatvoren, obustavljen ili je projekat obrisan, kopije mogu nestati zajedno s njim. Zato vam treba i vlastita kopija.

Korak 3: Napravite dump sa pg_dump

pg_dump izvozi Postgres bazu u fajl. Čita konzistentan snimak, pa aplikacija može raditi dok on radi.

Tipična komanda, koja koristi string za povezivanje koji vaša aplikacija već ima u varijabli okruženja:

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

Šta opcije rade:

• --format=custom piše komprimovan fajl koji pg_restore može čitati i omogućava vraćanje pojedinačnih tabela kasnije. Koristite --format=plain ako želite čitljivi .sql fajl.
• --no-owner izostavlja komande za vlasništvo, što olakšava vraćanje u drugu bazu.
• Datum u imenu fajla razdvaja kopije jednu od druge.

Verzija pg_dump treba biti ista kao ili novija od verzije vaše Postgres baze. Stariji pg_dump može odbiti da radi.

Ako gradite uz AI i ne želite da koristite komandnu liniju, možete zatražiti:

Napravi sigurnosnu kopiju baze aplikacije pomoću pg_dump u custom formatu, sa današnjim datumom u imenu fajla. Ne ispisuj string za povezivanje niti bilo koju tajnu. Kada završiš, javi mi ime fajla i njegovu veličinu.

Korak 4: Automatizujte

Ručne kopije se zaborave. Automatizujte ih onim što vaše okruženje podržava:

• Zakazane kopije vašeg providera baze, ako ih nudi.
• Zakazani zadatak na serveru ili CI servisu koji pokreće pg_dump i šalje fajl u pohranu.
• Hostovani servis za kopije koji se povezuje na vašu bazu.

Bez obzira na izbor, neka vas obavijesti kada kopija ne uspije. Zadatak za kopije koji tiho ne radi tri mjeseca je klasična horor priča.

Korak 5: Čuvajte kopije na drugom mjestu

Pravilo koje se često naziva 3-2-1: tri kopije podataka, na dvije različite vrste pohrane, jedna van lokacije. Za malu aplikaciju praktična verzija izgleda ovako:

• Živa baza
• Automatske kopije providera
• Vlastiti dumpovi u zasebnoj pohrani, kao što je bucket za objektnu pohranu na drugom nalogu

Takođe:

• Ograničite pristup. Kopija sadrži podatke svakog korisnika. Tretirajte je kao živu bazu.
• Odredite politiku čuvanja. Na primjer, dnevne kopije dvije sedmice i mjesečne godinu dana. Stare kopije brišite namjerno i zapamtite da vas zakoni o privatnosti mogu obavezati da obrišete lične podatke na zahtjev.
• Nikada ne commitujte kopije u Git. Dump u repozitorijumu je curenje podataka koje čeka da se dogodi.

Korak 6: Testirajte vraćanje

Sigurnosna kopija vrijedi onoliko koliko vaše posljednje uspješno vraćanje. Bar svakih nekoliko mjeseci, i nakon svake promjene u procesu pravljenja kopija:

1. Napravite novu, praznu bazu. Nikada ne vraćajte preko žive baze radi testa.
2. Vratite najnoviju kopiju u nju:

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

Za običan .sql fajl koristite psql "$TEST_DATABASE_URL" -f backup.sql.

1. Provjerite da li svaka tabela postoji, uporedite broj redova sa živom bazom i pogledajte nekoliko najnovijih zapisa.
2. Ako možete, pokrenite kopiju aplikacije nad njom i prijavite se.
3. Zabilježite koliko je vraćanje trajalo. To je vaše stvarno vrijeme oporavka.

Korak 7: Pravite kopiju prije rizičnih promjena

Napravite svježu kopiju neposredno prije:

• Pokretanja migracije baze koja briše ili preimenuje kolone
• Uvoza podataka u većem obimu
• Dozvoljavanja AI agentu da napravi velike promjene modela podataka
• Brisanja starih zapisa

U aplikaciji napravljenoj uz AI agent može promijeniti strukturu tabela kao dio funkcije. Checkpointi i verzionisanje vraćaju vaš kod, ali ne vraćaju obrisane redove. Kopija od trideset sekundi prije velike promjene je jeftino osiguranje.

Česte greške

• Pretpostavka da su Git ili izvoz koda sigurnosna kopija. Sadrže kod, a ne podatke.
• Nikada nije testirano vraćanje. Mnoge kopije se pokažu praznim, nepotpunim ili nečitljivim tek kada zatreba.
• Čuvanje kopija na istom nalogu kao baza. Jedan ugrožen ili zatvoren nalog gubi oboje.
• Zaboravljeni učitani fajlovi. Baza čuva putanju do fajla; sama slika živi u pohrani.
• Tajne ostavljene u skriptama za kopije. Čitajte string za povezivanje iz varijable okruženja, nikada iz teksta skripte. Pogledajte kako sačuvati API ključeve.

Sigurnosne kopije i Mythex

Projekti u Mythexu mogu imati zasebnu Postgres bazu, a njeni podaci za povezivanje se ubacuju u radni prostor i objavljenu aplikaciju. Dokumentacija Mythexa ne opisuje funkciju pravljenja ili vraćanja kopije baze, pa planirajte svoju: zatražite od agenta da napravi dump, preuzmite ga i čuvajte na sigurnom, naročito prije velikih promjena. Izvoz projekta (Pro) sadrži vaš kod, bez tajni i node_modules; ne sadrži redove iz baze. Pogledajte Database i Data ownership u dokumentaciji. Za više o samoj bazi pročitajte šta je Postgres.

Kontrolna lista za sigurnosne kopije

• Odlučeno koliko podataka možete da izgubite i koliko dugo možete biti nedostupni
• Provjeren šta vaš provider baze automatski pravi kao kopije
• Vaša vlastita kopija radi po rasporedu, a greške vas obavještavaju
• Kopije su sačuvane odvojeno od baze, sa ograničenim pristupom
• Politika čuvanja zapisana
• Učitani fajlovi sigurnosno kopirani kao i baza
• Vraćanje testirano u praznu bazu, uz provjeru broja redova
• Kopija napravljena prije svake rizične promjene

Pitanja