#!/usr/bin/env bash
set -e
# 1. Facem backup-ul propriu-zis din containerul de productie
docker exec pg_prod pg_dump -U postgres my_db > /tmp/backup.sql
# 2. Testam restore-ul intr-un container temporar, izolat
docker run --name pg_test -d -e POSTGRES_PASSWORD=test postgres:15-alpine
# Asteptam ca baza de date de test sa fie gata
sleep 3
# Cream baza de date si restauram datele din backup
docker exec -i pg_test psql -U postgres -c "CREATE DATABASE my_db;"
docker exec -i pg_test psql -U postgres -d my_db < /tmp/backup.sql
# Validam structura ruland un query simplu
USER_COUNT=$(docker exec -i pg_test psql -U postgres -d my_db -t -c "SELECT count(*) FROM users;")
echo "[OK] Restore testat cu succes. Useri gasiti: ${USER_COUNT}"
# Curatam containerul de test
docker rm -f pg_testNe lovim cu toții de stocarea datelor în Docker și, din păcate, mulți învață diferența dintre tipurile de volume pe calea cea grea. Am văzut destule baze de date pierdute în producție pentru că cineva a confundat un bind mount cu un named volume sau a crezut că e suficient să facă un tar pe folderul de date. Astăzi facem ordine în ele și vedem cum configurăm un backup/restore pe care chiar să ne putem baza când pică serverul.
Named Volumes vs Bind Mounts: Diferența reală
La prima vedere, ambele fac același lucru: persistă datele în afara ciclului de viață al containerului. Dar sub capotă, comportamentul lor e complet diferit, iar alegerea greșită te costă performanță sau chiar date pierdute.
Bind mounts (-v /opt/app/data:/var/lib/mysql) mapează un folder exact de pe mașina gazdă în container. Sunt excelente pentru fișiere de configurare sau pentru codul sursă în timpul dezvoltării, ca să ai hot reload instant. Dar au un mare minus în producție: depinzi direct de structura de directoare și de permisiunile de pe host.
Am avut un caz la un proiect cu vreo 12k useri activi unde un Postgres pe bind mount a crăpat la un update de OS pe host, fiindcă s-au resetat permisiunile pe folderul gazdă (UID-ul userului din container nu mai avea drept de scriere). În plus, pe macOS sau Windows, bind mount-urile au un overhead de I/O masiv din cauza virtualizării sistemului de fișiere.
Named volumes (-v db_data:/var/lib/mysql) sunt gestionate complet de Docker în /var/lib/docker/volumes/. Docker se ocupă de permisiuni, de inițializarea volumului cu datele existente în imagine și de performanță.
Trade-off-ul: Nu poți accesa ușor fișierele direct de pe host cu un simplu ls sau nano. Dar pentru baze de date în producție, named volumes sunt singura opțiune sănătoasă.
Cum facem backup corect (Fără "dirty copies")
Cea mai mare greșeală pe care o văd este oprirea containerului și copierea folderului de date direct din volume, sau mai rău, copierea lui în timp ce baza de date rulează. Dacă faci asta în timp ce se scrie în DB, te alegi cu un backup corupt pe care nu-l mai pornești în veci.
Pentru un Postgres sau MySQL, backup-ul corect se face la nivel logic, folosind utilitarele lor native, chiar dacă rulează în Docker. Nu trebuie să instalezi nimic pe host. Rulăm utilitarul direct în container și redirecționăm output-ul pe host.
Regula de aur: Restore testat într-un container temporar
Un backup pe care nu l-ai restaurat niciodată nu există. Este doar un fișier care ocupă spațiu degeaba. Protocolul meu în producție e simplu: imediat după ce scriptul de backup termină de rulat, pornesc un container temporar de Postgres, încarc backup-ul proaspăt făcut și rulez o interogare simplă ca să verific dacă datele sunt acolo și structura e validă. Dacă testul trece, abia atunci trimit backup-ul în S3.
Voi cum faceți backup-ul la bazele de date din Docker? Vă bazați pe snapshot-uri de VPS sau aveți scripturi de dump testate automat în CI/CD?