# 1. Backup corect prin container temporar (fără downtime)
docker run --rm \
--network my_app_network \
-e PGPASSWORD="secret_db_pass" \
postgres:16-alpine \
pg_dump -h db_container -U my_user -d production_db \
| gzip -9 > /opt/backups/backup_$(date +%Y%m%d_%H%M%S).sql.gz
# 2. Restore de test într-un container complet izolat
docker run -d --name db_restore_test \
-e POSTGRES_PASSWORD="test_pass" \
-e POSTGRES_DB="production_db" \
postgres:16-alpine
sleep 5
gunzip -c /opt/backups/backup_20240101_000000.sql.gz \
| docker exec -i db_restore_test psql -U postgres -d production_db
# 3. Curățenie după verificare
docker rm -f db_restore_testDacă pui baza de date într-un container fără să înțelegi exact ce se întâmplă cu discul, e doar o chestiune de timp până pierzi date. Am văzut zeci de setup-uri unde oamenii foloseau bind mounts pe host pentru un PostgreSQL în producție, apoi se mirau de ce crapă permisiunile sau de ce e I/O-ul la pământ.
Regula e simplă: bind mounts sunt pentru cod în development, named volumes sunt pentru date persistente în producție.
Bind mounts vs Named volumes: unde se rupe filmul
Bind mount leagă un path absolut de pe mașina gazdă direct în container (./data:/var/lib/postgresql/data). În dev e comod. Modifici un config sau vrei să vezi fișierele local, le ai imediat pe ecran. Dar pe producție aduce două mari probleme.
Prima e legată de permisiuni și UID-uri: utilizatorul postgres din container (de regulă UID 999) încearcă să scrie pe un folder deținut de root sau de userul tău de SSH. Rezultatul? Crash loop la restart cu eroare de permisiuni. A doua problemă e performanța. La un client cu vreo 8.000 de comenzi pe zi am măsurat o scădere de aproape 4x a operațiunilor de scriere pe secundă când baza rula pe bind mount din cauza layer-ului de sincronizare și a filesystem locking-ului de pe host.
Named volumes (db_data:/var/lib/postgresql/data) sunt gestionate exclusiv de Docker daemon în /var/lib/docker/volumes/. Nu te mai lovești de UID clashes, iar performanța pe Linux este 100% nativă. Trade-off-ul sincer? Nu poți da ușor ls din terminalul host-ului să vezi ce e acolo fără sudo sau fără un container de inspect. Dar e un preț mic pentru stabilitate.
Greșeala clasică: tar pe folderul de date viu
Mulți fac backup la volume rulând un container temporar care împachetează tot volumul cu tar czf. Dacă baza de date rulează și scrie activ în timp ce tu rulezi tar, ai șanse enorme să prinzi o stare inconsistentă (torn pages). Când vei da restore, Postgres va refuza să pornească sau vei avea date corupte în indecși.
Fișierele brute ale unei baze de date nu se copiază niciodată „la cald” fără oprirea containerului sau fără un mecanism nativ de backup (cum e pg_basebackup sau pg_dump).
Cum faci backup corect și verificat
Cel mai curat mod pe mașini standalone (fără storage snapshots la nivel de cloud) este un container efemer legat la aceeași rețea Docker, care rulează utilitarul bazei de date și scoate un dump compresat.
Și ține minte: un backup pe care nu l-ai restaurat vreodată nu este backup, este doar o iluzie. La fiecare pipeline de backup pe care îl scriu, adaug un pas lunar sau săptămânal de health-check: pornesc un Postgres temporar într-un container gol, încarc ultimul .sql.gz și dau un simplu SELECT count(*) FROM users. Dacă comanda crapă, știu imediat, nu la 3 noaptea când moare serverul principal.