#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="/opt/backups/postgres"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
DUMP_FILE="$BACKUP_DIR/db_$TIMESTAMP.sql.gz"
mkdir -p "$BACKUP_DIR"
# 1. Backup logic direct din containerul de producție
docker exec -t production_postgres_1 pg_dump -U postgres app_db | gzip > "$DUMP_FILE"
echo "Backup salvat în $DUMP_FILE"
# 2. Test automat de restore într-un container efemer
TEST_CONTAINER="pg_restore_test_$TIMESTAMP"
docker run --name "$TEST_CONTAINER" -e POSTGRES_PASSWORD=test -d postgres:16-alpine > /dev/null
sleep 4
gunzip -c "$DUMP_FILE" | docker exec -i "$TEST_CONTAINER" psql -U postgres -d postgres > /dev/null
# Validare query de integritate
RECORD_COUNT=$(docker exec -i "$TEST_CONTAINER" psql -U postgres -d postgres -t -c "SELECT 1;")
# Curățare container de test
docker rm -f "$TEST_CONTAINER" > /dev/null
if [[ "$RECORD_COUNT" =~ "1" ]]; then
echo "[OK] Restore validat cu succes."
else
echo "[ERROR] Restore-ul a eșuat!" >&2
exit 1
fiAm văzut zeci de setup-uri de Docker unde lumea trântește un simplu ./data:/var/lib/postgresql/data în docker-compose și consideră treaba rezolvată. Funcționează pe laptop în primele zece minute, dar în producție ajungi rapid la erori dubioase de permisiuni, performanță de I/O degradată sau fișiere blocate.
Bind mounts vs Named volumes: unde greșim
Bind mount-ul leagă un director exact de pe host în container. E excelent pentru development când vrei hot-reload la codul din ./src. În schimb, când vine vorba de motoare de baze de date (Postgres, MySQL, MongoDB), devine o capcană.
Problema principală e legată de UID/GID. Utilizatorul postgres din container (de regulă UID 999) nu are drepturi curate pe directorul creat de userul tău din host (1000:1000). La asta se adaugă overhead-ul de filesystem dacă ești pe macOS sau Windows, unde I/O-ul pe bind mounts e de 3-5 ori mai lent.
Named volumes sunt gestionate nativ de Docker engine în /var/lib/docker/volumes/.
- Avantaj: Performanță nativă completă, zero bătăi de cap cu permisiunile interne și izolare curată.
- Dezavantaj (trade-off sincer): E mai greu să „arunci o privire” directă pe fișiere din terminalul host-ului fără comenzi docker specifice.
Capcana backup-ului prin copiere brută
La un proiect cu vreo 45GB în Postgres și ~150 de tranzacții pe secundă, un coleg a încercat să facă backup copiind directorul volumului în timp ce containerul mergea. Rezultatul la restore? Tranzacții parțial scrise în WAL și un cluster complet corupt.
Regula e simplă: nu copiezi niciodată fișierele brute de date ale unei baze pornite, decât dacă oprești containerul complet sau folosești tool-uri native de snapshot cu lock.
Cea mai curată variantă pentru aplicații mici și medii rămâne streaming-ul de dump logic (pg_dump / mysqldump) direct printr-un container efemer, fără să instalezi utilitare de DB pe mașina gazdă.
Strategia de backup și restore testat
Un backup pe care nu l-ai restaurat măcar o dată nu este un backup; este doar o speranță.
Fluxul pe care îl folosesc în producție pe mașini standalone implică două etape:
- Rulăm
pg_dumpcomprimat viadocker execsau container auxiliar. - La fiecare backup nocturn, pornim automat un container temporar izolat, încărcăm dump-ul și rulăm un query de sănătate (
SELECT count(*) FROM users). Dacă testul crapă, primim alertă pe loc.
Voi cum gestionați backup-urile pentru baze containerizate pe VPS-uri: cron cu dump pe host sau container sidecar dedicat?