Backup-Strategien, die funktionieren: 3-2-1, Borg, Veeam und der Restore-Test

2018, irgendein Dienstag. Der Kunde ruft an. "Wir haben einen Ransomware-Vorfall." Alle VMs verschlüsselt. Die Backups auch. Das letzte Offline-Backup: drei Wochen alt. Von einem Jahr E-Mail-Archiv und Finanzdaten blieb das, was auf einem externen USB-Laufwerk im Tresor lag — von dem keiner mehr wusste, ob es noch lesbar war.

Backup ist der unbeliebteste Job in der IT. Keiner sieht, ob es läuft. Aber jeder sieht, wenn es nicht läuft.

3-2-1: Die Regel, und warum sie 2026 nicht mehr reicht

Die klassische 3-2-1-Regel: drei Kopien deiner Daten, auf zwei verschiedenen Medien, eine Kopie off-site. Das war 2005 Stand der Technik. 2026 reicht das nicht mehr, weil "off-site" heute "in der Cloud" heißt — und Cloud-Backups haben ihre eigenen Fallstricke.

Ich arbeite mit 3-2-1-1: drei Kopien, zwei Medien, eine off-site, eine immutable. Immutable heißt: Das Backup kann nicht gelöscht oder verändert werden, auch nicht von dem Admin-Account, der es geschrieben hat. Bei Borg ist das mit borg serve --append-only realisierbar. Bei Veeam mit einem Linux Hardened Repository. Bei AWS S3 mit Object Lock im Compliance-Mode.

Der Grund ist simpel: Wenn ein Angreifer deine Admin-Creds hat — und bei einem Ransomware-Vorfall hat er die oft — dann löscht er deine Backups zuerst. Immutable Storage verhindert das. Der Angreifer müsste warten, bis die Retention abläuft, und das sind bei mir mindestens 30 Tage.

BorgBackup: Mein täglicher Begleiter

Borg ist ein deduplizierendes, komprimierendes Backup-Tool. Es läuft über SSH, braucht keinen Agent auf dem Zielsystem, und die Repos sind verschlüsselt. Ich sichere damit seit 2019 alle meine Linux-Server.

Ein typisches Setup sieht so aus:

# Initialisierung (einmal pro Repo)
borg init --encryption=repokey-blake2 borg@backup-server:/backup/server01

# Tägliches Backup
borg create --stats --progress \
  --compression lz4 \
  borg@backup-server:/backup/server01::'{hostname}-{now:%Y-%m-%d_%H:%M}' \
  /etc /home /var/lib/docker/volumes /srv

# Alte Backups löschen (Behalte 7 tägliche, 4 wöchentliche, 6 monatliche)
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 \
  borg@backup-server:/backup/server01

Was Borg brutal gut macht: Deduplizierung. 30 tägliche Backups von einem Server mit 100 GB Daten brauchen bei mir nicht 3 TB, sondern etwa 115 GB. Borg findet identische Blöcke über Dateigrenzen hinweg und speichert sie nur einmal. lz4-Kompression spart zusätzlich 30-40 %, kostet aber kaum CPU.

Der größte Fehler, den ich mit Borg gemacht habe: Kein borg check im Cronjob. Nach 18 Monaten waren einige Chunks im Repo korrupt — ein defekter RAM-Riegel auf dem Backup-Server. Borg hat das beim Lesen gemerkt und abgebrochen. Reparieren konnte ich nichts mehr. Seitdem läuft einmal pro Woche:

borg check --verify-data borg@backup-server:/backup/server01

Das liest das gesamte Repo einmal durch und prüft jeden Chunk gegen seinen Hash. Dauert auf einem 500-GB-Repo etwa 4 Stunden. Die Alternative: Zeit und Geld in das Reparieren eines korrupten Backups stecken.

Veeam: Wenn es mehr als nur Dateien sein müssen

Für Windows-Server und VMware/Hyper-V gibt es keine Alternative zu Veeam. Der Veeam-Agent für Linux ist okay, aber Borg ist leichter. Veeam Community Edition ist kostenlos für bis zu 10 Workloads — das reicht für die meisten kleinen Umgebungen.

Veeams Killer-Feature ist Instant Recovery. Du startest eine VM direkt aus dem Backup-Repository, ohne sie vorher komplett wiederherzustellen. Der Hypervisor greift lesend auf das Backup-Storage zu, und sobald die VM läuft, migriert Veeam die Daten im Hintergrund (Storage vMotion/Quick Migration) auf den Produktiv-Storage. Ausfallzeit: unter zwei Minuten.

Was Veeam schlecht macht: Linux-Dateibackups mit dem Agent. Der Agent zieht einen Snapshot, mountet ihn, und kopiert dann Datei für Datei. Keine Deduplizierung auf Blockebene. Für 5 Mio. kleine Dateien (Mailserver, Nextcloud) braucht das ein Vielfaches der Zeit von Borg. Für diesen Use-Case läuft bei mir parallel immer noch Borg.

ZFS Snapshots: Kein Backup, aber der erste Schritt

Snapshots sind keine Backups. Aber sie sind das Erste, was du konfigurieren solltest, bevor du überhaupt über Backups nachdenkst. Ein ZFS-Snapshot friert den Zustand eines Datasets zu einem Zeitpunkt ein. Kein Kopieren, keine Latenz. Er belegt nur den Platz, den geänderte Blöcke seit dem Snapshot neu geschrieben haben.

Mein Standard-Snapshot-Plan mit sanoid:

# /etc/sanoid/sanoid.conf
[data/docker]
    use_template = production
    recursive = yes

[template_production]
    frequently = 0
    hourly = 24
    daily = 30
    monthly = 3
    yearly = 1
    autosnap = yes
    autoprune = yes

Das gibt mir 24 stündliche, 30 tägliche, 3 monatliche und einen jährlichen Snapshot — bei 200 GB Docker-Daten belegen alle Snapshots zusammen aktuell 12 GB, weil sich die meisten Container-Volumes kaum ändern.

Der Vorteil gegenüber Borg: Restore eines einzelnen Snapshots dauert Sekunden. zfs rollback data/docker@2026-09-08_00:00 und die Uhr ist zurückgedreht. Borg müsste erst das gesamte Backup extrahieren.

Der Downloadzeit-Rechner: Wie lange dauert dein Offsite-Backup wirklich?

Das ist der Punkt, den die meisten überschlagen. Ein Full-Backup über WAN ins Rechenzentrum: 500 GB Daten. Deine Internetleitung: 100 Mbit/s symmetrisch. Mit dem bitcalc Downloadzeit-Rechner komme ich auf 11,9 Stunden — theoretisch.

In der Praxis misst du mit iperf3 zwischen Standort A und B. Bei einem Kunden mit "100 Mbit/s"-Leitung kamen am anderen Ende nur 65 Mbit/s an, weil der Uplink-Provider auf der Route überlastet war. Statt 12 Stunden dauerte das erste Full-Backup 18. Und das gilt für jedes Full-Backup, nicht nur das erste.

Meine Lösung: Initial Seeding. Die erste Kopie der Daten auf eine externe Platte, mit dem Auto ins Rechenzentrum. Import am Ziel, dann nur noch inkrementelle Änderungen über WAN. Borg macht das automatisch: borg create auf einer externen Platte, Platte zum Zielserver tragen, Platte mounten, ab da läuft borg create über SSH und überträgt nur noch das Delta.

Der Restore-Test: Das Einzige, was wirklich zählt

Ein Backup, das du nie wiederhergestellt hast, ist kein Backup. Es ist eine Hoffnung. Bei einem Kunden habe ich 2019 ein komplettes Desaster-Recovery-Testszenario durchgeführt: Server aus, neuer Server an, nur die Borg-Repos als Quelle. Ergebnis: 6 Stunden bis alle Dienste wieder liefen. Davon 4 Stunden Daten-Wiederherstellung, 2 Stunden für das, was kein Backup hatte: /etc/fstab-Einträge für NFS-Mounts, Docker-Compose-Files, die jemand per Hand editiert und nie ins Backup-Verzeichnis gelegt hatte.

Meine Lessons Learned aus diesem Test:

1. Dokumentiere die Wiederherstellung. Nicht "irgendwo in der Wiki", sondern ein 20-Zeilen-Shellskript, das den Server von Null aufsetzt. Das Skript selbst liegt im Backup.
2. Teste mindestens quartalsweise. Kein "einmal im Jahr"-Quatsch. Ein Quartal ist die maximale Dauer, die du verkraften kannst, wenn du feststellst, dass Backups seit drei Monaten kaputt sind.
3. Monitoring für Backups. Borg und Veeam schicken Mails bei Erfolg und Misserfolg. Aber ich habe zusätzlich einen "Canary"-Cronjob: Einmal pro Woche wird eine Testdatei gesichert, aus dem Backup extrahiert und mit dem Original verglichen.
4. Backups sind kein Disaster Recovery. Ein DR-Plan sagt dir, in welcher Reihenfolge du was wiederherstellst. DNS zuerst — sonst finden deine Server sich nicht. Dann DHCP, dann Active Directory/SSO, dann Datenbanken, dann Applikationen.

Ransomware: Warum Immutable Backups Pflicht sind

2024 hat ein mittelständisches Unternehmen, das ich kenne, 450.000 € an eine Ransomware-Gruppe gezahlt. Nicht weil sie keine Backups hatten. Sondern weil die Angreifer drei Wochen vor dem eigentlichen Angriff die Backup-Infrastruktur kompromittiert und jeden Tag die frischen Backups gelöscht hatten. Als die Verschlüsselung losging, war das letzte intakte Backup 23 Tage alt.

Drei Schutzschichten, die das verhindern:

1. Pull, nicht Push. Der Backup-Server holt sich die Daten vom Client, nicht umgekehrt. Der Client hat keine Credentials für den Backup-Server. Borg macht das per Default richtig: Der Client pushed zwar, aber mit borg serve --append-only kann er nur neue Daten schreiben, nichts löschen.

2. Air Gap. Mindestens ein Backup-Medium ist physikalisch oder logisch vom Netz getrennt. LTO-Tapes im Tresor, externe Platten im Wechsel (eine immer im Schrank, eine am Server), oder Cloud-Storage mit einem Account, der nur schreiben, nicht löschen kann.

3. Retention-Delay. Dein primäres Backup-Tool hat einen Lösch-Aufschub. Selbst wenn jemand deine Credentials hat und borg prune aufruft, werden die Daten erst nach X Tagen wirklich gelöscht. Bei Borg: borg compact --cleanup-commits läuft nur einmal pro Woche manuell.

Was ich heute auf keinen Fall mehr anders machen würde

Bevor ich Backups einrichte, frage ich drei Dinge:

1. Was ist das RPO (Recovery Point Objective)? Wie viel Datenverlust ist akzeptabel? Buchhaltung: 1 Stunde. Entwicklungs-Wiki: 24 Stunden. Davon hängt ab, ob stündliche oder tägliche Snapshots reichen.

2. Was ist das RTO (Recovery Time Objective)? Wie schnell muss das System wieder laufen? Produktivdatenbank: 15 Minuten. Internes Monitoring: 8 Stunden. Davon hängt ab, ob du Snapshots, Instant Recovery oder Full Restore brauchst.

3. Wer hat Zugriff auf die Backup-Server? Wenn der Domain-Admin auch Backup-Admin ist, kannst du dir den Immutable-Teil sparen — der Angreifer hat alle Schlüssel. Getrennte Accounts, getrennte 2FA-Tokens.

Fazit

Backup ist kein Tool. Backup ist ein Prozess. Borg, Veeam und ZFS sind die Werkzeuge. Entscheidend ist: Du testest die Wiederherstellung regelmäßig, du hast ein off-site Backup, und ein Backup ist immutable. Alles andere ist tambourine.

Und: Ein RAID ist kein Backup. Das wussten wir alle schon. Trotzdem ist bei jedem zweiten Incident, den ich sehe, das RAID die einzige "Backup-Lösung". Zwei Festplattenausfälle gleichzeitig sind selten, aber sie passieren. Genau dann, wenn du sie nicht brauchen kannst.