#!/bin/bash
set -euo pipefail
# Configurare
DB_NAME="nume_baza_date"
DB_USER="postgres"
BACKUP_DIR="/tmp"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
BACKUP_FILE="$BACKUP_DIR/db_backup_$DATE.sql.gz"
B2_BUCKET="s3://bucket-ul-tau"
B2_ENDPOINT="https://s3.us-west-004.backblazeb2.com" # Modifică cu endpoint-ul tău din B2
# Dump direct comprimat
echo "Pornire dump pentru $DB_NAME..."
pg_dump -h localhost -U "$DB_USER" -F p "$DB_NAME" | gzip > "$BACKUP_FILE"
# Upload în Backblaze B2 folosind AWS CLI
echo "Upload în Backblaze B2..."
aws s3 cp "$BACKUP_FILE" "$B2_BUCKET/db_backup_$DATE.sql.gz" --endpoint-url "$B2_ENDPOINT"
# Curățare fișier local
rm "$BACKUP_FILE"
echo "Backup finalizat cu succes!"Salutare! Hai să vorbim despre backup-uri, că toți zicem că le facem, dar puțini le și testăm. Săptămâna trecută am mutat un proiect cu vreo 12k useri activi de pe un VPS vechi și a trebuit să refac schema de backup pentru Postgres. N-aveam chef să plătesc zeci de dolari pe lună pentru snapshot-uri automate în AWS, așa că am mers pe rețeta clasică: pg_dump + Backblaze B2 (care e practic gratis la volume mici) + un cron job bătrânesc.
Am pățit în trecut să am scripturi de backup care rulau fericite în cron, dar când a picat serverul, arhiva era coruptă. De atunci, am o regulă de aur: nu plec la bere până nu fac un restore cap-coadă pe o mașină curată.
De ce Backblaze B2 și nu AWS S3?
Sincer? Pentru că e ieftin de speriat. La 0.005$ pe GB, stocarea e aproape gratis. Trade-off-ul e că API-ul lor e un pic mai lent la upload-uri mari comparat cu AWS S3, iar consola lor web arată ca în 2012. Dar pentru baze de date de sub 50GB, diferența de viteză e insesizabilă și configurarea e identică, fiindcă B2 are API compatibil cu S3.
Pentru implementare, am folosit aws-cli configurat cu endpoint-ul de B2. E mult mai stabil decât utilitarul lor nativ de Python.
Scriptul de backup
Scriptul de mai jos (pe care îl găsești în secțiunea de cod) face câteva chestii esențiale: setează variabilele, rulează pg_dump direct comprimat cu gzip ca să economisim lățime de bandă, trimite fișierul în B2 și apoi curăță fișierul local ca să nu umplem disk-ul serverului.
Cum îl pui în Cron ca să dormi liniștit
Salvează scriptul în /usr/local/bin/backup_db.sh și fă-l executabil cu chmod +x. Ca să ruleze în fiecare noapte la ora 3:00, adaugă asta în crontab (crontab -e):
0 3 * * * /usr/local/bin/backup_db.sh >> /var/log/db_backup.log 2>&1
Redirecționarea logurilor e sfântă. Altfel, dacă crapă ceva, n-o să ai nicio idee de ce nu s-a generat backup-ul.
Testul adevărului: Cum faci Restore?
Dacă nu ai testat restore-ul, nu ai backup. Punct. Am văzut destui juniori care au transpirat rece când au realizat că backup-ul lor de 10GB era doar un fișier gol pentru că pg_dump dăduse o eroare de permisiuni pe care scriptul o ignorase.
Iată pașii exacți pentru restore pe o bază de date locală de test:
# 1. Descarcă backup-ul din B2
aws s3 cp s3://bucket-ul-tau/db_backup_2023-10-27.sql.gz . --endpoint-url https://s3.us-west-004.backblazeb2.com
# 2. Dezarhivează-l
gunzip db_backup_2023-10-27.sql.gz
# 3. Șterge și recreează DB-ul local (atenție, doar pe mașina de test!)
dropdb -h localhost -U postgres db_proiect_test --if-exists
createdb -h localhost -U postgres db_proiect_test
# 4. Importă datele
psql -h localhost -U postgres -d db_proiect_test -f db_backup_2023-10-27.sql
Dacă importul trece fără erori majore (mici warning-uri legate de owneri sunt normale), abia atunci poți spune că ai o strategie de disaster recovery funcțională.
Voi cum faceți backup-urile la proiectele mici și medii? Tot scripturi custom sau folosiți tool-uri SaaS dedicate?