#!/usr/bin/env bash
set -eo pipefail
# 1. Facem backup din containerul de prod/staging
docker exec -t postgres-prod pg_dump -U postgres -F c my_database > /backups/db_$(date +%Y%m%d).dump
# 2. Testam restore-ul intr-un container izolat de test
docker run --name pg-restore-test -e POSTGRES_PASSWORD=test_pass -d postgres:15-alpine
sleep 5 # asteptam initializarea
# 3. Creem baza si restauram dump-ul
docker exec -i pg-restore-test createdb -U postgres test_db
docker exec -i pg-restore-test pg_restore -U postgres -d test_db < /backups/db_$(date +%Y%m%d).dump
# 4. Sanity check simplu
ROWS_COUNT=$(docker exec -i pg-restore-test psql -U postgres -d test_db -t -c "SELECT COUNT(*) FROM users;")
echo "Restore reusit. Numar useri verificati: ${ROWS_COUNT}"
# 5. Curatăm containerul temporar
docker rm -f pg-restore-testAm văzut prea mulți devs care pun baze de date pe bind mounts în producție și se miră de ce crapă I/O-ul sau de ce pierd date la deploy. În postarea asta lămurim clar diferența dintre named volumes și bind mounts și cum faci un backup cu restore testat, fără iluzia că dacă ai un fișier sql pe disc ești salvat.
Named Volumes vs Bind Mounts: unde greșește lumea
Când pui un container de PostgreSQL pe un bind mount precum -v ./data:/var/lib/postgresql/data, adică legat direct de un folder din host-ul tău, îți faci viața grea fără să știi. Pe macOS și Windows, Docker rulează într-o mașină virtuală. Trecerea tuturor operațiunilor I/O ale bazei de date prin sistemul de fișiere partajat (VirtioFS sau gRPC FUSE) omoară performanța. Am pățit asta la un proiect cu vreo 800 req/sec: CPU-ul din VM era la 100% doar din cauza syscall-urilor de I/O pe un bind mount.
Pe Linux nativ, bind mount-ul e mai rapid, dar te lovești rapid de permisiuni POSIX. Containerul de Postgres rulează cu userul internal postgres (UID 999), în timp ce folderul tău din host are UID-ul userului tău (de exemplu 1000). Rezultatul? Permission denied la pornire sau ești nevoit să dai un chmod -R 777 pe host, ceea ce e o mizerie uriașă în producție.
Named volumes (-v pgdata:/var/lib/postgresql/data) sunt gestionate exclusiv de Docker daemon direct în /var/lib/docker/volumes/. Câștigi performanță nativă I/O pe orice OS și scapi de durerile de cap cu permisiunile. Trade-off-ul sincer? Fișierele nu mai sunt ușor accesibile din file manager-ul tău local, deci trebuie să folosești comenzi de Docker ca să le manipulezi.
Backup la baze de date: fără copy-paste pe directoare
Altă greșeală clasică: oprirea containerului și copierea folderului cu date, sau mai rău, copierea folderului în timp ce baza rulează. Dacă copiezi fișierele brute live, WAL-ul (Write-Ahead Logging) va fi într-o stare inconsistentă. Când încerci să pornești un container nou cu datele alea copiate, Postgres îți va da crash cu eroare de integritate.
Backup-ul corect se face la nivel logic, folosind utilitarele dedicate ale bazei. La un proiect recent unde aveam o bază de 12GB și în jur de 5k tranzacții pe minut, facem backup-ul printr-un container ephemer de backup care rulează pg_dump și scoate o arhivă comprimată. Nu oprim baza și nu blocăm scrierile.
Testarea restore-ului: singurul backup real
Un backup netestat este doar o dorință. Dacă nu ai un script automatizat care ia arhiva generată și o restaurează într-un container curat pentru verificare, nu ai un backup funcțional.
Noi rulăm săptămânal un job izolat care ridică o instanță temporară de Postgres într-un container nou, încarcă ultimul dump generat și execută un query rapid de sanity check (numărăm rândurile din tabelele critice). Dacă containerul temporar crapă la restore, primim alertă imediat pe Slack.
Concluzie
Folosiți named volumes pentru tot ce înseamnă persistență de date în containere și lăsați bind mounts doar pentru source code în medii de dev local. Iar pentru backup, scrieți de azi un script simplu care face restore automat într-un container temporar.
Voi cum gestionați backup-urile de Docker în staging sau producție? Le trimiteți direct în S3 sau folosiți utilitare dedicate gen pgBackRest?