
PostgreSQLi varukoopia: pg_dump üksi ei anna punktiaja taastamist

Kui vajad ühe andmebaasi koopiat kindlast varundushetkest, vali pg_dump. Kui pead pärast ekslikku muudatust taastama seisu vahetult enne seda, vajad füüsilist baaskoopiat ja katkematut WAL-arhiivi. PostgreSQLi punktiaja taastamise juhend selgitab, et WAL-i saab taasesitada füüsilisest baaskoopiast valitud hetkeni; loogiline dump ei sobi selle taasesituse lähtekoopiaks.
Valik sõltub lubatud andmekaost ja katkestuse pikkusest. Andmebaasi maht mõjutab kopeerimise ja taastamise aega, kuid ei otsusta üksi, kas vajad punktiaja taastamist: ka väikeses andmebaasis võib viimase dump'i järel tehtud muudatuste kaotus olla lubamatu.
Vali meetod taastamiseesmärgi järgi
Pane kirja lubatud andmekadu ehk RPO ja lubatud katkestus ehk RTO. Need on teenuse nõuded, mille täitmist saab hinnata alles taastamiskatsega. Seejärel vali töövoog selle järgi, millist seisu pead suutma tagasi saada.
- Kui piisab viimase dump'i seisust ja selle sisse laadimine mahub lubatud katkestusse, kasuta pg_dump'i. See võimaldab taastada ühe andmebaasi, kuid hilisema hetkeni WAL-i abil edasi liikuda ei saa.
- Kui piisab füüsilise baaskoopia seisust, kasuta pg_basebackup'i koos koopia käivitamiseks vajaliku WAL-iga. Taastatav üksus on kogu klaster, mitte üks valitud andmebaas.
- Kui pead jõudma valitud hetkeni pärast baaskoopia lõppu, arhiveeri WAL pidevalt. Taastamiseks peab jada olema kättesaadav vähemalt baaskoopia algusest soovitud hetkeni.
Dump'i tegemine võib mahtuda varundusaknasse, kuid selle taastamine ületada RTO. Mõõda seetõttu mõlemat toimingut oma andmemahuga. WAL-arhiivi puhul võrdle nõutud RPO-d tegeliku arhiveerimisviivitusega: edukalt lõppenud baaskoopia ei tõesta, et viimased muudatused on juba arhiivis.
Kui piisab varundushetkest: tee ja taasta loogiline dump

pg_dump salvestab ühe andmebaasi järjepideva loogilise seisu ning kohandatud vorming võimaldab objekte pg_restore'iga valikuliselt taastada. PostgreSQLi SQL-dump'i juhend täpsustab, et pg_dump ei hõlma klastri rolle ega tablespace'ide määratlusi; nende jaoks kasuta eraldi käsku pg_dumpall --globals-only.
- Loo koopia käsuga pg_dump -Fc -d appdb -f /backup/appdb.dump. Arvuta failile kontrollsumma käsuga sha256sum /backup/appdb.dump > /backup/appdb.dump.sha256. Kui taastamiseks on vaja klastriüleseid rolle ja tablespace'e, salvesta eraldi ka käsu pg_dumpall --globals-only väljund.
- Kontrolli proovimasinasse viidud faili käsuga sha256sum -c /backup/appdb.dump.sha256. Loo tühi andmebaas käsuga createdb -T template0 appdb_test ja laadi sisu käsuga pg_restore -e -d appdb_test /backup/appdb.dump.
- Kontrolli oluliste tabelite olemasolu, rakenduse päringuid ja õigusi. Kui taastasid ka klastriülesed objektid, tee seda enne andmebaasi sisu laadimist ning veendu, et tablespace'ide asukohad sobivad proovikeskkonda.
Kontrollsumma näitab, kas dump'i fail on pärast summa arvutamist muutunud. Edukas pg_restore näitab, et arhiiv õnnestus sisse laadida; rakenduse jaoks vajalike andmete ja ligipääsu toimimist tuleb kontrollida eraldi.
Kui vajad baaskoopiat: säilita ka hilisem WAL
pg_basebackup kopeerib töötava PostgreSQLi klastri füüsilised failid. PostgreSQLi pg_basebackupi käsujuhend kirjeldab, kuidas -Xs lisab koopia käivitamiseks vajaliku WAL-i, ning hoiatab, et --no-sync võib operatsioonisüsteemi krahhi järel jätta koopia rikutuks. Näidiskäsk on pg_basebackup -h db.example -U repl -D /backup/base -Fp -Xs -P --manifest-checksums=SHA256; asenda host ja kasutaja oma keskkonna väärtustega.
Replikatsiooniks kasutataval kontol peab olema vajalik õigus ning server peab ühenduse lubama. Kui kasutad eraldi tablespace'e, kontrolli enne käsku nende sihtkohti: tavalise failivorminguga baaskoopia kirjutab need vaikimisi lähteklastriga samadesse asukohtadesse. Samas masinas tehtava koopia jaoks võib vaja minna tablespace'ide ümberpaigutust.
Valik -Xs katab baaskoopia tegemiseks vajaliku WAL-i. Hilisemasse aega taastumiseks peab arhiveerimine jätkuma ka pärast koopia lõppu. Seadista wal_level väärtusele replica või kõrgemale, archive_mode väärtusele on ning archive_command oma arhiivi jaoks nii, et olemasolevat WAL-faili ei kirjutata üle. Kontrolli arhiveerimise õnnestumist enne esimese baaskoopia tegemist; ka väikese kirjutuskoormuse korral võib lõpetamata WAL-segmendi arhiivi jõudmine viibida.
Valmis koopia peal käivita pg_verifybackup /backup/base. Manifesti ja failide kontroll aitab avastada puuduvaid või muutunud faile, kuid ei näita, kas rakendus taastatud klastriga töötab. Tootmisvarukoopia puhul ära lisa kiiruse pärast --no-sync valikut: see jätab ära ootamise, kuni failid on turvaliselt kettale kirjutatud.
Proovi punktiaja taastamist eraldi masinas

Enne katset veendu, et valitud sihthetk on baaskoopia lõppemisest hilisem ja arhiivis on katkematu WAL-jada baaskoopia algusest alates. Järgmine näide eeldab klastrit ilma eraldi tablespace'ideta ning proovimasinat, kus sama klastri töötavat instantsi ei ole. Hoia algne baaskoopia muutmata.
- Märgi üles katse algusaeg. Loo tühi sihtkataloog ja kopeeri sinna baaskoopia näiteks käskudega mkdir -p /srv/restore-test ning cp -a /backup/base/. /srv/restore-test/. Tee seda PostgreSQLi süsteemikasutaja õigustes. Pärast veendumist, et kogu vajalik WAL on arhiivis, eemalda proovikoopia pg_wal-kataloogist varukoopiaga kaasa tulnud failid; ära muuda algset koopiat.
- Lisa proovikoopia konfiguratsiooni restore_command = 'cp /archive/%f %p' ja recovery_target_time = '2026-09-01 10:15:00+03'. Kuupäev on tinglik näide: asenda see tegeliku sihthetke ja üheselt määratud ajavööndiga. Lisa recovery_target_action = 'promote', kui soovid, et instants hakkaks sihthetke saavutamise järel ühendusi vastu võtma. Loo andmekataloogis fail recovery.signal käsuga touch /srv/restore-test/recovery.signal.
- Käivita instants eraldi pordil käsuga pg_ctl -D /srv/restore-test -o '-p 55432' -l /srv/restore-test.log start. Kontrolli logist, et taastamine jõudis sihthetkeni, seejärel vaata üle olulised tabelid ja rakenduse kriitilised päringud. Märgi üles aeg, mil taastatud teenus muutus kasutatavaks.
Kui sihthetk langeb baaskoopia tegemise ajale, vali varasem baaskoopia. Puuduvast WAL-segmendist ei saa taasesituses üle hüpata. Just seepärast annab korrapärane taastekatse rohkem teavet kui üksnes teade edukalt lõppenud varundustööst.
Pane mõõdetud taastamine kirja
Salvesta katse juurde baaskoopia tunnus, viimane kättesaadav WAL-segment, sihthetk koos ajavööndiga, kontrollsumma või manifestikontrolli tulemus ning taastamise algus- ja lõpuaeg. Võrdle aega, mis kulus teenuse kasutuskõlblikuks saamiseni, oma RTO-ga. RPO hindamisel lähtu viimastest arhiivis tegelikult olemas olnud muudatustest, mitte üksnes baaskoopia kuupäevast.
Kui katse ei täida eesmärki, näitab üleskirjutatud käik, kas piirang oli dump'i laadimise aeg, baaskoopia kopeerimine, WAL-i taasesitus või arhiivi mahajäämus. Selle järgi saad muuta varundamise sagedust, arhiveerimist või taastamiseks eraldatud ressursse ning korrata sama katset mõõdetava tulemusega.
Loe ka:
Seotud artiklid


Supabase või Firebase: andmemudel võib maksta rohkem kui kuutasu

Clastix kaasas 2,9 miljonit eurot: Euroopa AI-pilv algab Kubernetesest

Signal või WhatsApp: sõnum on krüpteeritud, metaandmete vahe jääb

Google Takeouti arhiiv aegub umbes nädalaga — ära jäta seda Drive’i

GitHubi 2FA võib konto lukku jätta — üks varumeetod pole piisav
Telli meie uudiskiri
Saa värskeimad Web3, AI ja krüptouudised otse oma postkasti.