# 1. Backup corect din container direct pe host
docker exec -t my-postgres-db pg_dumpall -U postgres | gzip > /backups/db_$(date +%F).sql.gz
# 2. Verifică dacă backup-ul chiar s-a creat și nu e gol
if [ -s /backups/db_$(date +%F).sql.gz ]; then
echo "[OK] Backup salvat cu succes."
else
echo "[ERROR] Backup-ul este gol sau nu a putut fi creat!"
exit 1
fi
# 3. Test de restore automat într-un container temporar
docker run --name temp-db-test -d -e POSTGRES_PASSWORD=test postgres:15
sleep 5
gunzip -c /backups/db_$(date +%F).sql.gz | docker exec -i temp-db-test psql -U postgres
if [ $? -eq 0 ]; then
echo "[OK] Testul de restore a trecut cu succes!"
else
echo "[FAIL] Restore-ul a eșuat pe containerul de test!"
fi
docker stop temp-db-test && docker rm temp-db-testSăptămâna trecută am salvat un client de la un mini-infarct. Omul rula un Postgres în Docker pe un VPS ieftin și făcea "backup" dând rsync la un folder din host mapat ca bind mount, în timp ce baza de date era activă. Când s-a bușit VPS-ul, surpriză: fișierele copiate erau corupte și complet inutilizabile.
Hai să lămurim odată pentru totdeauna cum stă treaba cu volumele în Docker și cum se face un backup pe bune, fără să te bazezi doar pe noroc.
Named Volumes vs. Bind Mounts: Unde punem datele?
Dacă ești la început, pare logic să folosești bind mounts (-v /opt/data:/var/lib/postgresql/data). Vezi fișierele direct pe host, le poți atinge, te simți în control. Dar asta este o capcană uriașă pe producție.
Bind mount-urile sunt excelente pentru development. Vrei ca modificările din codul tău local de Node.js sau Python să se vadă instant în container fără să reconstruiești imaginea? Bind mount e perfect acolo. Însă pentru baze de date, performanța I/O scade dramatic, mai ales dacă rulezi pe macOS sau Windows unde există o mașină virtuală la mijloc pentru Docker. În plus, te lovești constant de probleme de permisiuni, pentru că utilizatorul din container (de exemplu, postgres cu UID 999) s-ar putea să nu aibă drept de scriere pe folderul din host.
Pentru baze de date folosește mereu named volumes (-v pg_data:/var/lib/postgresql/data). Docker gestionează totul în /var/lib/docker/volumes/. Performanța este nativă, sistemul de operare nu se chinuie cu traducerea permisiunilor de pe host, iar datele sunt izolate corect. Trade-off-ul? Nu poți să intri ușor cu un FileZilla sau din terminalul tău să editezi fișierele direct. Dar adevărul e că nici n-ar trebui să faci asta direct în fișierele interne ale unei baze de date.
Cum faci backup corect la o bază de date în Docker
Regula de aur: niciodată nu copia fișierele brute (folderul data) în timp ce motorul bazei de date rulează. Riști să prinzi o scriere la jumătate în fișierele WAL (Write-Ahead Logging) și ai terminat jocul.
Backup-ul corect se face prin utilitarul nativ al bazei de date (cum e pg_dump pentru Postgres sau mysqldump pentru MySQL), executat în interiorul containerului, dar cu output-ul redirecționat către host. La un proiect cu peste 12k utilizatori activi, folosesc un cron job simplu care rulează o singură linie de comandă. Docker se ocupă de rutare, iar fișierul .sql.gz ajunge direct pe host-ul securizat.
Testează restore-ul, altfel n-ai backup
Am văzut zeci de developeri liniștiți că au "script de backup". Câți dintre voi ați testat restore-ul în ultima lună?
Acum câțiva ani, am avut nevoie de un restore pe un mediu de staging. Scriptul de backup rulase impecabil timp de 6 luni, genera fișiere zilnic. Când am dat import, am realizat că toate fișierele aveau 0 KB. O schimbare de permisiuni făcuse ca pg_dump să dea eroare în container, dar cron-ul ignora asta și doar dădea touch la fișier. De atunci, regula mea e simplă: scriptul de backup trebuie să aibă o validare de dimensiune și, cel mai important, un test de restore automatizat într-un container temporar.
Tu cum îți testezi backup-urile? Le lași pe mâna sorții sau ai un container de staging care trage dump-ul automat în fiecare săptămână ca să fii sigur că fișierele sunt valide?