# 1. Backup corect folosind pg_dump din interiorul containerului
docker exec -t postgres-db pg_dump -U myuser -F c mydb > /backups/db_backup_$(date +%F).dump
# 2. Testarea automata a restore-ului intr-un container efemer
echo "Validare backup..."
docker run --name pg-test -d -e POSTGRES_PASSWORD=test -e POSTGRES_USER=myuser -e POSTGRES_DB=mydb_test postgres:15-alpine
# Asteptam ca DB-ul de test sa porneasca
sleep 5
# Restauram dump-ul in containerul temporar
docker exec -i pg-test pg_restore -U myuser -d mydb_test < /backups/db_backup_$(date +%F).dump
if [ $? -eq 0 ]; then
echo "Backup VALIDAT cu succes!"
else
echo "Eroare critica: Restore-ul a esuat!"
fi
# Curatam containerul de test
docker rm -f pg-testSalutare! Am văzut destui colegi care își pierd datele din baze de date pentru că folosesc greșit volumele în Docker sau se bazează pe backup-uri copiate „la cald” direct din folderul de date.
Hai să lămurim rapid diferența asta și cum facem un backup pe care chiar te poți baza când crapă serverul.
Named Volumes vs Bind Mounts: Unde punem baza de date?
Dacă folosești -v /home/user/data:/var/lib/postgresql/data (bind mount), te joci cu focul în producție. Bind mount-urile sunt excelente în development când vrei să dai share la codul sursă între host și container, dar sunt groaznice pentru baze de date. De ce? Pentru că depinzi direct de structura de directoare a hostului și, mai ales, de permisiunile de user (UID/GID). Pe macOS sau Windows, performanța scade dramatic din cauza stratului de virtualizare pentru file system.
Pentru baze de date, regula de aur e simplă: folosește named volumes (-v db_data:/var/lib/postgresql/data).
Docker gestionează singur directorul în /var/lib/docker/volumes/ pe Linux, asigură permisiunile corecte automat și ai performanță nativă I/O. Singurul dezavantaj? Nu poți da ușor dublu-clic pe fișiere din host. Dar, sincer, nici nu ar trebui să faci asta la o bază de date activă.
Mitul copierii folderului de date (De ce crapă backup-ul „la cald”)
Am întâlnit oameni care fac backup la baza de date din Docker prin copierea folderului din named volume sau din bind mount în timp ce containerul rulează. Este o rețetă sigură pentru dezastru.
Dacă baza de date scrie ceva în fișiere în milisecunda în care rulezi tu cp sau rsync, backup-ul tău va fi corupt. La un proiect cu vreo 14.000 de useri activi, am pățit exact asta: am încercat să facem restore dintr-un astfel de backup și am realizat că indexurile erau bușite complet. Am pierdut 6 ore cu REINDEX și recuperat tabele manual.
Metoda corectă este să folosești utilitarul nativ al bazei de date (pg_dump pentru Postgres, mysqldump pentru MySQL) direct prin container.
Strategia de backup și testarea restore-ului
Un backup netestat nu este un backup, este doar o speranță. Cel mai bun mod de a face asta este să automatizezi un script care rulează pg_dump, iar apoi pornește temporar un container separat ca să testeze dacă acel dump chiar se poate importa fără erori.
În codul atașat aveți varianta curată pe care o folosesc eu în scripturile de cron. Folosim docker exec pentru backup și apoi un container efemer pentru validare.
Trade-off: Securitate vs Simplitate
Abordarea asta cu docker exec e simplă și nu necesită tool-uri terțe, dar are un dezavantaj: dacă baza de date are sute de gigabiți, pg_dump va consuma resurse de CPU și I/O direct pe serverul de producție, încetinind aplicația în timpul rulării. Pentru baze de date masive, va trebui să treci la replici de tip Read-Only sau la tool-uri enterprise care știu să facă backup fizic incremental la cald, cum e pgBackRest.
Voi cum gestionați backup-urile pentru bazele de date în containere? Mergeți pe scripturi simple în cron sau folosiți containere dedicate de backup care trimit direct în S3?