#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="/backups/postgres"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
FILENAME="${BACKUP_DIR}/db_backup_${TIMESTAMP}.sql.gz"
# 1. Backup logic consistent fără downtime
docker exec -t db_production pg_dump -U postgres -d app_db --clean --if-exists \
| gzip > "${FILENAME}"
# 2. Test restore automat pe un container efemer
docker run --rm -d --name db_restore_test \
-e POSTGRES_PASSWORD=secret \
-e POSTGRES_DB=test_db \
postgres:16-alpine
sleep 5
zcat "${FILENAME}" | docker exec -i db_restore_test psql -U postgres -d test_db > /dev/null
# 3. Verificare integritate minimă
docker exec -t db_restore_test psql -U postgres -d test_db -c "SELECT COUNT(*) FROM users;"
docker stop db_restore_test
echo "Backup și restore testate cu succes: ${FILENAME}"Dacă ai trântit vreodată un Postgres în Docker cu ./data:/var/lib/postgresql/data doar ca să vezi fișierele pe disk, ai fost la un pas de dezastru. Am văzut configurarea asta în zeci de proiecte, iar la primul restart forțat sau update de OS gazdă începe distracția cu permisiunile și fișierele blocate.
Hai să tranșăm odată dilema asta și să vedem cum ținem datele în siguranță fără să ne mințim că avem backupuri funcționale.
Bind mounts vs Named volumes: unde greșim
Bind mount-ul (./data:/app/data) leagă direct un folder de pe host într-un container. E genial pentru development când vrei hot reload la cod sau citești un log rapid. Pentru baze de date, însă, e o bombă cu ceas.
Pe Linux te lovești instant de UID/GID mismatch: containerul rulează procesul Postgres cu utilizatorul intern postgres (adesea UID 999), iar pe host folderul e creat de utilizatorul tău (UID 1000) sau de root. Baza refuză să pornească pentru că Postgres cere permisiuni stricte 0700. Pe macOS și Windows e și mai rău: sincronizarea I/O prin HyperKit/WSL2 omoară performanța discului. La un test simplu de scriere pe un MySQL cu 200 de conexiuni concurente, am scos un timp de răspuns de 4 ori mai slab pe bind mount față de named volume.
Named volumes (db_data:/var/lib/postgresql/data) sunt gestionate exclusiv de engine-ul Docker. Performanța pe Linux este 100% nativă, iar Docker se ocupă singur de permisiunile fișierelor din /var/lib/docker/volumes/.
Trade-off-ul cinstit? Ești dependent de CLI-ul Docker ca să inspectezi fișierele. Nu poți da dublu click în File Explorer pe datele bazei, dar nici nu ai ce căuta manual în fișierele interne ale unui motor SQL.
Iluzia backupului: de ce pică fișierele copiate
Am pățit acum vreo patru ani o chestie dureroasă pe un nod Hetzner. Aveam un cron job care făcea tar -czf direct pe folderul de date al containerului în timp ce baza rula. Când SSD-ul s-a prăjit și am încercat să ridic containerul din arhiva respectivă, Postgres a refuzat să pornească: pagini corupte în fișierele de date și WAL desincronizat.
Nu poți copia fișiere raw de DB dacă procesul încă scrie în ele. Punct. Pentru backup consistent ai nevoie de utilitarele native (pg_dump, mariadb-dump), rulate direct prin docker exec sau printr-un container separat atașat pe aceeași rețea.
Regula de fier: Restore-ul netestat e doar o speranță
Un fișier .sql.gz de 4GB pe un storage S3 nu înseamnă că ai backup. Înseamnă doar că ai un fișier comprimat.
La un magazin online cu vreo 40k comenzi pe lună, am implementat un job automat în CI: o dată pe săptămână, scriptul trage ultimul dump din bucket, ridică un container Postgres temporar pe un named volume nou, injectează dump-ul și rulează un simplu SELECT count(*) FROM orders. Dacă query-ul crapă sau durează anormal de mult, primim alertă pe Slack.
Testarea asta automată ne-a salvat când o migrare incompletă lăsase un foreign key invalid, iar dump-ul logic se bloca la restore cu o eroare silențioasă de constrângere.