Backup-Strategie im KMU: 3-2-1(-1-0)-Regel, RPO/RTO und Backup-Fenster planen

Warum “wir machen ja Backups” keine Strategie ist

Fast jedes KMU hat irgendein Backup. Ein NAS, das nachts synct. Ein Cloud-Ordner. Vielleicht sogar ein Bandlaufwerk aus 2015, das noch läuft, weil es nie kaputt gegangen ist. Das Problem zeigt sich nie beim Sichern, sondern beim Wiederherstellen: Der Ordner war leer, das letzte funktionierende Restore lag drei Monate zurück, oder die einzige Kopie lag im selben Serverraum wie das brennende Original.

Eine Backup-Strategie ist kein Tool, sondern eine Antwort auf vier Fragen: Wie viel Datenverlust können wir uns leisten (RPO)? Wie lange dürfen wir stillstehen (RTO)? Wie stellen wir sicher, dass eine Kopie auch dann noch existiert, wenn Ransomware, Feuer oder ein wütender Ex-Mitarbeiter zuschlägt? Und woher wissen wir, dass das Restore tatsächlich funktioniert, bevor wir es im Ernstfall brauchen?

Die 3-2-1-Regel: Herkunft und Kernprinzip

Die Regel stammt ursprünglich aus der Fotografie (Peter Krogh, ca. 2005) und wurde von der IT übernommen, weil sie einfach zu merken und trotzdem robust ist:

• 3 Kopien der Daten insgesamt (das Original plus mindestens zwei Backups)
• 2 verschiedene Speichermedien (z. B. lokale Disk plus Tape, oder NAS plus Cloud-Objektspeicher)
• 1 Kopie offsite, also physisch an einem anderen Standort als das Original

Der Gedanke dahinter: Jedes einzelne Speichermedium hat eine eigene Fehlerklasse. Eine SSD stirbt anders als ein Tape, ein RAID-Verbund schützt nicht vor einem Fehler im Dateisystem, und ein Serverraum-Brand vernichtet alles, was sich im selben Raum befindet — unabhängig vom Medium. Zwei Medientypen plus ein externer Standort decken die drei häufigsten Schadensklassen ab: Hardwareausfall, logische Korruption/Fehlbedienung, physische Zerstörung des Standorts.

Die erweiterte 3-2-1-1-0-Regel

Klassisches 3-2-1 wurde vor Ransomware-Verschlüsselung mit Backup-Sabotage entwickelt, bei der Angreifer gezielt zuerst die Backup-Infrastruktur kompromittieren, bevor sie die Produktivsysteme verschlüsseln. Moderne Anbieter wie Veeam, Acronis und Cohesity erweitern die Regel deshalb um zwei Ziffern:

• 1 zusätzliche Kopie, die air-gapped oder unveränderlich (immutable) ist — physisch getrennt vom Netzwerk oder per Object Lock/WORM technisch vor Löschung und Verschlüsselung geschützt, selbst mit Domain-Admin-Rechten
• 0 Fehler bei der Wiederherstellung — durch regelmässige, dokumentierte Restore-Tests verifiziert, nicht nur “das Backup-Job-Log zeigt grün”

Die “0” ist der meistübersehene Teil der Regel. Ein Backup-Job, der jede Nacht erfolgreich durchläuft, sagt nichts darüber aus, ob die Daten am Ende wiederherstellbar sind. Bitlocker-verschlüsselte Volumes ohne gesicherten Recovery Key, inkonsistente SQL-Snapshots oder ein defektes Backup-Repository fallen oft erst beim echten Restore auf — dann ist es zu spät.

RPO und RTO: die zwei Zahlen, die alles steuern

Bevor du irgendein Tool konfigurierst, brauchst du für jedes System zwei Kennzahlen — idealerweise gemeinsam mit der Geschäftsleitung festgelegt, nicht allein von der IT geschätzt.

Recovery Point Objective (RPO) beantwortet: “Wie viele Daten dürfen wir im Ernstfall maximal verlieren?” Ein RPO von 4 Stunden bedeutet, dass zwischen zwei Sicherungspunkten maximal 4 Stunden liegen dürfen — alles, was danach eingegeben wurde, ist im Fall eines Totalausfalls weg. Der RPO bestimmt direkt die nötige Backup-Frequenz.

Recovery Time Objective (RTO) beantwortet: “Wie lange darf die Wiederherstellung dauern, bis das System wieder läuft?” Ein RTO von 2 Stunden für den ERP-Server bedeutet: Ab dem Moment des Ausfalls hast du 2 Stunden, um das System komplett wiederhergestellt und nutzbar zu haben. Der RTO bestimmt die nötige Recovery-Architektur — reicht ein Restore von Tape (Stunden) oder brauchst du Hot-Standby/Replikation (Minuten)?

Ein häufiger Fehler: RPO und RTO werden mit “je kürzer desto besser” verwechselt. Ein RPO von 5 Minuten für jedes System klingt gut, treibt aber Storage-Kosten und Backup-Fenster-Last massiv nach oben. Realistisch ist eine Klassifizierung nach Business Impact: Tier 1 (unternehmenskritisch, z. B. ERP), Tier 2 (wichtig, z. B. Fileserver), Tier 3 (unkritisch, z. B. Testumgebungen). Jede Stufe bekommt ihr eigenes RPO/RTO-Ziel und damit ihre eigene Backup-Frequenz und -Priorität.

Backup-Typen im Vergleich: Full, Incremental, Differential, Synthetic Full

Die Wahl der Backup-Methode bestimmt direkt, wie lange ein Backup-Job dauert, wie viel Speicher er braucht und wie lange ein Restore dauert.

Full Backup ist am einfachsten wiederherzustellen, weil eine einzige, vollständige Kopie existiert — aber es braucht am meisten Zeit und Platz. In der Praxis nur noch als wöchentliche oder monatliche Basis sinnvoll.

Incremental Backups sind am schnellsten zu erstellen, weil nur die Änderungen seit dem letzten Backup (egal ob Full oder Incremental) gesichert werden. Der Haken: Für ein Restore brauchst du das letzte Full plus jedes nachfolgende Incremental in korrekter Reihenfolge. Ist eine Kette unterbrochen (ein Incremental fehlt oder ist korrupt), ist der komplette Wiederherstellungspunkt ab diesem Punkt unbrauchbar.

Differential Backups sichern immer alle Änderungen seit dem letzten Full — jedes Differential wird also mit der Zeit grösser, bis das nächste Full läuft. Restore braucht nur Full + das eine aktuellste Differential, was robuster ist als eine lange Incremental-Kette.

Synthetic Full (z. B. in Veeam Backup & Replication oder Synology Active Backup) löst das Ketten-Problem: Es werden weiterhin nur Incrementals übertragen, aber die Backup-Software baut im Hintergrund periodisch ein virtuelles Full-Backup aus den vorhandenen Blöcken zusammen — ohne die Produktionsumgebung erneut zu belasten. Das kombiniert die geringe Backup-Last von Incrementals mit der schnellen, robusten Restore-Fähigkeit eines Fulls.

Backup-Fenster und Bandbreite berechnen

Das Backup-Fenster ist die Zeitspanne, in der ein Backup laufen kann, ohne den Produktivbetrieb zu stören — typischerweise nachts oder am Wochenende. Wird das Fenster überschritten, läuft das Backup in die Geschäftszeit hinein und belastet Storage-I/O und Netzwerk während des Betriebs.

Die Grundformel:

Benötigte Zeit (Stunden) = Datenmenge (GB) / effektiver Durchsatz (GB/h)

Ein Praxisbeispiel für ein KMU mit 2 TB zu sicherndem Fileserver-Volumen über Gigabit-Ethernet:

Theoretische Bandbreite 1 GbE: 1000 Mbit/s = 125 MB/s = 450 GB/h
Realistischer Durchsatz (Overhead, Deduplizierung, gleichzeitige Jobs): ca. 40-60 % = 180-270 GB/h

2000 GB / 200 GB/h ≈ 10 Stunden für ein volles Backup

Bei einem nächtlichen Fenster von 22:00 bis 06:00 Uhr (8 Stunden) reicht das für ein volles Backup knapp nicht — ein Grund, warum Incremental/Synthetic-Full-Strategien in der Praxis fast immer nötig sind, sobald die Datenmenge über wenige hundert GB hinausgeht.

Für die Kapazitätsplanung bei WAN-Offsite-Backups (z. B. Replikation zu einem Cloud-Ziel oder Zweigstelle) rechnest du mit der tatsächlichen Upload-Bandbreite der Leitung, nicht mit der Download-Bandbreite:

Beispiel: 50 Mbit/s Upload, 500 GB tägliches Änderungsvolumen (Delta)

50 Mbit/s = 6.25 MB/s = 22.5 GB/h
500 GB / 22.5 GB/h ≈ 22 Stunden

→ Bei 500 GB täglichem Delta reicht die Leitung nicht für 24h-Zyklus.
→ Optionen: Bandbreite erhöhen, Deduplizierung/Komprimierung aktivieren,
  Änderungsvolumen reduzieren (z. B. Archivdaten ausschliessen),
  oder initiales Seeding physisch per Datenträgerversand.

Backup-Fenster planen: Schritt-für-Schritt-Ablauf

1. Datenmenge und Änderungsrate erheben — Wie viel GB/TB müssen initial gesichert werden, und wie viel ändert sich täglich (Delta)? Tools wie robocopy /L oder Backup-Software-eigene Change-Rate-Reports helfen bei der Schätzung.
2. Verfügbares Zeitfenster festlegen — Wann ist die Infrastruktur am wenigsten ausgelastet? Bei 24/7-Betrieb (z. B. internationale Standorte, E-Commerce) gibt es evtl. gar kein “ruhiges” Fenster mehr — dann sind CBT-basierte Snapshot-Backups mit minimaler I/O-Last Pflicht.
3. Durchsatz realistisch kalkulieren — Netzwerk, Storage-IOPS am Ziel, CPU für Deduplizierung/Komprimierung. Ein NAS mit langsamen SATA-Platten wird oft zum Flaschenhals, nicht das Netzwerk.
4. Backup-Typ wählen, der ins Fenster passt (siehe Vergleichstabelle oben) — meist Forever-Incremental mit periodischem Synthetic Full.
5. Mehrere Jobs staffeln, nicht parallelisieren — gleichzeitig laufende Backup-Jobs konkurrieren um dieselbe Netzwerk-/Storage-Bandbreite. Job-Reihenfolge und Abhängigkeiten in der Backup-Software definieren.
6. Puffer einplanen — mindestens 20-30 % Reserve im Fenster für Wachstum der Datenmenge und gelegentliche längere Läufe (z. B. nach grossen Datenimporten).
7. Nach 3 Monaten Praxisdaten reviewen — tatsächliche Laufzeiten mit der Kalkulation abgleichen und Backup-Fenster/Frequenz nachjustieren.

Air-Gap und Offsite-Kopien in der Praxis

“Offsite” heisst physisch getrennt — nicht einfach ein zweites Gerät im selben Serverraum. Für Schweizer KMU sind folgende Varianten gängig, mit unterschiedlichem Schutzniveau:

Für die meisten Schweizer KMU ist eine Kombination aus lokalem NAS/Backup-Server (schnelle Restores für Alltagsfälle wie versehentlich gelöschte Dateien) und einem Cloud-Ziel mit aktivierter Object-Lock-Immutability der pragmatischste Ansatz. Tape lohnt sich vor allem bei sehr grossen Datenmengen oder regulatorischen Anforderungen an lange, unveränderliche Aufbewahrung.

Testrestore-Zyklen und Dokumentation

Ein Backup ohne verifiziertes Restore ist eine Hoffnung, keine Absicherung. Etabliere einen wiederkehrenden Testzyklus, der zur Kritikalität der Systeme passt:

• Monatlich: Stichprobenartiges Datei-Restore aus dem Fileserver-Backup (einzelne Dateien/Ordner), dokumentiert mit Zeitstempel und Ergebnis.
• Quartalsweise: Vollständiges Bare-Metal- oder VM-Restore eines unkritischen Systems in eine isolierte Testumgebung — prüft, ob das komplette System (nicht nur einzelne Dateien) bootet und funktioniert.
• Halbjährlich bis jährlich: Restore eines Tier-1-Systems (z. B. ERP-Server oder Domain Controller) inklusive Zeitmessung — Vergleich der tatsächlichen Restore-Dauer mit dem definierten RTO.
• Nach jeder grösseren Infrastrukturänderung: Migration, neue Backup-Software-Version, Storage-Wechsel — jeweils gefolgt von einem Restore-Test, bevor der alte Zustand abgeschaltet wird.

Dokumentiere jeden Test mit: Datum, getestetes System, Restore-Ziel (Zeitpunkt/Recovery Point), tatsächliche Dauer, Ergebnis (erfolgreich/Probleme), verantwortliche Person. Diese Nachweise sind nicht nur für den Ernstfall wichtig, sondern zunehmend auch für Cyber-Versicherungen und im Kontext von NIS2 in der Schweiz relevant, wo dokumentierte Resilienzmassnahmen explizit gefordert werden.

Backup-Software-Auswahl: worauf achten

Für die technische Umsetzung im KMU-Kontext lohnt sich ein Blick auf folgende Kriterien, unabhängig vom konkreten Produkt:

• Application-Aware Backup (VSS-Integration für SQL Server, Exchange, Active Directory) statt reiner Crash-Consistent-Snapshots
• Changed Block Tracking (CBT) für schnelle Incrementals ohne volle Scans
• Immutability/Object-Lock-Support für mindestens ein Backup-Ziel
• Granulares Restore (einzelne Dateien, einzelne E-Mails, einzelne Datenbanktabellen) statt nur Komplett-Restore
• Verschlüsselung in Transit und at Rest, insbesondere bei Cloud-Zielen
• Alerting bei fehlgeschlagenen Jobs per E-Mail/Teams, nicht nur im Dashboard sichtbar
• Retention-Policies, die zu Aufbewahrungspflichten passen (z. B. 10 Jahre für Buchhaltungsdaten nach OR Art. 958f)

Für Microsoft-365-Daten (Exchange Online, SharePoint, OneDrive) gilt: Microsoft sichert die Infrastruktur, nicht deine Daten gegen versehentliches Löschen oder Ransomware innerhalb des Mandanten. Mehr dazu unter M365 Backup-Strategie.

Kostenfaktor: Wie viel Backup braucht ein Schweizer KMU wirklich?

Ein Trugschluss ist, dass mehr Redundanz automatisch besser ist. Die richtige Frage lautet: Was kostet ein Datenverlust oder Ausfall im Vergleich zu den Backup-Kosten? Für einen typischen 20-50-Mitarbeiter-Betrieb:

• Tagesausfall bei kompletter IT-Blockade: schnell 5-Stellig, je nach Branche auch mehr durch entgangene Aufträge und Reputationsschaden
• Lokales NAS mit RAID + Cloud-Backup mit Object Lock: laufende Kosten oft im tiefen dreistelligen Bereich pro Monat
• Restore-Test-Aufwand: ein halber Tag IT-Zeit pro Quartal

Die Investition in eine saubere 3-2-1-1-0-Strategie mit getesteten Restores ist verschwindend klein gegenüber dem Risiko eines unentdeckten, kaputten Backups im Ernstfall.

Weiterlernen

• Veeam: What is the 3-2-1 Backup Rule?
• Microsoft Learn: Azure Backup – Übersicht
• Microsoft Learn: Recovery Time Objective und Recovery Point Objective planen
• NIST SP 800-34: Contingency Planning Guide for Federal Information Systems
• Veeam Help Center: Backup-Methoden (Incremental, Reverse Incremental, Synthetic Full)
• Cohesity Glossar: 3-2-1-Backup-Regel

Videos

YouTube

YouTube