PGSQL Toate comenzile și funcțiile PostgreSQL

`Ghid de Backup și Disaster Recovery: WAL Archiving, pgBackRest și Point-in-Time Recovery` în PostgreSQL

Audit și Diagnostic Producție PostgreSQL 12+

Strategii de protecție a datelor la scară enterprise în PostgreSQL: arhivarea jurnalelor WAL, backup fizic incremental cu pgBackRest și restaurarea exactă la secundă prin Point-in-Time Recovery (PITR).

Sintaxă SQL

archive_command = 'pgbackrest ...'; pgbackrest --stanza=prod --type=pitr restore

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

1. Configurarea Arhivării WAL în postgresql.conf

# 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 = 300

De 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!

Comenzi uzuale de Backup cu pgBackRest

# 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 info

Scenariu 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):

Pașii de Restaurare PITR la secundă

# 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 postgresql

Testarea 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ă.