michaelschiemer/deployment/docs/guides/backup-and-rollback-guide.md

Backup & Rollback Guide

Stand: 2025-11-07
Status: Vollständige Dokumentation der Backup- und Rollback-Strategie

---

Übersicht

Dieses Dokument erklärt die Backup- und Rollback-Strategie für das Deployment. Backups werden automatisch erstellt und können für Rollbacks verwendet werden.

📖 Verwandte Dokumentation:

• Deployment Commands - Command-Referenz
• Application Stack Deployment - Detaillierter Ablauf

---

Backup-Strategie

Backup-Playbook

Datei: deployment/ansible/playbooks/backup.yml

Zweck: Erstellt vollständige Backups aller kritischen Daten

Backup-Ziele:

• ✅ PostgreSQL Datenbanken (Production + Staging)
• ✅ Application Code (Git Repository)
• ✅ Application Storage (Logs, Cache, etc.)
• ✅ Gitea Data
• ✅ Docker Registry Images (optional)

Backup ausführen

Mit Test-Script (Empfohlen):

cd /home/michael/dev/michaelschiemer
./deployment/scripts/test-backup.sh

Manuell:

cd deployment/ansible
ansible-playbook -i inventory/production.yml \
  playbooks/backup.yml \
  --vault-password-file secrets/.vault_pass

Mit Optionen:

# Nur PostgreSQL Backup
ansible-playbook -i inventory/production.yml \
  playbooks/backup.yml \
  -e "backup_postgresql=true" \
  -e "backup_application_data=false" \
  -e "backup_gitea=false" \
  --vault-password-file secrets/.vault_pass

# Retention Policy anpassen (Standard: 7 Tage)
ansible-playbook -i inventory/production.yml \
  playbooks/backup.yml \
  -e "backup_retention_days=14" \
  --vault-password-file secrets/.vault_pass

Backup-Struktur

Backup-Verzeichnis: /home/deploy/deployment/backups/

Struktur:

backups/
├── backup_2025-11-07_14-30-00/
│   ├── postgresql_michaelschiemer_2025-11-07_14-30-00.sql.gz
│   ├── application_storage_2025-11-07_14-30-00.tar.gz
│   ├── application_logs_2025-11-07_14-30-00.tar.gz
│   ├── application_env_2025-11-07_14-30-00.env
│   ├── gitea_data_2025-11-07_14-30-00.tar.gz
│   └── backup_metadata.txt
└── backup_2025-11-06_14-30-00/
    └── ...

Backup-Komponenten

PostgreSQL Backup:

• Format: postgresql_<database>_<date>_<time>.sql.gz
• Inhalt: Vollständiger Database Dump
• Komprimierung: Gzip

Application Storage:

• Format: application_storage_<date>_<time>.tar.gz
• Inhalt: storage/ Verzeichnis
• Komprimierung: Tar + Gzip

Application Logs:

• Format: application_logs_<date>_<time>.tar.gz
• Inhalt: storage/logs/ Verzeichnis
• Komprimierung: Tar + Gzip

Application .env:

• Format: application_env_<date>_<time>.env
• Inhalt: Environment-Variablen

Gitea Data:

• Format: gitea_data_<date>_<time>.tar.gz
• Inhalt: Gitea Volume
• Komprimierung: Tar + Gzip

Retention Policy

Standard: 7 Tage

Konfiguration:

• Backups älter als backup_retention_days werden automatisch gelöscht
• Retention kann via -e backup_retention_days=14 angepasst werden

Beispiel:

# 14 Tage Retention
ansible-playbook -i inventory/production.yml \
  playbooks/backup.yml \
  -e "backup_retention_days=14" \
  --vault-password-file secrets/.vault_pass

Backup-Verifikation

Automatisch:

• Playbook prüft ob Backup-Dateien erstellt wurden
• Dateigrößen werden angezeigt
• Fehler wenn keine Backups erstellt wurden

Manuell auf Server:

# Auf Server prüfen
ssh deploy@94.16.110.151
ls -lh ~/deployment/backups/backup_*/

# Backup-Metadaten anzeigen
cat ~/deployment/backups/backup_*/backup_metadata.txt

# Backup-Dateien auflisten
find ~/deployment/backups/backup_* -type f -ls

Backup-Test durchführen:

# Test-Backup mit Verifikation
cd /home/michael/dev/michaelschiemer
./deployment/scripts/test-backup.sh

# Danach auf Server verifizieren
ssh deploy@94.16.110.151
ls -lh ~/deployment/backups/backup_*/
cat ~/deployment/backups/backup_*/backup_metadata.txt

---

Rollback-Strategie

Rollback-Playbook

Datei: deployment/ansible/playbooks/rollback.yml

Zweck: Rollback zu vorheriger Version

Rollback-Optionen:

• Image Rollback (Docker Image)
• Code Rollback (Git Repository)
• Database Rollback (PostgreSQL)

Rollback ausführen

Zu letzter Version:

cd deployment/ansible
ansible-playbook -i inventory/production.yml \
  playbooks/rollback.yml \
  --vault-password-file secrets/.vault_pass

Zu spezifischer Version:

ansible-playbook -i inventory/production.yml \
  playbooks/rollback.yml \
  -e "rollback_to_version=backup_2025-11-06_14-30-00" \
  --vault-password-file secrets/.vault_pass

Rollback-Szenarien

1. Image Rollback

Zweck: Rollback zu vorherigem Docker Image

Prozess:

1. Vorheriges Image wird identifiziert
2. docker-compose.production.yml wird aktualisiert
3. Container werden neu gestartet

Beispiel:

ansible-playbook -i inventory/production.yml \
  playbooks/rollback.yml \
  -e "rollback_type=image" \
  --vault-password-file secrets/.vault_pass

2. Code Rollback

Zweck: Rollback zu vorherigem Git Commit

Prozess:

1. Vorheriger Git Commit wird identifiziert
2. Repository wird auf vorherigen Commit zurückgesetzt
3. Container werden neu gestartet

Beispiel:

ansible-playbook -i inventory/production.yml \
  playbooks/rollback.yml \
  -e "rollback_type=code" \
  --vault-password-file secrets/.vault_pass

3. Database Rollback

Zweck: Rollback zu vorherigem Database Backup

Prozess:

1. Vorheriges Database Backup wird identifiziert
2. Database wird aus Backup wiederhergestellt
3. Verifikation wird durchgeführt

Wichtig: Database Rollback sollte nur bei kritischen Problemen verwendet werden.

Beispiel:

ansible-playbook -i inventory/production.yml \
  playbooks/rollback.yml \
  -e "rollback_type=database" \
  -e "rollback_to_version=backup_2025-11-06_14-30-00" \
  --vault-password-file secrets/.vault_pass

---

Automatisierung

Geplante Backups

Empfohlen: Tägliche Backups via Cron oder Systemd Timer

Cron-Beispiel:

# Täglich um 2:00 Uhr
0 2 * * * cd /path/to/deployment/ansible && ansible-playbook -i inventory/production.yml playbooks/backup.yml --vault-password-file secrets/.vault_pass

Systemd Timer (Empfohlen):

• Erstellt Systemd Service und Timer
• Bessere Logging-Integration
• Bessere Fehlerbehandlung

Backup-Monitoring

Empfohlen: Alerts bei Backup-Fehlern

Methoden:

• Email-Benachrichtigungen
• Monitoring-Integration (Grafana/Prometheus)
• Log-Analyse

---

Best Practices

1. Regelmäßige Backups

Empfohlen: Täglich

Vorteile:

• Minimale Datenverluste
• Schneller Rollback möglich
• Compliance-Anforderungen

2. Backup-Verifikation

Empfohlen: Regelmäßige Restore-Tests

Vorteile:

• Sicherstellung dass Backups funktionieren
• Vertrautheit mit Restore-Prozess
• Identifikation von Problemen

3. Retention Policy

Empfohlen: 7-30 Tage

Abwägung:

• Längere Retention = Mehr Speicherplatz
• Kürzere Retention = Weniger Speicherplatz, aber weniger Rollback-Optionen

4. Offsite Backups

Empfohlen: Wichtige Backups extern speichern

Methoden:

• S3-compatible Storage (MinIO)
• SFTP/SCP zu externem Server
• Cloud Storage (optional)

---

Troubleshooting

Problem: Backup schlägt fehl

Ursachen:

• Container laufen nicht
• Speicherplatz voll
• Berechtigungen fehlen

Lösung:

• Prüfe Container Status
• Prüfe verfügbaren Speicherplatz
• Prüfe Berechtigungen

Problem: Rollback schlägt fehl

Ursachen:

• Backup existiert nicht
• Backup ist korrupt
• Container laufen nicht

Lösung:

• Prüfe ob Backup existiert
• Prüfe Backup-Integrität
• Prüfe Container Status

Problem: Database Restore schlägt fehl

Ursachen:

• Database läuft nicht
• Backup ist korrupt
• Berechtigungen fehlen

Lösung:

• Prüfe Database Status
• Prüfe Backup-Integrität
• Prüfe Database-Berechtigungen

---

Referenz

• Deployment Commands - Command-Referenz
• Application Stack Deployment - Detaillierter Ablauf
• CI/CD Workflow Guide - CI/CD Workflows