Kopie zapasowe

Dumpy bazy danych i procedury odtwarzania dla wdrożenia Sancho na Docker Compose. Stan trwały żyje pod ./data/ obok pliku compose — patrz Dane trwałe.

Automatyczny backup Postgres do S3

Serwis postgres-backup jest opcjonalny — jest zdefiniowany w docker-compose.yaml, ale uruchamia się tylko gdy aktywny jest profil backup. Aby włączyć, dodaj do .env:

COMPOSE_PROFILES=backup        # lub backup,garage

Następnie docker compose up -d. Bez tego BACKUP_S3_BUCKET jest ignorowany i żadne dumpy się nie uruchamiają. Jeśli prowadzisz backupy Postgresa poza stackiem (snapshot na poziomie hosta, managed Postgres z repliką itp.) — zostaw profil wyłączony.

Serwis (obraz: prodrigestivill/postgres-backup-local:18-s3) uruchamia pg_dump codziennie o 02:00 UTC, gzipuje dump i wysyła go do S3 przy użyciu tych samych poświadczeń, które są skonfigurowane dla API (S3_ENDPOINT, S3_API_KEY, S3_API_SECRET).

Same-host caveat dla backup + garage

Jeśli włączysz COMPOSE_PROFILES=backup,garage, backup ląduje w wewnętrznej instancji Garage — czyli na tym samym dysku co Postgres. To użyteczne, ale nie jest disaster recovery: awaria hosta zabiera i bazę, i backupy. Snapshotuj ./data/garage/ do off-site, albo wskaż S3_ENDPOINT dla backupu na zewnętrznego dostawcę.

Operatorzy Garage: utwórz bucket raz

API auto-tworzy własne buckety w Garage, ale nie BACKUP_S3_BUCKET — postgres-backup wpadnie w cichą awarię o 02:00 UTC, jeśli bucket nie istnieje. Uruchom raz po pierwszym up -d:

docker compose exec garage /garage bucket create "$BACKUP_S3_BUCKET"
docker compose exec postgres-backup /backup.sh     # wymuś jeden dump dla weryfikacji

• Cel: bucket ${BACKUP_S3_BUCKET}, dumpy w podkatalogach daily/, weekly/, monthly/. Dump w formacie custom pg_dump (--format=custom) — odtwarzanie przez pg_restore.
• Retencja: 28 dziennych, 4 tygodniowe i 4 miesięczne backupy (BACKUP_KEEP_DAYS=28, BACKUP_KEEP_WEEKS=4, BACKUP_KEEP_MONTHS=4). Starsze dumpy są przycinane automatycznie.
• Wymaganie: BACKUP_S3_BUCKET musi być ustawiony w .env, a sam bucket musi istnieć (na zewnętrznym S3 — utwórz go z wyprzedzeniem; dla Garage — patrz Aside wyżej). Serwis wpada w crash-loop z czytelnym błędem, jeśli bucket nie istnieje albo poświadczenia są błędne.
• Logi: docker compose logs -f postgres-backup — każdy run raportuje rozmiar, czas trwania i przycinanie.

Aby zweryfikować backup bez czekania do 02:00, uruchom on-demand:

docker compose exec postgres-backup /backup.sh

Backup ad-hoc / pełny

# Dump bazy danych do pliku lokalnego
docker compose exec postgres pg_dump -U $PG_USER $PG_DB | gzip > "sancho-$(date +%F).sql.gz"

# Pełne drzewo danych (postgres + rabbitmq + redis + stan caddy)
sudo tar -czf "sancho-data-$(date +%F).tar.gz" data/

Backupuj również zawartość swojego bucketu S3 (buckety API) — obsługą zajmuje się dostawca storage.

Odtwarzanie

Z automatycznego backupu S3

Pobierz dump z S3 (działa dowolny klient S3), a następnie zaaplikuj go do bazy:

mc cp <alias>/$BACKUP_S3_BUCKET/daily/sancho-YYYY-MM-DD.sql.gz ./
gunzip -c sancho-YYYY-MM-DD.sql.gz | docker compose exec -T postgres pg_restore -U $PG_USER -d $PG_DB --clean --if-exists

Z lokalnego pg_dump

gunzip -c sancho-YYYY-MM-DD.sql.gz | docker compose exec -T postgres psql -U $PG_USER $PG_DB

Z pełnego drzewa danych

Zatrzymaj stack przed odtworzeniem:

docker compose down
sudo tar -xzf sancho-data-YYYY-MM-DD.tar.gz
docker compose up -d