# 1. BACKUP: Rulăm pg_dump în container și salvăm pe host
docker exec -t my_postgres_db pg_dumpall -U postgres | gzip > /backups/db_backup_$(date +%Y%m%d_%H%M%S).sql.gz
# 2. RESTORE TESTAT: Ridicăm un container temporar pentru test
docker run --name test_db_restore -e POSTGRES_PASSWORD=my_test_pass -d postgres:15
# 3. Importăm datele din backup-ul comprimat în noul container
gunzip -c /backups/db_backup_20231024_120000.sql.gz | docker exec -i test_db_restore psql -U postgres
# 4. Verificăm rapid dacă datele sunt acolo și curățăm containerul de test
docker exec -it test_db_restore psql -U postgres -c "SELECT count(*) FROM users;"
docker stop test_db_restore && docker rm test_db_restoreSalutare! Hai să vorbim direct despre o problemă de care m-am lovit de zeci de ori în ultimii ani: cum gestionăm corect datele în Docker și de ce simplul copy-paste pe folderele de pe host o să-ți explodeze în față când ți-e lumea mai dragă. Am văzut prea des proiecte unde baza de date rulează în container, iar backup-ul înseamnă doar un cron job care face tar pe un folder local.
Named Volumes vs Bind Mounts: Lupta de zi cu zi
Pe scurt, ai două opțiuni mari când vrei ca datele tale să supraviețuiască după un docker compose down.
Bind mounts (-v /path/pe/host:/var/lib/mysql) înseamnă că mapzi un folder specific de pe mașina ta direct în container. E excelent pentru dezvoltare locală, când vrei ca modificările din codul sursă să se vadă instant în container (hot reload).
Totuși, pentru baze de date în producție, bind mounts sunt o idee proastă. Pe macOS și Windows, performanța I/O scade dramatic (până la 40% build time mai lung sau interogări lente) din cauza layerului de virtualizare. În plus, te lovești constant de probleme de permisiuni (UID/GID nepotrivite între host și container).
Named volumes (-v db_data:/var/lib/mysql) sunt administrate direct de Docker, de obicei în /var/lib/docker/volumes/.
Trade-off-ul sincer: Named volumes rulează la viteză nativă și scapi de durerile de cap cu permisiunile de fișiere. Dezavantajul? Sunt izolate. Nu poți să intri ușor cu un file explorer pe host să vezi ce e acolo fără drepturi de root sau comenzi Docker specifice.
Greșeala de 18 GB: Backup-ul la cald direct din folder
La un proiect cu vreo 14k useri activi, un coleg a configurat un bind mount pentru Postgres și făcea zilnic backup dând tar pe folderul de pe host în timp ce baza de date rula. Când am avut un crash pe server și a trebuit să facem restore, ghici ce? Arhiva era coruptă. Postgres scria în fișiere exact în secunda în care rulează tar-ul. Am pierdut 6 ore încercând să recuperăm tabelele dintr-un backup parțial de 18GB.
Regula de aur: Nu faci niciodată backup direct la fișierele bazei de date în timp ce motorul DB rulează.
Trebuie să folosești utilitarul nativ al bazei de date (de exemplu, pg_dump sau mysqldump) rulat direct în interiorul containerului, redirecționând output-ul către host.
Cum facem un backup corect și un restore testat
Mai jos ai abordarea curată pentru o bază de date PostgreSQL care rulează într-un container numit my_postgres_db. Scriptul generează un dump SQL comprimat direct pe mașina gazdă, fără ca baza să fie oprită și fără riscul de corupere a fișierelor.
Dar cel mai important pas, pe care 90% din oameni îl uită, este testarea restore-ului. Un backup nu valorează nimic dacă nu ai testat că poți ridica o bază nouă din el în mai puțin de 5 minute.
Voi cum gestionați backup-urile pentru bazele din Docker? Vă bazați pe snapshot-uri la nivel de VPS sau aveți scripturi dedicate în cron?