#!/usr/bin/env bash
set -eo pipefail
CONTAINER_NAME="production_db"
DB_USER="app_user"
DB_NAME="app_production"
BACKUP_DIR="/backups/postgres"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/db_backup_${DATE}.sql.gz"
mkdir -p "$BACKUP_DIR"
# 1. Backup direct prin stream comprimat (fara fisier intermediar necomprimat)
echo "[1/3] Generez backup..."
docker exec -t "$CONTAINER_NAME" pg_dump -U "$DB_USER" "$DB_NAME" | gzip > "$BACKUP_FILE"
# 2. Test Restore pe container ephemere
echo "[2/3] Testez restaurarea intr-un container izolat..."
TEST_CONTAINER="postgres_test_restore_${DATE}"
docker run --name "$TEST_CONTAINER" -e POSTGRES_PASSWORD=test_pass -d postgres:15-alpine > /dev/null
sleep 4 # asteptam initializarea postgres
zcat "$BACKUP_FILE" | docker exec -i "$TEST_CONTAINER" psql -U postgres -d postgres > /dev/null
# 3. Cleanup container temporar
echo "[3/3] Curtare container de test..."
docker rm -f "$TEST_CONTAINER" > /dev/null
echo "SUCCESS: Backup si restore testate cu succes: $BACKUP_FILE"M-am lovit prima dată urât de problema asta prin 2019, la un proiect cu 15k querii pe secundă. Am lăsat un Postgres pe un bind mount direct într-un folder din /var/app/db și ne-am mirat de ce aveam spike-uri masive de I/O și permisiuni stricate după fiecare update al sistemului de operare.
De atunci am învățat pe pielea mea: modul în care mapezi stocarea în Docker nu e doar o chestie de convenție, ci îți poate dărâma baza de date la primul restart neprogramat sau la prima migrare mai grea.
Named Volumes vs Bind Mounts: Ce folosești și când
Regula mea e destul de simplă după atâția ani. În dezvoltare locală, unde vrei hot reload pentru codul de Node, Python sau Go, folosești bind mounts (-v /path/local:/app). Vrei ca orice modificare salvată în IDE-ul tău să fie reflectată instant în container.
Dar pentru baze de date (Postgres, MySQL, Redis) sau pentru mediul de producție, folosești exclusiv named volumes (-v db_data:/var/lib/postgresql/data).
De ce? Bind mounts depind direct de structura de directoare a gazdei și de UID/GID-ul utilizatorilor din host. Dacă echipa lucrează pe Linux și macOS, un bind mount pe un folder de date Postgres o să meargă groaznic pe Mac din cauza stratului de virtualizare din Docker Desktop. Am măsurat personal o scădere de 4 ori a vitezei de scriere la teste de integrări când rulam DB-ul pe bind mount vs named volume pe macOS.
Trade-off-ul cu named volumes? Le gestionează Docker direct în /var/lib/docker/volumes/, deci e puțin mai incomod să le explorezi la pas cu file managerul. Dar câștigi performanță de I/O nativă și scapi complet de măgăriile cu chown -R 999:999 pe servere.
De ce pică baza de date când faci backup pe viu
Văd încă destui colegi care fac backup copiind direct folderul de date din host sau dând docker cp pe folderul de date din container. Vă rog eu, nu mai faceți asta. Dacă engine-ul bazei de date scrie un bloc pe disc fix când faci tu copia, backup-ul tău e compromis definitiv. Nu vei afla asta decât într-o noapte de vineri când încerci să faci restore de urgență.
Pentru o bază de date containerizată, backup-ul corect se face extras direct din procesul bazei de date folosind utilitare dedicate (pg_dump, mysqldump), trimis prin pipe comprimat în afara containerului.
Testează restore-ul automat, altfel nu ai backup
Un backup pe care nu l-ai restaurat niciodată într-un mediu izolat e doar un exercițiu de optimism. Am pierdut odată 40GB de date dintr-un dump corupt la jumătate de un caracter special nescapat corect în scriptul de cron.
În prezent, scriptul nostru de backup nu doar că generează fișierul .sql.gz, dar ridică imediat un container temporar de test, aplică dump-ul pe el și verifică dacă baza se ridică fără erori. Dacă testul de restore pică, scriptul returnează exit code non-zero și aruncă alertă pe Slack.
Voi cum gestionați backup-ul volumelor de DB pe serverele proprii? Folosiți scripturi bash cu cron sau ați trecut la soluții mai avansate gen Restic, Borg sau WAL-G?