bollwerkadmin/bollwerk
1
0
Fork 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions

Infrastruktur: Tägliches PostgreSQL-Backup mit 1 GB Rotation #87

New issue
Closed
opened 2026-05-17 08:48:19 +00:00 by jreinemann-euris · 1 comment
jreinemann-euris commented 2026-05-17 08:48:19 +00:00 (Migrated from github.com)
Copy link

Kontext

Die PostgreSQL-Datenbank auf dem VPS braucht ein automatisches Backup, um Datenverlust zu vermeiden.

Akzeptanzkriterien

1. Tägliches Backup um 03:00 Uhr

  • Cronjob oder Container-basierter Scheduler führt täglich um 03:00 UTC ein pg_dump der Krisenvorrat-Datenbank aus
  • Backup-Dateien werden komprimiert gespeichert (z.B. .sql.gz)
  • Dateiname enthält Timestamp (z.B. krisenvorrat_2026-05-17_0300.sql.gz)
  • Skip bei unveränderter DB: Vor dem Backup prüfen, ob sich seit dem letzten Backup etwas geändert hat (z.B. Checksum/Hash des Dumps mit dem letzten vergleichen). Falls keine Änderung → kein neues Backup anlegen

2. Speicherlimit 1 GB

  • Nach jedem Backup wird geprüft, ob die Gesamtgröße aller Backups 1 GB überschreitet
  • Falls ja: älteste Backups werden gelöscht, bis die Gesamtgröße wieder unter 1 GB liegt

3. Deployment

  • Backup-Lösung ist in docker-compose.yml integriert (eigener Service oder Erweiterung des bestehenden Setups)
  • Backup-Verzeichnis ist als Volume gemountet, damit Backups bei Container-Neustart erhalten bleiben

4. Verifizierung

  • Manueller Test: Backup-Skript einmal manuell ausführen und prüfen, ob die .sql.gz-Datei valide ist (gunzip -t + psql-Import auf Testinstanz)
  • Rotation: Prüfen, dass bei Überschreitung von 1 GB die ältesten Dateien entfernt werden

Technische Hinweise

  • Server läuft auf VPS (1984 Hosting, Island) mit Docker
  • PostgreSQL läuft bereits als Container (docker-compose.yml)
  • Bewährte Optionen: pg_dump per Cronjob im Container, oder dedizierter Backup-Container (z.B. prodrigestivill/postgres-backup-local)
  • Backup-Verzeichnis: z.B. /data/backups auf dem Host
## Kontext Die PostgreSQL-Datenbank auf dem VPS braucht ein automatisches Backup, um Datenverlust zu vermeiden. ## Akzeptanzkriterien ### 1. Tägliches Backup um 03:00 Uhr - [ ] Cronjob oder Container-basierter Scheduler führt täglich um 03:00 UTC ein `pg_dump` der Krisenvorrat-Datenbank aus - [ ] Backup-Dateien werden komprimiert gespeichert (z.B. `.sql.gz`) - [ ] Dateiname enthält Timestamp (z.B. `krisenvorrat_2026-05-17_0300.sql.gz`) - [ ] **Skip bei unveränderter DB:** Vor dem Backup prüfen, ob sich seit dem letzten Backup etwas geändert hat (z.B. Checksum/Hash des Dumps mit dem letzten vergleichen). Falls keine Änderung → kein neues Backup anlegen ### 2. Speicherlimit 1 GB - [ ] Nach jedem Backup wird geprüft, ob die Gesamtgröße aller Backups 1 GB überschreitet - [ ] Falls ja: älteste Backups werden gelöscht, bis die Gesamtgröße wieder unter 1 GB liegt ### 3. Deployment - [ ] Backup-Lösung ist in `docker-compose.yml` integriert (eigener Service oder Erweiterung des bestehenden Setups) - [ ] Backup-Verzeichnis ist als Volume gemountet, damit Backups bei Container-Neustart erhalten bleiben ### 4. Verifizierung - [ ] Manueller Test: Backup-Skript einmal manuell ausführen und prüfen, ob die `.sql.gz`-Datei valide ist (`gunzip -t` + `psql`-Import auf Testinstanz) - [ ] Rotation: Prüfen, dass bei Überschreitung von 1 GB die ältesten Dateien entfernt werden ## Technische Hinweise - Server läuft auf VPS (1984 Hosting, Island) mit Docker - PostgreSQL läuft bereits als Container (`docker-compose.yml`) - Bewährte Optionen: `pg_dump` per Cronjob im Container, oder dedizierter Backup-Container (z.B. `prodrigestivill/postgres-backup-local`) - Backup-Verzeichnis: z.B. `/data/backups` auf dem Host
jreinemann-euris commented 2026-05-17 09:15:07 +00:00 (Migrated from github.com)
Copy link

Abgeschlossen (2026-05-17)

Durchgeführte Aufgaben

  • ✅ backup/Dockerfile: Alpine 3.21 + postgresql-client + busybox crond (containerfreundlich, kein \setpgid)
  • ✅ backup/backup.sh: pg_dump → MD5-Checksum-Vergleich (PostgreSQL-17-Tokens \\restrict/\\unrestrict\ herausgefiltert) → gzip-komprimiertes Backup mit Timestamp → Rotation (älteste .sql.gz löschen bis < 1 GB)
  • ✅ docker-compose.yml: neuer Service \ackup, Volume \ackup_data\
  • ✅ Cronjob: täglich 03:00 UTC
  • ✅ Auf VPS deployed (\krisenvorrat-backup\ läuft)

Verifikation

  • Manueller Lauf: \krisenvorrat_2026-05-17_0913.sql.gz\ erstellt, \gunzip -t\ Exit 0 ✅
  • Skip bei unveränderter DB: zweiter Lauf → No changes since last backup. Skipping. ✅
  • Rotation: bei 1.2 GB Testdaten → älteste Dateien gelöscht bis < 1 GB ✅
## Abgeschlossen (2026-05-17) ### Durchgeführte Aufgaben - ✅ **backup/Dockerfile**: Alpine 3.21 + postgresql-client + busybox crond (containerfreundlich, kein \setpgid\) - ✅ **backup/backup.sh**: pg_dump → MD5-Checksum-Vergleich (PostgreSQL-17-Tokens \\\restrict\/\\\unrestrict\ herausgefiltert) → gzip-komprimiertes Backup mit Timestamp → Rotation (älteste .sql.gz löschen bis < 1 GB) - ✅ **docker-compose.yml**: neuer Service \ackup\, Volume \ackup_data\ - ✅ Cronjob: täglich 03:00 UTC - ✅ Auf VPS deployed (\krisenvorrat-backup\ läuft) ### Verifikation - Manueller Lauf: \krisenvorrat_2026-05-17_0913.sql.gz\ erstellt, \gunzip -t\ Exit 0 ✅ - Skip bei unveränderter DB: zweiter Lauf → *No changes since last backup. Skipping.* ✅ - Rotation: bei 1.2 GB Testdaten → älteste Dateien gelöscht bis < 1 GB ✅
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
block-planning

   
bug

Something isn't working

  
documentation

Improvements or additions to documentation

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
feature

   
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
infrastructure

   
invalid

This doesn't seem right

  
planning

   
priority:high

   
priority:low

   
question

Further information is requested

  
refactoring

   
status:backlog

Im Backlog

  
status:done

Abgeschlossen

  
status:in-progress

Aktuell in Bearbeitung

  
status:todo

Naechstes Todo-Ticket

  
tech-decision

   
test

   
wontfix

This will not be worked on

No labels
block-planning
bug
documentation
duplicate
enhancement
feature
good first issue
help wanted
infrastructure
invalid
planning
priority:high
priority:low
question
refactoring
status:backlog
status:done
status:in-progress
status:todo
tech-decision
test
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: bollwerkadmin/bollwerk#87
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?