#!/bin/bash
set -e
# Configurare variabile
DB_NAME="nume_baza_date"
DB_USER="postgres"
BACKUP_DIR="/tmp/backups"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
FILE_NAME="$BACKUP_DIR/$DB_NAME-$DATE.sql.gz"
B2_BUCKET="b2-remote:nume-bucket-backblaze"
# Crează directorul temporar dacă nu există
mkdir -p "$BACKUP_DIR"
# Dump direct în gzip pentru a economisi spațiu pe disc
pg_dump -U "$DB_USER" -h localhost -F p "$DB_NAME" | gzip > "$FILE_NAME"
# Încarcă în Backblaze B2 folosind rclone
rclone copy "$FILE_NAME" "$B2_BUCKET" --quiet
# Șterge fișierul local temporar
rm "$FILE_NAME"
echo "Backup completat cu succes în B2: $DB_NAME-$DATE.sql.gz"Salutare! Zilele trecute am mutat backup-urile unui client de pe AWS S3 pe Backblaze B2. La vreo 150 GB de backup-uri zilnice, păstrate timp de 30 de zile, am redus factura de la vreo 90$ la sub 15$ pe lună. Sincer, pentru proiecte mici și medii, AWS S3 e jaf la drumul mare când vine vorba de storage și mai ales de trafic de egress.
Am pus la punct un script simplu în Bash care face pg_dump, îl comprimă direct în zbor și îl urcă în B2 folosind rclone. E sfânt, îl am pe vreo 6 producții active acum și n-a crăpat niciodată.
De ce rclone și nu utilitarul oficial B2?
Am testat b2-cli acum ceva timp, dar rclone e mult mai flexibil. Are retry-uri automate mai deștepte în caz de timeout și, dacă mâine vrei să muți backup-urile pe Cloudflare R2 sau alt S3-compatible storage, schimbi doar o linie în config-ul de rclone. Nu rescrii scriptul.
În plus, rclone știe să facă curățenie singur dacă îi pui un flag de expirare sau dacă folosești politicile de lifecycle direct din consola Backblaze (ceea ce recomand, e mai sigur așa).
Trade-off-uri pe care trebuie să le știi
Soluția asta e excelentă pentru baze de date de până în 50-100 GB. Peste pragul ăsta, pg_dump în format text sau custom începe să mănânce multe resurse de CPU și I/O în timp ce rulează. Poate chiar să-ți încetinească query-urile din producție dacă ai trafic mare în acel moment.
Dacă ai DB de sute de giga, ai nevoie de backup fizic (cum e pgBackRest sau Barman) care face streaming de WAL-uri și permite Point-in-Time Recovery (PITR). Dar pentru 90% din proiectele de pe la noi, un dump zilnic la ora 03:00 dimineața e mai mult decât suficient.
Partea cea mai importantă: Cum testezi restore-ul?
Am pățit-o prin 2018. Făceam backup-uri zilnice, totul părea verde în loguri. Când a crăpat un disc și am vrut să fac restore, am realizat că dump-urile erau goale din cauza unei erori de permisiuni la o schemă nouă din baza de date. De atunci, regula mea e simplă: un backup netestat nu există.
Pentru restore, eu folosesc comanda asta într-un container temporar de Docker ca să nu murdăresc DB-ul local de development:
gunzip -c backup_nume_db.sql.gz | docker exec -i my_postgres_container psql -U postgres -d test_db
Fă-ți un obicei din a descărca o dată la 3 luni un backup din B2 și a-i da un restore pe local. Îți ia fix 5 minute, dar dormi liniștit noaptea știind că fișierele alea chiar conțin date valide.
Cum pui totul pe cron?
Rulezi crontab -e pe serverul tău și adaugi linia asta ca să ruleze în fiecare noapte la ora 3:
0 3 * * * /usr/local/bin/backup-db.sh >> /var/log/db-backup.log 2>&1
Nu uita să dai chmod +x /usr/local/bin/backup-db.sh după ce salvezi scriptul în acel path.
Voi ce folosiți pentru baze de date mai mărișoare? Mergeți pe tool-uri dedicate de backup fizic sau tot pe scripturi custom cu pg_dump și upload în cloud?