Backups & Wiederherstellung

Legen Sie regelmäßige Backups an (SQLite-Schnappschuss) und bewahren Sie sie sicher, ideal verschlüsselt und extern, auf. Testen Sie die Wiederherstellung, damit im Ernstfall alles klappt.

Warum Backups wichtig sind

Backups schützen vor:

🔥 Hardware-Ausfall: Server-Festplatte defekt
🐛 Software-Bugs: Datenbankkorruption
👤 Menschliche Fehler: Versehentliches Löschen
🔒 Ransomware: Verschlüsselung durch Angriff
⚡ Naturereignisse: Rechenzentrumsausfall

Ohne Backup

Datenverlust = Alle Nutzer, Credits, Konfigurationen, Usage-Historie verloren!

Was wird gesichert?

SQLite-Datenbank

Die Hauptdatenbank enthält:

✅ Nutzer & API-Keys
✅ Projekte & Budgets
✅ Provider & Routen
✅ Pricing-Konfiguration
✅ Usage-Logs (Metadaten)
✅ Credit-Historie
✅ Allowance-Einstellungen
✅ Common Pool Stände

Datei-Standort (typisch):

/opt/bud-e/school-bud-e-middleware/data/admin_bude.db

Kleine Datei

Die Datenbank ist meist sehr klein (wenige MB bis ~100 MB), da keine Gesprächsinhalte gespeichert werden.

Backup erstellen

Methode 1: Admin-Dashboard (empfohlen)

Öffnen Sie das Admin-Dashboard
Navigieren Sie zu Maintenance
Klicken Sie auf Download Backup
SQLite-Datei wird heruntergeladen

Dateiname-Format:

admin_bude_backup_2025-10-11_14-30-15.db

Methode 2: Manueller Download

Per SSH auf dem Server:

bash

# Als backup-User oder root
cd /opt/bud-e/school-bud-e-middleware/data/

# Datenbank kopieren (während Server läuft)
sqlite3 admin_bude.db ".backup backup_$(date +%Y%m%d_%H%M%S).db"

# Herunterladen (von Ihrem lokalen PC)
scp ubuntu@ihr-server:/opt/bud-e/school-bud-e-middleware/data/backup_*.db ~/backups/

Methode 3: Automatisiertes Backup-Script

Erstellen Sie ein Cron-Script für tägliche Backups:

bash

#!/bin/bash
# Datei: /opt/bud-e/backup.sh

BACKUP_DIR="/opt/bud-e/backups"
DB_PATH="/opt/bud-e/school-bud-e-middleware/data/admin_bude.db"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/admin_bude_$DATE.db"

# Verzeichnis erstellen falls nicht vorhanden
mkdir -p "$BACKUP_DIR"

# Backup erstellen
sqlite3 "$DB_PATH" ".backup '$BACKUP_FILE'"

# Komprimieren
gzip "$BACKUP_FILE"

# Alte Backups löschen (behalte letzte 30 Tage)
find "$BACKUP_DIR" -name "admin_bude_*.db.gz" -mtime +30 -delete

echo "Backup erstellt: ${BACKUP_FILE}.gz"

Ausführbar machen:

bash

chmod +x /opt/bud-e/backup.sh

Crontab einrichten (täglich um 3 Uhr):

bash

sudo crontab -e

Fügen Sie hinzu:

0 3 * * * /opt/bud-e/backup.sh >> /var/log/admin-bude-backup.log 2>&1

Backup-Speicherung

Lokal (kurzfristig)

Vorteile:

Schnell verfügbar
Keine Internet-Abhängigkeit

Nachteile:

Bei Server-Ausfall verloren
Keine Schutz vor Ransomware

Empfehlung: Nur als temporärer Zwischenspeicher (max. 7 Tage)

Extern (langfristig)

Option 1: Cloud-Storage

AWS S3:

bash

# Installation aws-cli
sudo apt install awscli

# Backup hochladen
aws s3 cp backup_20251011.db.gz s3://ihr-bucket/backups/

# Mit Verschlüsselung
aws s3 cp backup_20251011.db.gz s3://ihr-bucket/backups/ \
  --server-side-encryption AES256

Google Cloud Storage:

bash

# Installation gcloud
# (siehe: https://cloud.google.com/sdk/docs/install)

# Backup hochladen
gsutil cp backup_20251011.db.gz gs://ihr-bucket/backups/

Backblaze B2 (kostengünstig):

bash

# Installation b2 CLI
pip install b2

# Konfiguration
b2 authorize-account

# Upload
b2 upload-file ihr-bucket backup_20251011.db.gz backups/backup_20251011.db.gz

Option 2: SFTP/FTP

Auf separatem Server:

bash

# SFTP Upload
scp backup_20251011.db.gz backup@backup-server:/backups/admin-bude/

Option 3: Lokale externe Festplatte

Für kleinere Setups:

bash

# USB-Festplatte mounten
sudo mount /dev/sdb1 /mnt/backup

# Backup kopieren
cp backup_20251011.db.gz /mnt/backup/admin-bude/

# Unmount
sudo umount /mnt/backup

Backup-Verschlüsselung

Mit GPG verschlüsseln:

bash

# Schlüssel generieren (einmalig)
gpg --full-generate-key

# Backup verschlüsseln
gpg --encrypt --recipient admin@schule.de backup_20251011.db.gz

# Ergebnis: backup_20251011.db.gz.gpg

Entschlüsseln:

bash

gpg --decrypt backup_20251011.db.gz.gpg > backup_20251011.db.gz

Backup-Strategie

3-2-1-Regel

Die bewährte Backup-Regel:

3 Kopien der Daten
2 verschiedene Speichermedien
1 Kopie extern (off-site)

Beispiel:

Kopie 1: Produktiv-Server (/opt/bud-e/data/)
Kopie 2: Lokales Backup-Verzeichnis (/opt/bud-e/backups/)
Kopie 3: Cloud-Storage (AWS S3 / Google Cloud Storage)

Aufbewahrungsfristen

Empfehlung:

Typ	Aufbewahrung	Zweck
Täglich	7 Tage	Schnelle Wiederherstellung bei akuten Problemen
Wöchentlich	4 Wochen	Monatliche Kontrolle
Monatlich	12 Monate	Jahresabschluss, Audits
Jährlich	3-7 Jahre	Rechtliche Anforderungen

Backup-Rotation:

backups/
├── daily/
│   ├── 2025-10-11.db.gz
│   ├── 2025-10-10.db.gz
│   ├── ... (7 Tage)
│   └── 2025-10-05.db.gz
├── weekly/
│   ├── 2025-W41.db.gz
│   ├── ... (4 Wochen)
│   └── 2025-W38.db.gz
├── monthly/
│   ├── 2025-10.db.gz
│   ├── ... (12 Monate)
│   └── 2024-11.db.gz
└── yearly/
    ├── 2025.db.gz
    └── 2024.db.gz

Wiederherstellung

Vorbereitung

Warnung

Wiederherstellung überschreibt die aktuelle Datenbank! Erstellen Sie vorher ein Backup des aktuellen Zustands.

Methode 1: Admin-Dashboard

Öffnen Sie das Admin-Dashboard
Navigieren Sie zu Maintenance
Klicken Sie auf Restore Backup
Wählen Sie die Backup-Datei
Bestätigen Sie die Wiederherstellung
Server wird automatisch neu gestartet

Methode 2: Manuelle Wiederherstellung

Schritt 1: Server stoppen

bash

sudo systemctl stop admin-bude.service

Schritt 2: Aktuellen Stand sichern

bash

cd /opt/bud-e/school-bud-e-middleware/data/
cp admin_bude.db admin_bude.db.before-restore-$(date +%Y%m%d)

Schritt 3: Backup hochladen

bash

# Lokal → Server
scp backup_20251011.db.gz ubuntu@ihr-server:/tmp/

# Auf Server entpacken
ssh ubuntu@ihr-server
cd /tmp
gunzip backup_20251011.db.gz

Schritt 4: Backup wiederherstellen

bash

sudo cp /tmp/backup_20251011.db /opt/bud-e/school-bud-e-middleware/data/admin_bude.db
sudo chown ubuntu:ubuntu /opt/bud-e/school-bud-e-middleware/data/admin_bude.db

Schritt 5: Datenbank-Integrität prüfen

bash

sqlite3 /opt/bud-e/school-bud-e-middleware/data/admin_bude.db "PRAGMA integrity_check;"
# Erwartete Ausgabe: ok

Schritt 6: Server starten

bash

sudo systemctl start admin-bude.service
sudo systemctl status admin-bude.service

Schritt 7: Funktionalität testen

bash

# Im Browser: http://ihr-server:8000/admin
# - Login testen
# - Nutzer-Liste prüfen
# - Test-Anfrage senden

Wiederherstellung-Checkliste

✅ Backup-Datei vorhanden und gültig
✅ Server gestoppt
✅ Aktueller Stand gesichert
✅ Backup-Datei hochgeladen
✅ Datenbank ersetzt
✅ Berechtigungen korrekt
✅ Integrität geprüft
✅ Server gestartet
✅ Admin-Login erfolgreich
✅ Test-Anfrage erfolgreich

Test-Wiederherstellung

Regelmäßig testen!

Backups sind nutzlos, wenn die Wiederherstellung nicht funktioniert. Testen Sie mindestens quartalsweise!

Test-Szenario

Separaten Test-Server aufsetzen
- Kleine VM (z.B. CX11 bei Hetzner)
- Identische Software-Version
Backup wiederherstellen
- Backup hochladen
- Restore durchführen
Funktionalität prüfen
- Admin-Login
- Nutzer-Liste vollständig?
- Provider-Konfiguration vorhanden?
- Test-Anfrage senden

Dokumentieren

markdown

# Restore-Test 2025-10-11

Backup: backup_20251010.db.gz
Server: test-server.example.com
Status: ✅ Erfolgreich
Dauer: 15 Minuten
Probleme: Keine

Monitoring & Alarme

Backup-Monitoring

Prüfen Sie:

Letztes Backup-Datum
Backup-Dateigröße (Plausibilität)
Verfügbarkeit externer Backups
Speicherplatz auf Backup-Storage

Alarme einrichten:

⚠️ Warnung: Letztes Backup > 24 Stunden alt
🚨 Kritisch: Letztes Backup > 48 Stunden alt
🚨 Kritisch: Backup-Speicher > 90% voll

Automatisierte Prüfung

Backup-Verify-Script:

bash

#!/bin/bash
# backup-verify.sh

BACKUP_FILE="$1"

# Größe prüfen
SIZE=$(stat -f%z "$BACKUP_FILE" 2>/dev/null || stat -c%s "$BACKUP_FILE")
if [ "$SIZE" -lt 10000 ]; then
  echo "❌ Backup zu klein: $SIZE Bytes"
  exit 1
fi

# SQLite-Integrität prüfen
sqlite3 "$BACKUP_FILE" "PRAGMA integrity_check;" | grep -q "ok"
if [ $? -eq 0 ]; then
  echo "✅ Backup gültig"
  exit 0
else
  echo "❌ Backup korrupt"
  exit 1
fi

Verwenden:

bash

chmod +x backup-verify.sh
./backup-verify.sh backup_20251011.db

Disaster Recovery Plan

Szenarien

Szenario 1: Server-Festplatte defekt

Recovery:

Neue Festplatte einbauen / neue VM erstellen
Betriebssystem neu installieren (Ubuntu)
Admin Bud-E neu installieren (siehe Installation)
Letztes Backup wiederherstellen
Server konfigurieren & starten

RTO (Recovery Time Objective): 2-4 Stunden RPO (Recovery Point Objective): 1 Tag (bei täglichen Backups)

Szenario 2: Datenbank-Korruption

Recovery:

Server stoppen
Korrupte DB sichern (für Analyse)
Letztes Backup wiederherstellen
Integrität prüfen
Server starten

RTO: 30 Minuten RPO: 1 Tag

Szenario 3: Versehentliches Löschen

Recovery:

Identifizieren, was gelöscht wurde
Passendes Backup finden (vor Löschung)
Selektive Wiederherstellung (nur betroffene Daten)
Oder: Vollständige Wiederherstellung

RTO: 1-2 Stunden RPO: Abhängig von Löschzeitpunkt

Szenario 4: Ransomware

Recovery:

Server sofort vom Netz trennen
Malware entfernen / Server neu aufsetzen
Backup von vor der Infektion wiederherstellen
Alle Passwörter ändern
Sicherheitslücken schließen

RTO: 4-8 Stunden RPO: Variabel (Infektionszeitpunkt abhängig)

Best Practices

1. Automatisierung

✅ Tägliche automatische Backups
✅ Automatischer Upload zu externem Storage
✅ Automatische Verifikation
✅ Automatische Rotation (alte Backups löschen)

2. Verschlüsselung

✅ Backups verschlüsseln (GPG, AES-256)
✅ Schlüssel sicher aufbewahren (nicht auf demselben Server!)
✅ Test-Entschlüsselung regelmäßig durchführen

3. Dokumentation

✅ Backup-Prozess dokumentieren
✅ Restore-Anleitung erstellen
✅ Ansprechpartner definieren
✅ Disaster-Recovery-Plan

4. Zugriffskontrolle

✅ Backup-Verzeichnis schützen (chmod 700)
✅ Nur Admins haben Zugriff
✅ Audit-Log für Backup-Zugriffe

5. Regelmäßige Tests

✅ Quartalsweise Test-Wiederherstellung
✅ Dokumentation der Tests
✅ Lessons Learned nach jedem Test

Nächste Schritte

Maintenance - Regelmäßige Wartungsaufgaben
Privacy - Datenschutz für Backups
FAQ - Häufige Backup-Fragen

Backups & Wiederherstellung ​

Warum Backups wichtig sind ​

Was wird gesichert? ​

SQLite-Datenbank ​

Backup erstellen ​

Methode 1: Admin-Dashboard (empfohlen) ​

Methode 2: Manueller Download ​

Methode 3: Automatisiertes Backup-Script ​

Backup-Speicherung ​

Lokal (kurzfristig) ​

Extern (langfristig) ​

Option 1: Cloud-Storage ​

Option 2: SFTP/FTP ​

Option 3: Lokale externe Festplatte ​

Backup-Verschlüsselung ​

Backup-Strategie ​

3-2-1-Regel ​

Aufbewahrungsfristen ​

Wiederherstellung ​

Vorbereitung ​

Methode 1: Admin-Dashboard ​

Methode 2: Manuelle Wiederherstellung ​

Wiederherstellung-Checkliste ​

Test-Wiederherstellung ​

Test-Szenario ​

Monitoring & Alarme ​

Backup-Monitoring ​

Automatisierte Prüfung ​

Disaster Recovery Plan ​

Szenarien ​

Szenario 1: Server-Festplatte defekt ​

Szenario 2: Datenbank-Korruption ​

Szenario 3: Versehentliches Löschen ​

Szenario 4: Ransomware ​

Best Practices ​

1. Automatisierung ​

2. Verschlüsselung ​

3. Dokumentation ​

4. Zugriffskontrolle ​

5. Regelmäßige Tests ​

Nächste Schritte ​

Backups & Wiederherstellung

Warum Backups wichtig sind

Was wird gesichert?

SQLite-Datenbank

Backup erstellen

Methode 1: Admin-Dashboard (empfohlen)

Methode 2: Manueller Download

Methode 3: Automatisiertes Backup-Script

Backup-Speicherung

Lokal (kurzfristig)

Extern (langfristig)

Option 1: Cloud-Storage

Option 2: SFTP/FTP

Option 3: Lokale externe Festplatte

Backup-Verschlüsselung

Backup-Strategie

3-2-1-Regel

Aufbewahrungsfristen

Wiederherstellung

Vorbereitung

Methode 1: Admin-Dashboard

Methode 2: Manuelle Wiederherstellung

Wiederherstellung-Checkliste

Test-Wiederherstellung

Test-Szenario

Monitoring & Alarme

Backup-Monitoring

Automatisierte Prüfung

Disaster Recovery Plan

Szenarien

Szenario 1: Server-Festplatte defekt

Szenario 2: Datenbank-Korruption

Szenario 3: Versehentliches Löschen

Szenario 4: Ransomware

Best Practices

1. Automatisierung

2. Verschlüsselung

3. Dokumentation

4. Zugriffskontrolle

5. Regelmäßige Tests

Nächste Schritte