Backup automat de PostgreSQL în Backblaze B2: Scriptul meu de producție și testul de restore

Marian Apostol · 2026-07-18T02:00:26.829Z

Nu mai arunca banii pe soluții scumpe de backup. Îți arăt cum am configurat un sistem de backup automatizat cu pg_dump și Backblaze B2 pentru câțiva cenți pe lună.

Postat 18 iul. 2026

bash

#!/bin/bash

# Configurare variabile
DB_NAME="numele_bazei_de_date"
DB_USER="postgres"
BACKUP_DIR="/var/backups/postgres"
B2_BUCKET="s3://numele-bucketului-tau/db-backups/"
B2_ENDPOINT="https://s3.us-west-004.backblaze.com" # Schimbă cu endpoint-ul tău
DATE=$(date +"%Y_%m_%d_%H%M%S")
FILENAME="$BACKUP_DIR/$DB_NAME-$DATE.sql.gz"

# Ne asigurăm că directorul de backup există local
mkdir -p "$BACKUP_DIR"

# Generăm backup-ul direct comprimat (folosim formatul custom -Fc)
echo "[$(date)] Începe backup-ul pentru $DB_NAME..."
pg_dump -h localhost -U "$DB_USER" -Fc "$DB_NAME" | gzip > "$FILENAME"

if [ $? -eq 0 ]; then
  echo "[$(date)] Backup-ul local a fost creat cu succes: $FILENAME"
  
  # Upload în Backblaze B2 folosind aws-cli
  aws s3 cp "$FILENAME" "$B2_BUCKET" --endpoint-url "$B2_ENDPOINT"
  
  if [ $? -eq 0 ]; then
    echo "[$(date)] Upload-ul în Backblaze B2 a fost finalizat."
    # Ștergem backup-urile locale mai vechi de 7 zile ca să nu ocupăm spațiu degeaba
    find "$BACKUP_DIR" -type f -mtime +7 -name "*.gz" -exec rm {} \;
  else
    echo "[$(date)] EROARE: Upload-ul în B2 a eșuat!" >&2
  fi
else
  echo "[$(date)] EROARE: pg_dump a eșuat!" >&2
fi

Am văzut prea multe startup-uri care dau zeci de dolari pe lună pe SaaS-uri de backup, când pot rezolva totul singuri în 15 minute. Am aplicat rețeta asta pe un proiect cu peste 12.000 de utilizatori activi și baza de date de vreo 18 GB. Costul total pe Backblaze B2? Sub 20 de cenți pe lună.

Nu ai nevoie de scripturi complexe de mii de linii sau utilitare obscure. Un simplu bash script rulat de un cron-job pe server este suficient, atâta timp cât respecți o regulă de aur: testează restore-ul periodic.

De ce Backblaze B2 și nu AWS S3?

Sincer, pentru că e incredibil de ieftin și nu te taxează ascuns. AWS S3 are un pricing destul de complicat când începi să adaugi cereri de tip PUT/GET și reguli de lifecycle. Backblaze oferă stocare compatibilă cu S3 API la o treime din preț.

Trade-off-ul sincer: Viteza de upload din Europa către serverele lor din US poate fi uneori mai mică decât pe AWS localizat în Frankfurt. Totuși, pentru un backup care rulează noaptea la ora 03:00, chiar nu mă interesează dacă upload-ul durează 1 minut în loc de 15 secunde.

Configurația inițială

Înainte de a rula scriptul, ai nevoie de utilitarul aws-cli instalat și configurat pe serverul tău. Backblaze B2 oferă chei de acces compatibile cu S3, așa că le poți folosi direct.

Rulează aws configure și introdu cheia de acces (Key ID) și cheia secretă (Application Key) generate din dashboard-ul Backblaze. La regiune poți pune orice (de exemplu us-west-004, în funcție de ce scrie în contul tău la Endpoint).

Scriptul de backup în producție

Am pus în secțiunea de cod de mai jos scriptul pe care îl folosesc. Acesta creează un backup comprimat, îl ureează în B2 și apoi șterge fișierele locale mai vechi de 7 zile ca să nu umplem discul serverului.

Nu uita să îi dai drepturi de execuție cu chmod +x backup.sh înainte de a-l testa.

Cum testezi restore-ul (Fără asta, degeaba ai backup)

Un backup netestat este doar o iluzie de siguranță. Am pățit o singură dată să am nevoie de un restore rapid și să realizez că arhiva era incompletă din cauza unei erori de permisiuni pe care o ignorasem în log-uri.

Pentru a testa restore-ul pe o bază de date locală sau de staging:

Descarcă backup-ul din Backblaze: aws s3 cp s3://nume-bucket/db-backups/backup_2023_10_25.sql.gz . --endpoint-url https://s3.us-west-004.backblaze.com
Dezarhivează fișierul: gunzip backup_2023_10_25.sql.gz
Rulază restore-ul într-o bază de date de test goală: pg_restore -h localhost -U postgres -d test_db -v backup_2023_10_25.sql

Deoarece am folosit formatul custom (-Fc) în pg_dump, restaurarea este mult mai rapidă și îți permite să folosești flag-ul -j pentru paralelizare dacă baza de date este foarte mare.

Automatizarea cu Cron

Adaugă scriptul în crontab-ul userului tău (crontab -e). Îți recomand să redirecționezi și log-urile ca să poți depana în caz de probleme:

0 3 * * * /home/deploy/scripts/backup.sh >> /var/log/backup.log 2>&1

Această linie va rula scriptul în fiecare noapte la ora 3:00 și va scrie orice eroare în fișierul de log configurat.

Voi cum vă gestionați backup-urile la proiectele mici și medii? Vă bazați pe snapshot-urile automate de la provider sau preferați să aveți control total asupra fișierelor?