#!/usr/bin/env bash
set -euo pipefail
# Configuratii
DB_NAME="myapp_prod"
DB_USER="postgres"
BACKUP_DIR="/tmp/db_backups"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
FILENAME="db_${DB_NAME}_${TIMESTAMP}.sql.gz"
B2_BUCKET="s3://nume-bucket-demo"
B2_ENDPOINT="https://s3.us-west-002.backblazeb2.com"
mkdir -p "$BACKUP_DIR"
# Dump + Gzip direct in pipeline ca sa economisim spatiu pe disc
pg_dump -U "$DB_USER" -h localhost "$DB_NAME" | gzip -9 > "$BACKUP_DIR/$FILENAME"
# Upload in Backblaze B2 folosind AWS CLI
aws s3 cp "$BACKUP_DIR/$FILENAME" "$B2_BUCKET/$FILENAME" \
--endpoint-url "$B2_ENDPOINT" \
--only-show-errors
# Curatare fisier local temporar
rm -f "$BACKUP_DIR/$FILENAME"Am văzut prea mulți juniori care cred că o replică de citire sau un volum EBS e totuna cu un backup. Anul trecut am salvat un proiect cu 12k utilizatori activi fix pentru că aveam un script chior de pg_dump care rula în fiecare noapte la ora 3. Dacă nu ai testat niciodată procedura de restore, de fapt nu ai niciun backup — ai doar o speranță că lucrurile vor fi ok.
De ce Backblaze B2 și nu AWS S3?
Toată lumea sare direct la AWS S3 din obișnuință. Dar la $0.006/GB pe lună pentru stocare și zero costuri de egress dacă folosești un proxy adecvat sau trafic minim, B2 e un no-brainer pentru stocare rece. La un DB de vreo 35GB necomprimat, plătesc practic câțiva cenți pe lună în loc de dolari buni la Amazon.
Partea frumoasă e că Backblaze oferă API compatibil S3. Nu trebuie să instalezi mizerii exotice pe server; folosești utilitarul standard aws-cli pe care îl știe toată lumea.
Scriptul de backup
Principala problemă când faci dump-uri locale e că îți umpli discul dacă uiți de rotire. Am pățit-o pe un VPS mic cu 20GB stocare unde uitasem un script vechi fără curățenie — am stat la 2 noaptea pe SSH să șterg manual pachete ca să poată porni Postgres-ul la loc.
Scriptul pe care îl folosesc în producție pe servere mici și medii creează arhiva .sql.gz, o urcă în B2 și curăță imediat fișierul temporar local. Am lăsat codul complet în secțiunea de mai jos.
Pentru configurare, mai întâi instalezi CLI-ul și creezi un Application Key în consola Backblaze:
aws configure --profile backblaze
# Introduci KeyID, ApplicationKey si regiunea (ex: us-west-002)
Apoi adaugi asta în crontab (crontab -e) ca să ruleze la ora 03:00 am:
0 3 * * * /usr/local/bin/backup_b2.sh >> /var/log/db_backup.log 2>&1
Trade-off-uri reale: Când devine insuficient?
Hai să fim sinceri: pg_dump e o soluție excelentă pentru proiecte mici și medii. Merge brici până pe la un 50-80GB de date.
Peste pragul ăsta, dump-ul logic durează prea mult, pune un lock supărător pe resurse și blochează I/O-ul. De la 100GB în sus nu mai faci dump-uri logice; treci pe backup fizic la nivel de block (WAL-G, pgBackRest sau Point-in-Time Recovery). Dar pentru 90% din SaaS-urile sau aplicațiile dezvoltate la noi, scriptul ăsta își face treaba fără cusur.
Pasul critic: Testul de Restore
O dată pe trimestru descarc ultima arhivă pe un mediul de staging local și fac restore. Dacă nu automatizezi testul de restore, măcar fă-l manual periodic. Altfe, poți avea surpriza ca arhiva să fie coruptă din cauza unei căderi de rețea la upload.
Procesul de restore dintr-un astfel de backup se face în 3 pași rapizi:
- Descarci arhiva din B2:
aws s3 cp s3://nume-bucket-demo/db_backup_20231024.sql.gz ./ --endpoint-url https://s3.us-west-002.backblazeb2.com
- Decomprimi fișierul:
gunzip db_backup_20231024.sql.gz
- Importi datele într-o bază curată:
psql -h localhost -U postgres -d myapp_staging -f db_backup_20231024.sql
Dacă comanda trece fără erori critice de sintaxă sau de lipsă de tabelă, ești în siguranță.
Voi ce folosiți pentru proiectele de talie medie? Ați rămas pe scripturi simple cu cron sau ați migrat direct pe soluții gestionate gen Supabase / Managed Databases?