Cum faci backup și recuperare în PostgreSQL?

Question

Accepted Answer

PostgreSQL oferă mai multe metode de **backup** — backup-uri logice (`pg_dump`) și backup-uri fizice (base backup + WAL pentru **recuperare la un moment din timp**). O strategie solidă de backup și recuperare este esențială pentru protejarea împotriva pierderii de date, și în mod crucial, **backup-urile trebuie testate**.

## Backup-uri logice — 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` creează un backup logic (SQL sau arhivă) al unei baze de date — portabil (restorable pe versiuni/servere diferite), bun pentru baze de date mai mici, migrații și backup-uri selective. Dar este o snapshot la un moment din timp (fără recuperare continuă).

## Backup-uri fizice + Recuperare la un moment din timp (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** este puternic: prin arhivarea continuă a WAL, poți recupera la orice moment — nu doar la ultimul backup — ceea ce este esențial pentru minimizarea pierderii de date din dezastre.

## Elemente esențiale ale strategiei de backup

```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
```

## Cea mai importantă regulă: TESTEAZĂ-ți backup-urile

```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.
```

## De ce este important

Backup și recuperarea este cunoștință **critică** pentru operarea responsabilă a PostgreSQL — protejarea împotriva pierderii de date (din eșec hardware, corupere, ștergere accidentală, dezastre) este una dintre cele mai importante responsabilități pentru orice bază de date de producție, deci înțelegerea strategiilor de backup este cunoștință esențială la nivel senior.

Înțelegerea metodelor este necesară: **`pg_dump`** (backup-uri logice — dump-uri SQL/arhivă portabile, bune pentru baze de date mai mici, migrații și backup-uri selective/cross-version, dar doar snapshot-uri la un moment din timp) și **backup-uri fizice cu Recuperare la un moment din timp (PITR)** (base backup + arhivare continuă WAL, permițând recuperare la *orice* moment — ceea ce este puternic pentru minimizarea pierderii de date, cum ar fi recuperarea chiar înainte de o `DROP TABLE` accidentală, esențial pentru date critice).

Cunoașterea **elementelor esențiale ale strategiei** (backup-uri automate regulate, stocarea lor în afara serverului și în afara locației, politici de retenție, combinarea base backup-urilor cu WAL pentru PITR pe date critice, backup-uri din replici) este cunoștință operațională importantă.

Cel mai critic, înțelegerea că **backup-urile trebuie testate** — un backup netestrat este nesigur și adesea eșuează exact când are nevoie (corupere, date incomplete, proces de restaurare necunoscut) — este un principiu vital, adesea neglijat: testarea regulată a restaurărilor este ceea ce face o strategie de backup de fapt de încredere.

Deoarece pierderea de date poate fi catastrofală (și recuperarea este posibilă doar cu backup-uri funcționale), și deoarece o strategie adecvată (metode de backup potrivite, PITR pentru pierdere minimă, stocare în afara locației și în mod crucial *restaurări testate*) este ceea ce protejează datele unei organizații, înțelegerea backup și recuperării PostgreSQL este cunoștință critică la nivel senior pentru operații responsabile ale bazei de date — o responsabilitate cu mize mari unde diferența dintre o strategie testată și una netestată poate fi diferența dintre recuperarea dintr-un dezastru și pierderea permanentă a datelor, făcând-o un subiect esențial și frecvent relevant pentru oricine operează baze de date de producție.