← Zurück zu Backup & Cronjobs
✅

Backup Best Practices

Ein Backup ist nur so gut wie seine Umsetzung. Diese Best Practices machen den Unterschied.

⏱️ 20 Minuten 📊 Mittel
🔐 Schritt 0: Verschlüsselung +

Jedes Backup sollte verschlüsselt sein - besonders wenn es den eigenen Server verlässt.

🚨

Unverschlüsselte Backups sind ein Risiko

Wenn jemand Zugriff auf dein Offsite-Backup bekommt, hat er Zugriff auf ALLE deine Daten. Verschlüsselung ist nicht optional.

Verschlüsselung mit restic:

bash 
# Repository initialisieren (Passwort wird abgefragt)
restic init -r /mnt/backup/restic-repo

# Mit Passwort-Datei (für Cronjobs)
echo "mein-sicheres-passwort" > /root/.restic-password
chmod 600 /root/.restic-password
export RESTIC_PASSWORD_FILE=/root/.restic-password

Verschlüsselung mit borg:

bash 
# Repository mit Verschlüsselung initialisieren
borg init --encryption=repokey /mnt/backup/borg-repo

# Key exportieren und sicher aufbewahren!
borg key export /mnt/backup/borg-repo > borg-key-backup.txt
⚠️

Passwort sicher aufbewahren!

Ohne Passwort/Key sind verschlüsselte Backups wertlos. Speichere das Passwort an einem sicheren Ort AUSSERHALB des Backup-Systems (z.B. Passwort-Manager, Safe).
📅 Schritt 1: Retention Policy +

Wie lange bewahrst du Backups auf? Eine durchdachte Retention Policy spart Speicher und erfüllt Anforderungen.

Empfohlene Retention (GFS-Schema):

  • 7 tägliche - letzte Woche komplett
  • 4 wöchentliche - letzter Monat (Sonntage)
  • 12 monatliche - letztes Jahr (Monatserste)
  • Unbegrenzt jährliche - für Compliance (optional)

restic forget mit Policy:

bash 
# Alte Snapshots nach Policy löschen
restic forget \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 12 \
    --keep-yearly 5 \
    --prune

# --prune löscht die nicht mehr referenzierten Daten

borg prune:

bash 
borg prune --list \
    --keep-daily=7 \
    --keep-weekly=4 \
    --keep-monthly=12 \
    /mnt/backup/borg-repo
💡

Gesetzliche Aufbewahrungsfristen

In Deutschland: Buchhaltungsunterlagen 10 Jahre, Geschäftsbriefe 6 Jahre. Prüfe, welche Fristen für dich gelten.
🧪 Schritt 2: Restore-Tests +
🚨

Ein ungetestetes Backup ist kein Backup

Regelmäßige Restore-Tests sind PFLICHT. Mindestens vierteljährlich, besser monatlich.

Was du testen solltest:

  • Kannst du das Backup überhaupt öffnen? (Passwort noch bekannt?)
  • Sind alle erwarteten Dateien vorhanden?
  • Lässt sich eine Datenbank aus dem Dump wiederherstellen?
  • Funktioniert die Anwendung nach dem Restore?
  • Wie lange dauert der Restore? (Ist das akzeptabel?)

Restore-Test mit restic:

bash 
# Snapshot-Liste anzeigen
restic snapshots

# Einzelne Datei wiederherstellen
restic restore latest --target /tmp/restore-test --include "/etc/nginx"

# Prüfen ob Dateien korrekt sind
diff -r /etc/nginx /tmp/restore-test/etc/nginx

Datenbank-Restore testen:

bash 
# PostgreSQL Dump wiederherstellen (in Test-DB)
createdb test_restore
pg_restore -d test_restore /tmp/restore-test/backup.sql

# Prüfen ob Daten vorhanden
psql test_restore -c "SELECT COUNT(*) FROM wichtige_tabelle;"

# Test-DB wieder löschen
dropdb test_restore
✅

Restore-Test dokumentieren

Halte fest: Datum, getestete Daten, Dauer, Ergebnis. Bei Audits ist das Gold wert.
📋 Schritt 3: Backup-Dokumentation +

Was du dokumentieren solltest:

Backup-Dokumentation Checkliste:

  • ☐ Was wird gesichert? (Verzeichnisse, Datenbanken, VMs)
  • ☐ Wohin wird gesichert? (Pfade, Server, Credentials)
  • ☐ Wann laufen die Backups? (Zeitplan)
  • ☐ Wie lange werden Backups aufbewahrt? (Retention)
  • ☐ Wie wird wiederhergestellt? (Schritt-für-Schritt)
  • ☐ Wer ist verantwortlich?
  • ☐ Wo liegt das Passwort/der Key?

Beispiel-Dokumentation:

bash 
# Backup-Dokumentation Server: web01

## Gesicherte Daten
- /etc (Konfiguration)
- /home (Benutzerdaten)
- /var/www (Webseiten)
- PostgreSQL Dump (alle Datenbanken)

## Backup-Ziele
1. Lokal: /mnt/backup (NAS via NFS)
2. Offsite: Hetzner Storage Box (sftp://u123456@u123456.your-storagebox.de)

## Zeitplan
- Täglich 03:00: Inkrementelles Backup
- Sonntag 04:00: Retention Cleanup

## Wiederherstellung
1. restic mount /mnt/backup /mnt/restore
2. Dateien kopieren
3. restic umount /mnt/restore

## Passwort
Passwort-Manager: "Backup/web01-restic"
Notfall-Kopie: Safe im Büro

## Letzter Restore-Test
Datum: 2026-01-10
Ergebnis: OK, 15 Minuten für Full Restore
🔔 Schritt 4: Monitoring & Alerts +

Backups müssen überwacht werden. Stille Fehler sind die gefährlichsten.

Was überwachen:

  • Backup gelaufen? - Exit-Code prüfen
  • Backup-Größe plausibel? - Zu klein = Fehler
  • Speicherplatz ausreichend? - Rechtzeitig warnen
  • Letztes Backup wie alt? - Maximal 24h (bei täglichen)

Healthcheck-Script:

bash 
#!/bin/bash
# /usr/local/bin/backup-healthcheck.sh

REPO="/mnt/backup/restic-repo"
MAX_AGE_HOURS=26  # Etwas Puffer über 24h

# Letzten Snapshot prüfen
LAST_BACKUP=$(restic snapshots --json | jq -r '.[-1].time')
LAST_BACKUP_TS=$(date -d "$LAST_BACKUP" +%s)
NOW_TS=$(date +%s)
AGE_HOURS=$(( (NOW_TS - LAST_BACKUP_TS) / 3600 ))

if [ $AGE_HOURS -gt $MAX_AGE_HOURS ]; then
    echo "CRITICAL: Letztes Backup ist $AGE_HOURS Stunden alt!"
    # Alert senden
    curl -X POST "https://ntfy.sh/dein-channel" \
         -H "Priority: urgent" \
         -d "Backup überfällig: $AGE_HOURS Stunden alt"
    exit 1
fi

echo "OK: Letztes Backup vor $AGE_HOURS Stunden"
exit 0
💡

Uptime Kuma Integration

Lass den Healthcheck-Script einen "Push Monitor" in Uptime Kuma pingen. So siehst du auf einen Blick den Status aller Backups.
🛡️ Schritt 5: Sicherheits-Checkliste +

Backup Security Checkliste:

  • ✓ Verschlüsselung: Backups sind verschlüsselt (AES-256)
  • ✓ Passwort-Sicherheit: Starkes Passwort, sicher aufbewahrt
  • ✓ Zugriffskontrolle: Nur root kann Backup-Configs lesen
  • ✓ Transport: Übertragung via SSH/SFTP (nicht FTP!)
  • ✓ Immutability: Offsite-Backups nicht vom Quellserver löschbar
  • ✓ Isolation: Ransomware kann Backup nicht erreichen
⚠️

Ransomware-Schutz

Wenn der Server kompromittiert wird, darf der Angreifer nicht die Backups löschen können. Lösung: Offsite-Backup mit separaten Credentials, die nicht auf dem Server liegen. Oder "append-only" Modus bei Storage-Anbietern.

Häufige Fragen

Wie groß sollte mein Backup-Speicher sein? ▸
Faustregel: Mindestens 3x die Größe der Quelldaten. Mit Deduplizierung (restic, borg) oft weniger nötig. Plane 20% Reserve ein.
Soll ich Datenbanken per Dump oder Dateisystem sichern? ▸
Immer Dump (pg_dump, mysqldump)! Dateisystem-Backups einer laufenden DB sind inkonsistent und oft unbrauchbar. Ausnahme: Snapshots bei gestoppter DB.
Wie schütze ich mich vor Ransomware? ▸
1) Offsite-Backup mit separaten Credentials, 2) Append-Only Modus wo möglich, 3) Air-Gapped Backup (USB-Platte, die nur bei Backup angeschlossen ist), 4) Versionierte Backups (um auf Stand vor Infektion zurück zu können).
← Zurück: Cronjobs Weiter: Disaster Recovery →