#!/bin/bash
set -e
# Configurare variabile
DB_NAME="prod_db"
DB_USER="postgres"
BACKUP_DIR="/var/backups/postgres"
DATE=$(date +"%Y-%m-%d_%H-%M-%S")
FILENAME="$BACKUP_DIR/$DB_NAME-$DATE.dump"
B2_BUCKET="s3://nume-bucket-backblaze"
B2_ENDPOINT="https://s3.us-west-004.backblazeb2.com" # Schimbă cu endpoint-ul tău
mkdir -p "$BACKUP_DIR"
echo "[$(date)] Pornit pg_dump pentru $DB_NAME..."
pg_dump -h localhost -U "$DB_USER" -F c -b -v -f "$FILENAME" "$DB_NAME"
echo "[$(date)] Upload în Backblaze B2..."
aws s3 cp "$FILENAME" "$B2_BUCKET/$DB_NAME-$DATE.dump" --endpoint-url="$B2_ENDPOINT"
echo "[$(date)] Curățare fișier local..."
rm "$FILENAME"
echo "[$(date)] Backup finalizat cu succes!"Toți zicem că avem backup-uri până când crapă serverul și realizăm că scriptul ăla vechi din cron dădea eroare de permisiuni de șase luni. Am pățit-o acum doi ani la un proiect cu vreo 40GB de date în PostgreSQL și de atunci nu mai las lucrurile la voia întâmplării. Azi vă arăt configurarea mea simplă cu pg_dump, cron și Backblaze B2, care mă costă sub 2 dolari pe lună și funcționează ceas.
De ce Backblaze B2 și nu AWS S3?
Sincer, pentru că e incredibil de ieftin. La AWS plătești pentru orice mișcare (stocare, API calls, transfer out). La B2, stocarea e în jur de 6$/TB pe lună, iar primii 10GB sunt gratuiți.
Există totuși un trade-off sincer: API-ul lor compatibil cu S3 funcționează destul de bine, dar uneori viteza de upload pentru fișiere mari fluctuează mai mult decât pe AWS. Pentru backup-uri zilnice, însă, nu mă interesează dacă upload-ul durează 2 sau 5 minute.
Un alt aspect important de care m-am lovit: rularea pg_dump direct pe mașina de producție mănâncă CPU și I/O. La baza mea actuală de 45GB, spike-ul de CPU ajunge pe la 60% timp de vreo 4 minute. Dacă aveți trafic mare și constant, rulați dump-ul de pe o replică read-only, nu direct pe master.
Cum configurăm tool-urile
Pentru a urca fișierele în Backblaze B2, cel mai simplu este să folosim aws-cli. B2 oferă API compatibil cu S3, așa că nu trebuie să învățăm tool-uri noi.
Instalați aws-cli pe server și rulați aws configure. Introduceți cheile de acces generate din panoul Backblaze (Application Key și Key ID). La regiune puneți orice (de exemplu, us-east-1), dar aveți grijă să folosiți endpoint-ul corect de B2 în script.
Scriptul pe care îl folosesc folosește formatul custom (-F c) din pg_dump. Este cel mai flexibil format deoarece este arhivat implicit și îți permite să restaurezi doar anumite tabele dacă e nevoie, spre deosebire de un dump simplu în format text SQL.
Automatizarea cu cron
Odată ce scriptul de mai sus funcționează rulat manual, îl punem în cron. Recomand să-l rulați la o oră moartă, de exemplu la 3 dimineața, când traficul este minim.
Deschideți crontab cu crontab -e și adăugați linia:
0 3 * * * /usr/local/bin/backup_postgres.sh >> /var/log/pg_backup.log 2>&1
Este critic să redirecționați atât stdout, cât și stderr într-un fișier de log. Altfel, dacă scriptul crapă (de exemplu, dacă expiră cheia de B2), nu veți avea nicio idee de ce nu s-a mai făcut backup-ul.
Partea sfântă: Testul de restore
Un backup netestat nu există. Am văzut zeci de echipe care făceau backup-uri zilnic, dar când a fost nevoie de restore, au realizat că fișierele erau corupte sau că userul de sistem nu avea drepturi de scriere pe tabelele noi.
Pentru a testa restore-ul pe o mașină locală sau pe un server de staging, descărcați dump-ul din B2 și rulați comanda:
pg_restore -h localhost -U postgres -d db_test -v /cale/catre/backup.dump
Eu am automatizat și acest pas în staging: o dată pe săptămână, un server de test trage ultimul backup din B2 și rulează pg_restore pe o bază de date temporară. Dacă procesul returnează codul de eroare 0, știu sigur că ne putem baza pe acele date în caz de dezastru.
Voi cum vă asigurați că backup-urile voastre chiar pot fi restaurate la nevoie? Automatizați procesul de restore în staging sau mergeți pe încredere?