Kaip sukurti programos duomenų bazės atsarginę kopiją (ir tikrai ją atkurti)

Norėdami sukurti programos duomenų bazės atsarginę kopiją, eksportuokite ją į failą pagal tvarkaraštį (Postgres atveju standartinė priemonė yra pg_dump), laikykite kopijas atskirai nuo duomenų bazės ir reguliariai atkurkite vieną į tuščią duomenų bazę, kad įsitikintumėte, jog ji veikia. Prieš bet kokį rizikingą pakeitimą padarykite papildomą kopiją. Jūsų kodo atsarginė kopija, ar tai GitHub saugykla, ar eksportas, neapima jūsų duomenų.

Šis vadovas skirtas žmonėms, kurie valdo nedidelę programą ir nori nebesijaudinti dėl jos praradimo. Pavyzdžiams naudojamas Postgres, nes dauguma DI sukurtų programų jį naudoja, tačiau principai taikomi bet kuriai duomenų bazei.

Ką turi apimti atsarginė kopija

Programą sudaro daugiau nei duomenų bazė. Žinokite, kurią dalį saugo kiekviena kopija.

Duomenys – tai dalis, kurios negalite atkurti. Kodą galima perrašyti, o nustatymus įvesti iš naujo; jūsų klientų užsakymų – ne.

1 žingsnis: nuspręskite, kiek galite prarasti

Du klausimai nustato jūsų atsarginių kopijų planą:

• Kiek neseniai įvestų duomenų galite sau leisti prarasti? Jei darote kopiją kartą per dieną ir duomenų bazė sugenda vakare, prarandate tos dienos pakeitimus. Mažai programai tai priimtina. Programai, kuri priima užsakymus, gali būti nepriimtina.
• Kiek laiko programa gali būti neveikianti, kol atkuriate? Maža duomenų bazė atkuriama per kelias minutes. Didelė gali užtrukti daug ilgiau, ir apie tai reikia žinoti iki to, kai prireiks.

Daugeliui mažų programų geras pradžios planas – automatinė kasdienė kopija ir rankinė kopija prieš rizikingus pakeitimus. Programos, kuriose susiję pinigai ar sveikatos duomenys, verta daryti dažnesnes kopijas arba naudoti valdomą duomenų bazę su atkūrimu iki konkretaus laiko (galimybe atkurti bet kurią akimirką, o ne tik iki paskutinės kopijos).

2 žingsnis: patikrinkite, ką jau daro jūsų talpykla

Daugelis valdomų duomenų bazių teikėjų atlieka automatines kopijas. Sužinokite:

• Ar kopijos įjungtos pagal jūsų planą ir kaip dažnai jos daromos?
• Kiek laiko jos saugomos?
• Ar galite atkurti iki konkretaus laiko, ar tik iki kasdienio momentinio vaizdo?
• Ar galite atsisiųsti kopiją, ar tik atkurti ją jų sistemoje?

Teikėjų kopijos naudingos, bet jos dalija vieną bendrą taškinio gedimo vietą su jūsų duomenų baze: paskyrą. Jei paskyra uždaroma, sustabdoma arba projektas ištrinamas, kopijos gali dingti kartu. Todėl verta turėti ir savo kopiją.

3 žingsnis: sukurkite kopiją su pg_dump

pg_dump eksportuoja Postgres duomenų bazę į failą. Ji skaito nuoseklų momentinį vaizdą, todėl programa gali toliau veikti, kol ji dirba.

Tipinė komanda, naudojanti jau turimą programos ryšio eilutę aplinkos kintamajame:

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

Ko reiškia parinktys:

• --format=custom sukuria suspaustą failą, kurį gali skaityti pg_restore, ir leidžia vėliau atkurti atskiras lenteles. Jei norite įskaitomo .sql failo, naudokite --format=plain.
• --no-owner praleidžia savininko komandas, todėl atkurti į kitą duomenų bazę tampa paprasčiau.
• Data failo pavadinime padeda atskirti kopijas.

pg_dump versija turi būti tokia pati kaip jūsų duomenų bazės Postgres versija arba naujesnė. Senesnis pg_dump gali atsisakyti veikti.

Jei kuriate su DI ir nenorite liestis prie komandinės eilutės, galite paprašyti:

Sukurk programos duomenų bazės kopiją naudodamas pg_dump pasirinktiniu formatu, failo pavadinime naudok šiandienos datą. Neatspausdink ryšio eilutės ar jokios paslapties. Kai baigsi, nurodyk failo pavadinimą ir jo dydį.

4 žingsnis: automatizuokite

Rankinės kopijos dažnai pamirštamos. Automatizuokite jas naudodami tai, ką palaiko jūsų sąranka:

• Jūsų duomenų bazės teikėjo planinės kopijos, jei jis jas siūlo.
• Planinė užduotis serveryje ar CI paslaugoje, kuri paleidžia pg_dump ir įkelia failą į saugyklą.
• Talpinama atsarginių kopijų paslauga, kuri prisijungia prie jūsų duomenų bazės.

Kokį variantą bepasirinktumėte, pasirūpinkite, kad jis praneštų, kai kopija nepavyksta. Atsarginės kopijos užduotis, kuri tyliai nepavyko tris mėnesius, – klasikinė siaubo istorija.

5 žingsnis: laikykite kopijas kitur

Taisyklė dažnai vadinama 3-2-1: trys jūsų duomenų kopijos, dviejose skirtingose saugojimo vietose, viena – už savo vietos ribų. Mažai programai praktiškas variantas yra:

• Gyva duomenų bazė
• Teikėjo automatinės kopijos
• Jūsų pačių kopijos atskirai saugykloje, pavyzdžiui objektų saugyklos segtuve kitoje paskyroje

Taip pat:

• Riboti prieigą. Atsarginėje kopijoje yra kiekvieno naudotojo duomenys. Elkitės su ja kaip su gyva duomenų baze.
• Turėkite saugojimo taisyklę. Pavyzdžiui, kasdienės kopijos dviem savaitėms ir mėnesinės – vieniems metams. Senas kopijas trinkite sąmoningai, prisiminkite, kad privatumo įstatymai gali reikalauti ištrinti asmens duomenis pagal prašymą.
• Niekada nedėkite kopijų į Git. Kopija saugykloje – tai duomenų nutekėjimas, laukiantis įvykio.

6 žingsnis: išbandykite atkūrimą

Atsarginė kopija yra tiek verta, kiek jos paskutinis sėkmingas atkūrimas. Bent kas kelis mėnesius ir po kiekvieno atsarginių kopijų proceso pakeitimo:

1. Sukurkite naują, tuščią duomenų bazę. Testui niekada neatkurkite virš gyvos duomenų bazės.
2. Atkurkite naujausią kopiją į ją:

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

Jei turite paprastą .sql failą, vietoj to naudokite psql "$TEST_DATABASE_URL" -f backup.sql.

1. Patikrinkite, ar egzistuoja kiekviena lentelė, palyginkite eilučių skaičius su gyva duomenų baze ir pažiūrėkite kelis naujausius įrašus.
2. Jei galite, paleiskite programos kopiją, nukreiptą į ją, ir prisijunkite.
3. Užsirašykite, kiek laiko užtruko atkūrimas. Tai jūsų tikras atkūrimo laikas.

7 žingsnis: darykite kopiją prieš rizikingus pakeitimus

Prieš bet ką iš šio sąrašo padarykite naują kopiją:

• Duomenų bazės migracijos, kuri panaikina arba pervadina stulpelius, vykdymas
• Didelio kiekio duomenų importas
• DI agento leidimas atlikti didelius duomenų modelio pakeitimus
• Senų įrašų trynimas

DI sukurtoje programoje agentas gali keisti lentelių struktūrą kaip funkcijos dalį. Kontrolinės vietos ir versijų valdymas atkuria jūsų kodą, bet neatkuria ištrintų eilučių. Trisdešimties sekundžių kopija prieš didelį pakeitimą yra pigi apsauga.

Dažnos klaidos

• Manymas, kad Git ar kodo eksportas yra atsarginė kopija. Jame yra kodas, o ne duomenys.
• Niekada netestuoti atkūrimo. Daugelis kopijų paaiškėja tuščios, neišsamios arba neskaitomos tik tada, kai jų reikia.
• Kopijų laikymas toje pačioje paskyroje kaip ir duomenų bazė. Viena pažeista arba uždaryta paskyra praranda abu.
• Įkeltų failų pamiršimas. Duomenų bazėje saugomas failo kelias; pats paveikslėlis gyvena saugykloje.
• Paslapčių laikymas atsarginių kopijų scenarijuose. Ryšio eilutę skaitykite iš aplinkos kintamojo, niekada iš scenarijaus teksto. Žr. kaip saugoti API raktus.

Atsarginės kopijos ir Mythex

Mythex projektai gali turėti atskirą Postgres duomenų bazę, o jos ryšio duomenys įdedami į darbo erdvę ir paskelbtą programą. Mythex dokumentacijoje nėra aprašyta duomenų bazės atsarginės kopijos ar atkūrimo funkcijos, todėl planuokite savo: paprašykite agento sukurti kopiją, atsisiųskite ją ir laikykite saugioje vietoje, ypač prieš didelius pakeitimus. Projekto eksportas (Pro) apima jūsų kodą, paslaptys ir node_modules nėra įtraukti; jame nėra duomenų bazės įrašų. Daugiau žr. Database ir Data ownership dokumentacijoje. Apie pačią duomenų bazę skaitykite kas yra Postgres.

Atsarginių kopijų kontrolinis sąrašas

• Nuspręsta, kiek duomenų galite sau leisti prarasti ir kiek laiko galite būti neveikiantys
• Patikrinta, kokias automatines kopijas teikia jūsų duomenų bazės talpintojas
• Jūsų kopija veikia pagal tvarkaraštį, o nesėkmės jus įspėja
• Kopijos laikomos atskirai nuo duomenų bazės, su ribota prieiga
• Saugojimo taisyklė užrašyta
• Įkelti failai įtraukti į atsargines kopijas kartu su duomenų baze
• Atkūrimas išbandytas į tuščią duomenų bazę, eilučių skaičiai patikrinti
• Kopija daroma prieš kiekvieną rizikingą pakeitimą

Klausimai