fix: Gitea Traefik routing and connection pool optimization
Some checks failed
🚀 Build & Deploy Image / Determine Build Necessity (push) Failing after 10m14s
🚀 Build & Deploy Image / Build Runtime Base Image (push) Has been skipped
🚀 Build & Deploy Image / Build Docker Image (push) Has been skipped
🚀 Build & Deploy Image / Run Tests & Quality Checks (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Staging (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Production (push) Has been skipped
Security Vulnerability Scan / Check for Dependency Changes (push) Failing after 11m25s
Security Vulnerability Scan / Composer Security Audit (push) Has been cancelled
Some checks failed
🚀 Build & Deploy Image / Determine Build Necessity (push) Failing after 10m14s
🚀 Build & Deploy Image / Build Runtime Base Image (push) Has been skipped
🚀 Build & Deploy Image / Build Docker Image (push) Has been skipped
🚀 Build & Deploy Image / Run Tests & Quality Checks (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Staging (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Production (push) Has been skipped
Security Vulnerability Scan / Check for Dependency Changes (push) Failing after 11m25s
Security Vulnerability Scan / Composer Security Audit (push) Has been cancelled
- Remove middleware reference from Gitea Traefik labels (caused routing issues) - Optimize Gitea connection pool settings (MAX_IDLE_CONNS=30, authentication_timeout=180s) - Add explicit service reference in Traefik labels - Fix intermittent 504 timeouts by improving PostgreSQL connection handling Fixes Gitea unreachability via git.michaelschiemer.de
This commit is contained in:
362
deployment/docs/guides/backup-and-rollback-guide.md
Normal file
362
deployment/docs/guides/backup-and-rollback-guide.md
Normal file
@@ -0,0 +1,362 @@
|
||||
# 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](./deployment-commands.md) - Command-Referenz
|
||||
- [Application Stack Deployment](../reference/application-stack.md) - 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):**
|
||||
```bash
|
||||
cd /home/michael/dev/michaelschiemer
|
||||
./deployment/scripts/test-backup.sh
|
||||
```
|
||||
|
||||
**Manuell:**
|
||||
```bash
|
||||
cd deployment/ansible
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/backup.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
```
|
||||
|
||||
**Mit Optionen:**
|
||||
```bash
|
||||
# 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:**
|
||||
```bash
|
||||
# 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:**
|
||||
```bash
|
||||
# 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:**
|
||||
```bash
|
||||
# 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:**
|
||||
```bash
|
||||
cd deployment/ansible
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/rollback.yml \
|
||||
--vault-password-file secrets/.vault_pass
|
||||
```
|
||||
|
||||
**Zu spezifischer Version:**
|
||||
```bash
|
||||
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:**
|
||||
```bash
|
||||
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:**
|
||||
```bash
|
||||
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:**
|
||||
```bash
|
||||
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:**
|
||||
```bash
|
||||
# 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](./deployment-commands.md) - Command-Referenz
|
||||
- [Application Stack Deployment](../reference/application-stack.md) - Detaillierter Ablauf
|
||||
- [CI/CD Workflow Guide](./cicd-workflow-guide.md) - CI/CD Workflows
|
||||
|
||||
Reference in New Issue
Block a user