Pentru o bază de date de câțiva gigaocteți, un export logic zilnic cu pg_dump poate fi acceptabil. Dar pentru baze de date de sute de gigaocteți sau teraocteți în producție, pg_dump este complet inadecvat: durează ore întregi, crește presiunea pe memorie și, cel mai grav, nu permite recuperarea modificărilor apărute între backup-ul de noapte și momentul unui incident din cursul zilei.
Standardul modern de Disaster Recovery în PostgreSQL combină Backup-urile Fizice de Bază cu Arhivarea Continuă a Jurnalelor WAL (Write-Ahead Logs), permițând tehnica Point-in-Time Recovery (PITR).
# Nivelul de înregistrare WAL trebuie să fie 'replica'
wal_level = replica
# Activăm arhivarea continuă
archive_mode = on
# Comanda apelată de PostgreSQL la fiecare segment complet de WAL de 16 MB:
# Folosind utilitarul enterprise standard pgBackRest:
archive_command = 'pgbackrest --stanza=productie archive-push %p'
# Timpul maxim după care un segment parțial este arhivat forțat (ex: 5 minute):
archive_timeout = 300De ce pgBackRest este alegerea numărul 1 în producție?
| Capabilitate | pg_dump | pgBackRest |
|---|---|---|
| Tip Backup | Export logic SQL/Custom (lent la restaurare). | Backup fizic la nivel de bloc de pagini (copiere directă de fișiere). |
| Backup Incremental / Diferențial | Nu suportă (exportă mereu 100% din date). | Da (salvează doar blocurile fizice modificate de la ultimul backup). |
| Compresie și Paralelism | Mono-thread sau paralelism limitat. | Compresie multi-core extrem de rapidă (LZ4, ZSTD) pe fire paralele. |
| Stocare Directă în Cloud | Necesită salvare pe disc local și upload separat. | Scrie direct în bucket-uri S3 / MinIO / Google Cloud Storage. |
| Backup din Noduri Replica | Posibil, dar impactează replica. | Descarcă datele din Standby fără nicio încărcare pe nodul Primary! |
# Executarea unui backup complet (de regulă duminică noaptea):
pgbackrest --stanza=productie --type=full backup
# Executarea unui backup incremental rapid (în fiecare noapte):
pgbackrest --stanza=productie --type=incr backup
# Verificarea stării și a integrității backup-urilor:
pgbackrest --stanza=productie infoScenariu Real: Restaurare Point-in-Time Recovery (PITR)
Imaginați-vă următorul scenariu critic: la ora 15:28:10, o procedură automată de curățare eronată a rulat TRUNCATE TABLE comenzi;. Ultimul backup incremental a fost la ora 03:00 dimineața.
Pentru a readuce baza de date exact în starea de la ora 15:28:09 (cu o secundă înainte de dezastru):
# Pasul 1: Oprim serviciul PostgreSQL pe mașina afectată
sudo systemctl stop postgresql
# Pasul 2: Lansăm restaurarea pgBackRest cu ținta specifică de timp:
pgbackrest --stanza=productie \
--type=time \
--target="2026-10-24 15:28:09+02" \
--target-action=promote \
restore
# Ce se întâmplă în culise:
# 1. pgBackRest restaurează automat cel mai apropiat backup de bază.
# 2. Descarcă din arhivă și aplică secvențial jurnalele WAL segment cu segment.
# 3. Oprește rejucarea evenimentelor EXACT la 15:28:09!
# 4. Promovează baza de date ca instanță primară funcțională gata de trafic.
# Pasul 3: Pornim PostgreSQL:
sudo systemctl start postgresqlTestarea Periodică a Planului de Disaster Recovery
O regulă esențială în administrarea sistemelor afirmă: „Starea unui backup este nedeterminată până în momentul în care restaurarea a fost validată cu succes”. Configurați un mediu automat de staging care restaurează în fiecare weekend cel mai recent backup de producție și rulează un set de teste de integritate automată.
Întrebări & Exemple de Cod:
Ghid de Backup și Disaster Recovery: WAL Archiving, pgBackRest și Point-in-Time RecoveryAi o nelămurire despre utilizarea comenzii
Ghid de Backup și Disaster Recovery: WAL Archiving, pgBackRest și Point-in-Time Recoverysau ai descoperit un truc / fragment de cod util? Distribuie-l cu ceilalți programatori!Fii primul care pune o întrebare sau distribuie un fragment de cod / prompt!
Nu au fost adăugate încă întrebări sau exemple de cod pentru această pagină. Dacă ai întâlnit o problemă sau ai un snippet util, adaugă-l mai jos pentru a-i ajuta pe ceilalți.