#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="/var/backups/postgres"
BUCKET_NAME="s3://bucket-backup-db"
B2_ENDPOINT="https://s3.eu-central-003.backblazeb2.com"
DATE=$(date +"%Y-%m-%d_%H%M%S")
FILENAME="db_backup_${DATE}.dump"
mkdir -p "${BACKUP_DIR}"
# Dump binar comprimat (-Fc permite restore paralel)
PGPASSWORD="${DB_PASS}" pg_dump -U "${DB_USER}" -h localhost -d "${DB_NAME}" -Fc -f "${BACKUP_DIR}/${FILENAME}"
# Upload in Backblaze B2 prin interfata S3
aws s3 cp "${BACKUP_DIR}/${FILENAME}" "${BUCKET_NAME}/${FILENAME}" --endpoint-url "${B2_ENDPOINT}"
# Curatenie locala: pastram doar ultimele 2 zile
find "${BACKUP_DIR}" -name "db_backup_*.dump" -mtime +2 -delete
echo "Backup finalizat cu succes: ${FILENAME}"Un backup pe care nu l-ai restaurat măcar o dată într-un container curat nu e backup. E doar o speranță că lucrurile vor fi bine când pică serverul.
La un proiect cu vreo 8k useri activi și o bază de date de 42GB, varianta clasică cu snapshot-uri pe DigitalOcean devenea scumpă și legată de un singur vendor. Am vrut o soluție off-site, simplă, ieftină și independentă de infrastructura de compute. Am ales Backblaze B2 prin API-ul lor compatibil S3, iar lunar mă costă undeva pe la 0.35$ pentru vreo 60GB stocați (cu tot cu versiuni vechi).
De ce B2 și nu direct AWS S3?
AWS S3 are prețul de 0.023$/GB pe storage, plus costuri pe request-uri și egress nesimțit dacă vrei să scoți datele. La B2 dai 0.006$/GB/lună și ai primii 10GB/zi de download gratuiți. Pentru baze medii, diferența în bani e neglijabilă la scară mică, dar simplitatea B2 fără 500 de bife de IAM policies face toți banii.
Am configurat aws-cli pe mașină să bată în endpoint-ul de B2. Practic rulezi comenzi de AWS S3, dar storage-ul e la Backblaze.
Cum funcționează scriptul din cron
Facem dump comprimat pe disc local într-un folder temporar, îl urcăm pe B2 cu un timestamp în nume, apoi ștergem fișierele locale mai vechi de 2 zile și backup-urile din bucket mai vechi de 14 zile.
Nu fac pipe direct din pg_dump în aws s3 cp dintr-un motiv practic: dacă pg_dump eșuează la mijloc (de exemplu dă out of memory), pipe-ul poate trimite un exit code 0 către S3 și te trezești cu un fișier parțial în cloud care pare complet.
În cron (crontab -e), arată așa:
0 3 * * * /usr/local/bin/backup-db.sh >> /var/log/db-backup.log 2>&1
Rulează la ora 3 noaptea. Pentru baza de 42GB, un dump cu pg_dump -Fc (format custom, comprimat binar) scoate un fișier de vreo 8.5GB. Durează cam 4 minute de dump și încă 2 minute de upload pe o conexiune gigabit.
Partea critică: verificarea restore-ului
O dată pe lună, am un task în calendar. Trag cel mai recent backup pe laptopul de dev sau pe un VPS ieftin de test și rulez restore-ul:
# 1. Tragi fișierul din B2
aws s3 cp s3://bucket-backup-db/db_backup_2025-02-15.dump ./latest.dump \
--endpoint-url https://s3.eu-central-003.backblazeb2.com
# 2. Creezi un DB temporar
createdb -U postgres test_restore_db
# 3. Dai restore cu pg_restore
pg_restore -U postgres -d test_restore_db -v -j 4 ./latest.dump
Flag-ul -j 4 folosește 4 core-uri în paralel, ceea ce taie timpul de restaurare la mai puțin de jumătate. La final, verific dacă numărul de înregistrări din tabelele critice are sens:
SELECT count(*) FROM orders;
Unde crapă abordarea asta (trade-off-ul)
pg_dump e genial până pe la 100-150GB. Peste pragul ăsta, dump-ul începe să țină tranzacții deschise ore întregi, crește presiunea pe I/O și produce bloat în tabele dacă baza e scrisă intens în acel interval. De asemenea, RPO-ul (Recovery Point Objective) este de maxim 24 de ore — dacă baza crapă la 18:00, ai pierdut datele din toată ziua.
Dacă ai nevoie de RPO de secunde sau minute, renunți la pg_dump și treci la WAL archiving continuu cu pgBackRest sau WAL-G. Dar pentru 90% din proiecte, un script de bash de 20 de linii e de o mie de ori mai ușor de întreținut și depanat.
Voi cum vă validați backup-urile? Aveți vreun container de test automatizat sau mergeți pe încredere?