Kaip atliekate PostgreSQL duomenų bazės atsarginę kopiją ir atkūrimą?

Question

Accepted Answer

PostgreSQL siūlo kelis **atsarginės kopijos** metodus — loginius atsarginius kopijas (`pg_dump`) ir fizines atsargines kopijas (bazinė kopija + WAL skirta **taškui per laiko atkūrimui**). Tvirta atsarginės kopijos ir atkūrimo strategija yra būtina duomenų praradimo prevencijai, ir labai svarbu — **atsarginės kopijos turi būti testuojamos**.

## Loginės atsarginės kopijos — pg_dump

```bash
# pg_dump — dumps a database as SQL (or a custom archive) — portable, flexible
pg_dump -U user -d mydb -F c -f backup.dump      # custom format (compressed, flexible restore)
pg_dump -U user -d mydb > backup.sql              # plain SQL
pg_dumpall > all.sql                              # ALL databases + roles

# restore
pg_restore -U user -d mydb backup.dump            # from custom format
psql -U user -d mydb -f backup.sql                # from plain SQL
```

`pg_dump` sukuria loginę atsarginę kopiją (SQL arba archyvą) iš duomenų bazės — perkeliamą (atkūriamą į skirtingas versijas/serverius), gerą mažesnėms duomenų bazėms, migracijoms ir selektyvioms atsarginėms kopijoms. Bet tai taškinis laiko momentas (nėra nuolatinio atkūrimo).

## Fizinės atsarginės kopijos + taško per laiko atkūrimas (PITR)

```text
For larger/critical databases: a BASE BACKUP (a copy of the data files) + continuous
archiving of the WAL (write-ahead log) → enables POINT-IN-TIME RECOVERY:
  ✓ Restore the base backup, then REPLAY WAL up to ANY point in time
  ✓ Recover to JUST BEFORE a disaster (e.g. an accidental DROP TABLE at 2:47pm)
→ Tools: pg_basebackup, WAL archiving, and tools like pgBackRest / Barman automate this.
```

**PITR** yra galinga: archyvuojant WAL nuolat, galite atkurti bet kurį momentą — ne tik paskutinę atsarginę kopiją — tai būtina minimaliam duomenų praradimui iš nelaimės sumažinti.

## Atsarginės kopijos strategijos esencija

```text
✓ Regular, AUTOMATED backups (scheduled, not manual/forgotten)
✓ Store backups OFF the database server (and offsite / cloud) — survive hardware failure
✓ Retention policy (keep daily/weekly/monthly as needed)
✓ Combine: periodic base backups + continuous WAL for PITR (critical data)
✓ Backups from a REPLICA to avoid loading the primary
```

## Pati svarbiausia taisyklė: TESTUOKITE savo atsargines kopijas

```text
⚠️ A backup you've never restored is NOT a reliable backup.
UNTESTED backups fail when you need them most (corrupt, incomplete, wrong process).
→ Regularly TEST restores to verify they actually work and you know the procedure.
```

## Kodėl tai svarbu

Atsarginė kopija ir atkūrimas yra **kritiniai** žinių klausimai PostgreSQL atsakingam valdymui — apsauga nuo duomenų praradimo (dėl aparatūros sutrikimo, duomenų sugadinimo, netyčinio ištrynimo, nelaimių) yra viena iš svarbiausių atsakomybių bet kuriai gamybinei duomenų bazei, todėl atsarginių kopijų strategijų supratimas yra būtinas aukšto lygio žinios.

Metodų supratimas yra būtinas: **`pg_dump`** (loginės atsarginės kopijos — perkeliami SQL/archyvo saugyklos, geros mažesnėms duomenų bazėms, migracijoms ir selektyvioms/tarpversinėms atsarginėms kopijoms, bet tik laiko momentų kopijos) ir **fizinės atsarginės kopijos su taško per laiko atkūrimu (PITR)** (bazinė kopija + nuolatinis WAL archyvavimas, leidžiantis atkurti bet kurį momentą — tai galingas būdas minimaliam duomenų praradimui, pavyzdžiui, atkūrimas iš prieš netyčinį `DROP TABLE`, būtinas kritiniams duomenims).

**Strategijos esencijos** žinojimas (reguliarūs automatiški atsarginės kopijos, jų saugojimas ne serveryje ir iš viso, išlaikymo strategijos, bazinių kopijų kombinavimas su WAL PITR svarbiems duomenims, replikų atsarginės kopijos) yra svarbi operacinė žinia.

Svarbiausiai, supratimas, kad **atsarginės kopijos turi būti testuojamos** — netestuota atsarginė kopija yra nepatikima ir dažnai žlunga būtent tada, kai jų reikia (sugadinimas, nepilni duomenys, nežinomas atkūrimo procesas) — yra vitali, dažnai nepaisoma principas: reguliarūs atkūrimo testai yra tai, kas daro atsarginės kopijos strategiją iš tikrųjų patikima.

Kadangi duomenų praradimas gali būti katastrofiškas (ir atkūrimas yra galimas tik su veikiančiomis atsarginėmis kopijomis), ir kadangi tinkama strategija (atitinkami atsarginės kopijos metodai, PITR minimaliai strategyjai, iš viso saugojimas, ir labai svarbu *testautos* atkūrimas) yra tai, kas apsaugo organizacijos duomenis, PostgreSQL atsarginės kopijos ir atkūrimo supratimas yra kritinės aukšto lygio žinios atsakingam duomenų bazės valdymui — didelės rizikos atsakomybė, kur skirtumas tarp testautos strategijos ir betestautos gali būti skirtumas tarp atkūrimo iš nelaimės ir amžino duomenų praradimo, todėl tai yra būtina, dažnai aktuali tema bet kam, valdžiusiam gamybines duomenų bazes.