Kako napraviti rezervnu kopiju baze aplikacije (i stvarno je vratiti)

Da napravite rezervnu kopiju baze aplikacije, izvezite je u fajl po rasporedu (za Postgres, standardni alat je pg_dump), čuvajte kopije na mestu odvojenom od baze i redovno vraćajte jednu u praznu bazu da biste dokazali da radi. Pre svake rizične izmene napravite dodatnu kopiju. Rezervna kopija koda, bilo da je to GitHub repozitorijum ili izvoz, ne sadrži vaše podatke.

Ovaj vodič je za ljude koji vode malu aplikaciju i žele da prestanu da brinu hoće li je izgubiti. Primeri koriste Postgres, jer većina aplikacija pravljenih uz AI koristi baš njega, ali principi važe za svaku bazu.

Šta rezervna kopija mora da pokrije

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

Podaci su deo koji ne može da se ponovo napravi. Kod se može ponovo napisati, a podešavanja ponovo uneti; porudžbine vaših kupaca ne mogu.

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

Dva pitanja određuju plan rezervnih kopija:

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

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

Korak 2: Proverite šta vaš host već radi

Mnogi upravljani provajderi baza prave automatske kopije. Proverite:

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

Kopije provajdera su korisne, ali dele jednu tačku otkaza sa bazom: nalog. Ako se nalog zatvori, obustavi ili se projekat obriše, kopije mogu nestati zajedno s njim. Zato vam treba i sopstvena kopija.

Korak 3: Napravite dump pomoću pg_dump

pg_dump izvozi Postgres bazu u fajl. Čita dosledan snimak, pa aplikacija može da radi dok on traje.

Tipična komanda, koja koristi vezu koju vaša aplikacija već ima u promenljivoj okruženja:

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

Šta opcije rade:

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

Verzija pg_dump treba da bude ista kao verzija Postgresa vaše baze ili novija. Stariji pg_dump može odbiti da radi.

Ako pravite aplikaciju uz AI i ne želite da koristite komandnu liniju, možete da zamolite:

Napravi kopiju baze aplikacije pomoću pg_dump u prilagođenom formatu, sa današnjim datumom u nazivu fajla. Nemoj da ispisuješ connection string niti bilo koju tajnu. Javi mi naziv fajla i njegovu veličinu kad završiš.

Korak 4: Automatizujte

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

• Zakazane kopije vašeg provajdera baze, ako ih nudi.
• Zakazan posao na serveru ili CI servisu koji pokreće pg_dump i otprema fajl u skladište.
• Hostovana usluga za kopije koja se povezuje na vašu bazu.

Ma koju da izaberete, neka vas obavesti kad kopija ne uspe. Posao za kopije koji je tiho pao tri meseca je klasična horor priča.

Korak 5: Čuvajte kopije na drugom mestu

Pravilo koje se često naziva 3-2-1: tri kopije podataka, na dve različite vrste skladišta, uz jednu kopiju van lokacije. Za malu aplikaciju praktična verzija je:

• Živa baza
• Automatske kopije provajdera
• Vaši sopstveni dump-ovi u odvojenom skladištu, na primer u bucket-u za objekte na drugom nalogu

Takođe:

• Ograničite pristup. Kopija sadrži podatke svakog korisnika. Tretirajte je kao živu bazu.
• Odredite pravila čuvanja. Na primer, dnevne kopije dve nedelje, a mesečne godinu dana. Stare kopije brišite namerno, i zapamtite da vas zakoni o privatnosti mogu obavezati da obrišete lične podatke na zahtev.
• Nikad ne commit-ujte kopije u Git. Dump u repozitorijumu je curenje podataka koje čeka da se dogodi.

Korak 6: Proverite vraćanje

Kopija vredi koliko i vaše poslednje uspešno vraćanje. Bar svakih nekoliko meseci, i nakon svake izmene procesa pravljenja kopija:

1. Napravite novu, praznu bazu. Nikad 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 umesto toga koristite psql "$TEST_DATABASE_URL" -f backup.sql.

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

Korak 7: Pravite kopiju pre rizičnih izmena

Napravite svežu kopiju neposredno pre:

• Pokretanja migracije koja briše ili preimenuje kolone
• Masovnog uvoza podataka
• Dozvoljavanja AI agentu da pravi velike izmene modela podataka
• Brisanja starih zapisa

U aplikaciji pravljenoj uz AI, agent može da menja strukturu tabela kao deo neke funkcije. Checkpoint-i i kontrola verzija vraćaju kod, ali ne vraćaju obrisane redove. Kopija od trideset sekundi pre velike izmene je jeftino osiguranje.

Česte greške

• Pretpostavka da su Git ili izvoz koda rezervna kopija. Imaju kod, a ne podatke.
• Nikad ne proveravati vraćanje. Mnoge kopije se pokažu praznim, nepotpunim ili nečitljivim tek kad zatreba.
• Čuvanje kopija na istom nalogu kao baza. Jedan ugrožen ili zatvoren nalog gubi oboje.
• Zaboravljanje otpremljenih fajlova. Baza čuva putanju do fajla; sama slika je u skladištu.
• Ostavljanje tajni u skriptama za kopije. Connection string čitajte iz promenljive okruženja, nikad iz teksta skripte. Pogledajte kako čuvati API ključeve bezbedno.

Rezervne kopije i Mythex

Mythex projekti mogu imati posebnu Postgres bazu, a njeni podaci za povezivanje se ubacuju u radni prostor i u objavljenu aplikaciju. Dokumentacija Mythexa ne opisuje funkciju pravljenja ili vraćanja kopije baze, pa sami isplanirajte kopije: zamolite agenta da napravi dump, preuzmite ga i sačuvajte na sigurnom mestu, naročito pre velikih izmena. Izvoz projekta (Pro) sadrži vaš kod, uz izostavljene tajne 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 kopije

• Odlučeno koliko podataka smete da izgubite i koliko možete da budete nedostupni
• Proverite šta automatske kopije vašeg provajdera baze nude
• Vaš dump radi po rasporedu, a neuspeh vas obaveštava
• Kopije se čuvaju odvojeno od baze, uz ograničen pristup
• Pravila čuvanja su zapisana
• Otpremljeni fajlovi su obuhvaćeni kopijom kao i baza
• Vraćanje je provereno u praznu bazu, a brojevi redova upoređeni
• Kopija se pravi pre svake rizične izmene

Pitanja