Backupstrategie – Leitfaden für eine belastbare Datensicherung ✅

Ziel:

Eine praxiserprobte, einfach umsetzbare Strategie, die Ausfälle (Hardware, Ransomware, Bedienfehler), versehentliche Löschungen und Katastrophen (Brand, Diebstahl) abfedert – und Wiederherstellung planbar macht.

—

* RPO (Recovery Point Objective): Wie alt dürfen Daten im schlimmsten Fall sein? (z. B. max. 24 h → tägliche Sicherung) * RTO (Recovery Time Objective): Wie schnell muss es wieder laufen? (z. B. 4 h → schnelle Medien/Automatisierung nötig) * Scope: Welche Systeme/Dienste/Daten sind drin? (Server, VMs, Docker-Volumes, Datenbanken, Konfigs, Zertifikate, Endgeräte, SaaS)

—

* 3 Kopien: Produktiv + 2 Backups * 2 verschiedene Medien/Technologien (z. B. Disk/NAS und Cloud/Tape) * 1 Kopie außer Haus (Offsite) * 1 Kopie offline/immutable (z. B. S3 Object Lock, WORM-Tape) * 0 Fehler nach regelmäßiger Verifikation (Prüfsummen, Restore-Tests)

—

—

* Vollbackup (Full): komplette Kopie; Basis für lange Retention (z. B. wöchentlich/monatlich). * Inkrementell (Inc): nur Änderungen seit dem letzten Backup (schnell, platzsparend). * Differenziell (Diff): Änderungen seit dem letzten Vollbackup (Kompromiss). * Synthetic Full: Vollbackup, das aus früheren Voll+Inkrementen zusammengebaut wird (entlastet Quelle).

Praxis: Täglich inkrementell, wöchentlich synthetisches Full, monatlich „echtes“ Full als Archiv.

—

—

* Disk/NAS: schnell für tägliche Restores; RAID ≠ Backup. * Cloud/Object Storage: S3-kompatibel mit Object Lock (immutability, Legal Hold). * Tape (LTO): günstig für lange Archivierung; echte Offline-Air-Gap. * Snapshots (ZFS/Btrfs/LVM/Hypervisor): super Ergänzung, aber kein Ersatz für externes Backup.

—

* Datenbanken: konsistente Dumps oder Hot-Backup-Mechanismen (z. B. `mysqldump –single-transaction`, `pg_dump`, `xtrabackup`). * VMs: applikationskonsistente Snapshots (VSS bei Windows-Gästen). * Dateiserver: Snapshots + Backup; offene Dateien via VSS oder LVM-Snapshot sichern. * Container/Docker: Volumes sichern (nicht nur Images), außerdem Compose-Dateien, `.env`, Secrets, TLS-Zertifikate, Datenbanken im Container per Dump sichern.

—

* Transport & Ruhe: Ende-zu-Ende verschlüsseln (z. B. restic/borg, Key Management). * Schlüssel/Passphrasen: separat und offline hinterlegen (Tresor, Sealed Envelope). * Trennung: Backup-Server/Repo mit eigenen Admin-Konten, MFA, Netzwerksegmentierung, kein Domain-Admin. * Immutable/WORM: aktivieren, um Löschungen/Manipulation zu verhindern.

—

* Monitoring/Alarme: tägliche Report-Mails/Webhook (z. B. Healthchecks), fehlgeschlagene Jobs = Pager. * Integrität: `restic check`, `borg check`, Prüfsummen. * Restore-Drills: Mind. quartalsweise Testwiederherstellung (Datei, komplette VM, Datenbank). * RTO/RPO-Beweis: Dauer messen & dokumentieren.

—

* Backup-Policy (Was, wie oft, wohin, wie lange, wer darf löschen?). * Runbook für Notfälle (Wer ruft wen an? Reihenfolge der Restores?). * Change-Mgmt: neue Systeme automatisch ins Backup aufnehmen. * Revision/DSGVO: Datenklassen, Löschkonzepte, Auftragsverarbeitung, Verschlüsselung.

—

# 1) Repo initialisieren (Beispiel: S3-kompatibles Ziel)

export RESTIC\_REPOSITORY="s3:[https://s3.example.com/bucket](https://s3.example.com/bucket)"
export RESTIC\_PASSWORD="STRONG-PASSPHRASE"
export AWS\_ACCESS\_KEY\_ID="AKIA..."
export AWS\_SECRET\_ACCESS\_KEY="..."

restic init

# 2) Täglich: inkrementelles Backup inkl. wichtiger Verzeichnisse

restic backup 
/etc /var/backups /home /opt/stacks 
--tag daily

# 3) Retention (Beispiel GFS)

restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

# 4) Integritätscheck (z. B. wöchentlich)

restic check 

export BORG\_REPO="ssh://backup\@backuphost:/repositories/node1"
export BORG\_PASSPHRASE="STRONG-PASSPHRASE"

borg init --encryption=repokey-blake2 "\$BORG\_REPO"
borg create --stats --progress "\$BORG\_REPO"::"{now:%Y-%m-%d\_%H-%M}" 
/etc /var/backups /home /opt/stacks
borg prune -v --list "\$BORG\_REPO" --keep-daily=14 --keep-weekly=8 --keep-monthly=12
borg check -v "\$BORG\_REPO" 

# MariaDB/MySQL (konsistent via single-transaction)

mysqldump --single-transaction --routines --triggers --databases appdb 
| gzip > /var/backups/mysql/appdb\_\$(date +%F).sql.gz

# PostgreSQL

pg\_dump -Fc appdb > /var/backups/pgsql/appdb\_\$(date +%F).dump 

# Named Volume als Tar sichern

docker run --rm 
-v meine\_daten:/src\:ro 
-v /var/backups/docker:/dst 
alpine sh -c 'cd /src && tar czf /dst/meine\_daten\_\$(date +%F).tgz .'

# Compose & .env & Labels sichern (Infrastructure as Code)

cp -a /opt/stacks/\* /var/backups/stacks/\$(date +%F)/ 

# Proxmox: vzdump (vollständig, konsistent)

vzdump 100 --mode snapshot --compress zstd --storage backup-nfs --mailnotification always

# Windows/Hyper-V: Bare-Metal/Volumes (als Admin PowerShell)

wbadmin start backup -backupTarget\:E: -include\:C: -allCritical -quiet 

—

—

== Incident: Datenverlust/Ransomware ==
 
Zeitpunkt: ______   Ticket: ______   Melder: ______

1. Lage bewerten: Welche Systeme betroffen? RPO/RTO?
2. Isolieren: Netzwerkzugriff einschränken, Admin-Konten prüfen.
3. Quelle wählen: Jüngstes sauberes Backup (Immutable bevorzugt).
4. Restore-Reihenfolge:
   a) Verzeichnis-/Datei-Restore für schnelle Wiederanlaufpunkte
   b) Datenbanken + Applikationen (abhängigkeitsbasiert)
   c) Dienste/VMs in Startreihenfolge
5. Validierung: Smoke-Tests, Integrität, Anwendertests.
6. Dokumentation: Dauer (RTO), Datenalter (RPO), Lessons Learned.

—

▢ RPO/RTO pro System festlegen und dokumentieren
▢ 3-2-1-1-0 konkret planen (Ziele, Medien, Offsite, Immutable)
▢ Backup-Software wählen (restic/borg/veeam/Proxmox/…)
▢ Sensitive Daten verschlüsseln; Keys offline sichern
▢ Automatisierung (cron/systemd, Jobs, Webhooks/Alarme)
▢ Onboarding-Prozess für neue Systeme/Container/DBs/
▢ Restore-Test (Datei, VM, DB) terminieren & protokollieren
▢ Retention (täglich/wöchentlich/monatlich/jährlich) umsetzen
▢ Rechte & Trennung (separate Admins, MFA, Netzsegmente)
▢ Compliance (DSGVO/GoBD) prüfen: Speicherorte, Löschkonzept

—

* Nur Snapshots ≠ Backup → Immer externes Ziel einplanen. * Keine Offsite/Immutable-Kopie → Ransomware-Risiko massiv. * DBs „kalt“ gesichert → inkonsistent → applikations-aware sichern. * Keine Restore-Tests → im Ernstfall Überraschungen. * Schlüssel verloren → verschlüsselte Backups unbrauchbar → Key-Runbook & sichere Offline-Ablage. * Alles in einem VLAN/AD → Angreifer löscht Backups → Trennung, eigene Accounts, WORM. * Unklare Retention → Speicher läuft voll oder Löschung zu früh. * SaaS ohne Backup → Microsoft/Google sind keine Backuplösungen → Drittanbieter/Export einplanen.

—

* Täglich: `restic backup` (Dateien, Docker-Volumes), 14 Tage auf NAS * Wöchentlich: Synthetic Full → NAS und S3 (Object Lock 30 Tage) * Monatlich: Vollbackup als Archiv (12 Monate) * Quartalsweise: Restore-Test (VM + DB + Datei) * Monitoring: Healthcheck-Ping + E-Mail bei Fehlern * Sicherheit: eigener Backup-User, kein Domänen-Admin, MFA fürs Offsite

—

= Backup Policy =

Scope: Alle produktiven Server, VMs, Container-Volumes, Datenbanken, Konfigurationen, Zertifikate.
RPO/RTO: Kritisch (RPO 4h / RTO 4h), Wichtig (RPO 24h / RTO 24h), Standard (RPO 48h / RTO 72h).
Regel: 3-2-1-1-0 (immutable/offline Pflicht für kritisch & wichtig).
Zeitplan: daily inc, weekly full/synth, monthly full (Archiv).
Retention: Daily 14, Weekly 8, Monthly 12, Yearly 7 (Compliance abhängig).
Sicherheit: Verschlüsselung E2E; Keys offline, Zugriff nur via MFA; getrennte Admin-Konten.
Verifikation: Tägliche Job-Reports, wöchentlicher Check, quartalsweise Restore-Drill.
Änderungen: Neue Systeme binnen 48h ins Backup aufnehmen, Offboarding inkl. sicheres Löschen.
Verantwortung: Betriebsverantwortlicher \_\_\_\_\_\_; Stellvertretung \_\_\_\_\_\_. 

—

—