#!/bin/bash
# Script de backup PostgreSQL -> Backblaze B2
DB_NAME="nume_baza_date"
BACKUP_DIR="/var/backups/postgres"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
FILENAME="${DB_NAME}_${DATE}.dump"
B2_BUCKET="b2-my-backups"
# Asigură-te că directorul de backup există
mkdir -p "$BACKUP_DIR"
# Dump în format custom (compresat nativ de pg_dump)
pg_dump -F c -b -v -f "${BACKUP_DIR}/${FILENAME}" "${DB_NAME}"
# Urcă în Backblaze B2 folosind rclone
rclone copy "${BACKUP_DIR}/${FILENAME}" "b2:${B2_BUCKET}/db_backups/"
# Șterge dump-urile mai vechi de 7 zile de pe serverul local
find "$BACKUP_DIR" -type f -mtime +7 -name "*.dump" -deleteSalutare tuturor. Am văzut prea des oameni care își pun baza de date pe "auto-pilot" și își dau seama că backup-urile lor sunt corupte sau goale abia când crapă serverul de producție. Am pățit chestia asta acum vreo 5 ani la un proiect cu 15.000 de useri activi și, credeți-mă, nu vreți să simțiți transpirația aia rece când vezi un fișier .sql de 0 KB.
De atunci, am un sistem simplu, ieftin și extrem de sigur pe care îl aplic la aproape orice proiect mediu: backup automat cu pg_dump, trimis direct în Backblaze B2 folosind rclone.
De ce Backblaze B2 și nu AWS S3?
Răspunsul scurt: costul. AWS S3 e excelent, dar pentru stocare de backup-uri istorice devine scump din cauza politicilor de transfer și a prețului pe GB. În B2 plătesc în jur de 1.5 dolari pe lună pentru vreo 200 GB de backup-uri. La AWS, cu aceleași reguli de retenție și trafic, treceam lejer de 10-12 dolari. Nu e o avere, dar de ce să arunci cu banii când B2 îți oferă API compatibil cu S3 și aceeași durabilitate a datelor?
Scriptul de backup (pg_dump + rclone)
Nu vă complicați cu tool-uri mamut. Un script de Bash de 20 de linii rulat prin Cron își face treaba perfect. Condiția este să folosiți formatul custom de la postgres (-F c), nu plain text .sql. Formatul custom e deja arhivat, ocupă mult mai puțin spațiu și îți permite să selectezi ce tabele restaurezi la nevoie.
Înainte de a rula scriptul de mai jos, trebuie să aveți instalat rclone și configurat un remote numit b2 (se face super simplu cu rclone config).
Trade-off-ul sincer al acestei soluții
Merge de minune pentru baze de date de până în 30-50 GB. Peste pragul ăsta, pg_dump începe să mănânce CPU serios în timpul compresiei și blochează anumite operațiuni de întreținere. La un magazin online mare, rularea unui dump în mijlocul zilei poate genera timeout-uri în aplicație. Dacă săriți de 100 GB, uitați de pg_dump și treceți pe soluții de backup fizic (cum e WAL-G sau pgBackRest) care fac backup-uri incrementale fără să streseze baza de date.
Cum testezi restore-ul (Pasul cel mai important!)
Un backup pe care nu s-a făcut restore niciodată se numește "schrödinger backup" - nu știi dacă există până nu ai nevoie de el. Eu am un task în calendar la fiecare 3 luni: trag ultimul dump din B2 și îl ridic într-un container local de Docker.
Comanda de restore pentru formatul custom este:
pg_restore -d nume_db_test -v /path/to/backup.dump
Dacă restore-ul rulează fără erori majore (erorile de tipul owner pot fi ignorate dacă folosiți alt user local), înseamnă că dormiți liniștiți.
Cum îl pui în Cron
Cea mai comună greșeală e să pui scriptul în crontab fără path-uri absolute. Cron rulează într-un environment minimal și s-ar putea să nu găsească pg_dump sau rclone.
Deschideți crontab:
crontab -e
Și adăugați linia asta ca să ruleze în fiecare noapte la ora 3:
0 3 * * * /bin/bash /home/user/scripts/db_backup.sh >> /var/log/db_backup.log 2>&1
Voi cum vă asigurați că backup-urile chiar funcționează? Le aveți automatizate sau mergeți pe sistemul "sperăm să nu crape"?