# Backup corect pentru Postgres fără să oprești containerul
docker exec container_db_nume pg_dump -U user_db nume_db | gzip > backup_$(date +%Y-%m-%d).sql.gz
# Restore testat într-un container nou
gunzip -c backup_data.sql.gz | docker exec -i container_nou_db psql -U user_db nume_dbAm tot văzut discuții pe forum despre unde e mai bine să pui fișierele unei baze de date când rulezi Docker. Unii jură pe bind mounts pentru că „le văd eu acolo pe disc”, alții merg pe named volumes și nu se mai uită în spate. După 10 ani de containere, m-am prins că alegerea asta îți poate face viața un rai sau un calvar când vine vorba de backup și restore.
Bind Mounts vs Named Volumes: Mitul controlului
Bind mounts (-v /path/pe/host:/var/lib/mysql) par varianta „sigură”. Ai fișierele acolo, le poți atinge, le poți copia cu cp. Dar am pățit la un proiect cu vreo 12 microservicii să avem probleme masive de permisiuni. Docker rulează adesea procesele ca root în container, dar pe host ai un user cu alt UID. Te trezești că baza de date nu mai poate scrie în propriul folder după un restart sau că nu poți șterge log-urile de pe host fără sudo.
Pe de altă parte, Named Volumes sunt gestionate de Docker în /var/lib/docker/volumes/. Marele avantaj? Performanța I/O, mai ales pe macOS sau Windows, unde bind mounts trec printr-un strat de abstractizare care mănâncă resurse cu lopata. La un test de stres pe un Postgres cu 8k useri concurenți, am economisit cam 25% din latența de scriere doar trecând de la bind mount la named volume.
Trade-off-ul e sincer: named volumes sunt mai rapide și scapă de grija permisiunilor, dar sunt „invizibile” la o simplă navigare prin folderele de pe server.
Strategia de backup: Nu face „copy-paste”
Cea mai mare greșeală pe care o văd e backup-ul prin copierea folderului de date în timp ce containerul rulează. E rețeta perfectă pentru corupere de date. Baza de date are fișiere deschise, scrie în buffer-e, iar tu dacă faci cp sau rsync, prinzi fișierele într-o stare inconsistentă.
Backup-ul corect se face prin utilitarele native (ca pg_dump sau mysqldump) rulate direct în container. Am implementat o schemă unde dump-ul se duce direct într-un folder montat separat pentru backup-uri, apoi e arhivat și trimis în S3. La un DB de 50GB, procesul ăsta durează, dar ai garanția că datele sunt valide.
Restore-ul testat (singurul care contează)
Un backup pe care nu l-ai testat niciodată nu există. E doar un fișier care îți ocupă spațiu degeaba. Am avut un caz la un client unde scriptul de backup rula „cu succes” de 6 luni, dar din cauza unei schimbări de schemă, dump-ul era de fapt gol. Am aflat asta fix când a crăpat discul principal.
Acum, regula mea e simplă: o dată pe lună, ridicăm un container temporar, facem restore la cel mai recent dump și rulăm un query de verificare (un simplu COUNT pe tabela de useri e suficient de multe ori). Dacă restore-ul durează mai mult de 30 de minute pentru o bază medie, înseamnă că strategia de indexare e praf și trebuie regândită.
În concluzie, folosește Named Volumes pentru performanță în producție și Bind Mounts doar în development pentru cod. Și te rog, nu te baza pe cp pentru baza de date dacă vrei să dormi liniștit noaptea.
Voi cum vă gestionați volumele în producție, mergeți pe drivere de cloud (ca AWS EBS) sau rămâneți pe local volumes?