Viele kleine und mittelständische Unternehmen haben „irgendeine Form“ von Backup. Oft läuft sogar jeden Abend ein Job, irgendwo blinkt ein grünes Häkchen und damit scheint das Thema erledigt. Die Realität sieht im Ernstfall häufig anders aus: Wiederherstellungen dauern länger als gedacht, Sicherungen sind unvollständig oder unbrauchbar und im schlimmsten Fall sind Produktivdaten und Backups gleichzeitig betroffen.
Wie groß die Lücke zwischen „Backup vorhanden“ und „Recovery funktioniert“ sein kann, zeigt eine KMU-Backup-Studie: Zwar sichern viele Unternehmen regelmäßig, aber 72 % testen ihre Backups selten oder nie laut einer Studie von 2025 von Data Reverse. Und genau das ist der Knackpunkt: Backups sind nicht nur eine technische Pflichtübung, sie sind eine betriebliche Absicherung. 2026 gehören dazu neben Verfügbarkeit auch Themen wie Ransomware-Resilienz, Cloud/SaaS und nachvollziehbare Prozesse.
Im Folgenden finden Sie die sieben häufigsten Fehler - jeweils mit typischen Symptomen und praxistauglichen Gegenmaßnahmen.
Backup: eigenständige Sicherung, die eine Wiederherstellung auf einen definierten Zeitpunkt ermöglicht.
Snapshot: schneller Zustandspunkt auf demselben Storage - gut für schnelle Rollbacks, aber kein Ersatz für ein externes Backup.
Replikation: Kopie in ein anderes System/Standort - erhöht Verfügbarkeit, ersetzt aber kein Backup (z. B. bei versehentlichem Löschen oder Verschlüsselung wird oft „sauber repliziert“).
Das Ziel bleibt immer gleich: Sie müssen innerhalb der für Ihr Geschäft oder Ihre Organisation akzeptablen Zeit wieder arbeitsfähig sein. Damit sind wir bei zwei Business-Begriffen, die jedes Backup-Konzept enthalten sollte:
RPO (Recovery Point Objective): Wie viel Datenverlust ist maximal tolerierbar? (z. B. 4 Stunden)
RTO (Recovery Time Objective): Wie schnell muss das System wieder laufen? (z. B. 2 Stunden)
Symptom: Backup läuft „durch“, aber niemand hat in den letzten Monaten eine echte Wiederherstellung durchgeführt.
Risiko: Beschädigte Sicherungen bleiben unentdeckt; Wiederherstellungszeiten sind unbekannt; im Incident verlieren Sie Zeit, Geld und Vertrauen.
Praxisbild: Ein KMU sichert „jeden Tag“. Erst beim Vorfall fällt auf, dass seit Monaten Jobs fehlschlagen oder nur Teilbestände gesichert wurden.
Etablieren Sie einen Restore-Testplan:
monatlich: Stichproben-Restore einzelner Dateien/Ordner/Postfächer
quartalsweise: vollständiger Restore eines repräsentativen Systems (z. B. VM, Datenbank, Fileserver)
jährlich: Notfallübung (Tabletop + technischer Restore)
Dokumentieren Sie Ergebnisse: Was wurde wie schnell wiederhergestellt? Wo hakte es?
Setzen Sie auf „Proof statt Gefühl“: Ein Backup ist erst dann „gut“, wenn der Restore nachweislich funktioniert.
Symptom: Backups liegen im selben Gebäude oder auf dem gleichen Storage/NAS wie die Produktivsysteme.
Risiko: Brand, Diebstahl, Wasserschaden oder Überspannung zerstören Daten und Backups gleichzeitig.
Praxisbild: Brand im Serverraum - inklusive Backup-NAS. Die Wiederanlaufplanung reduziert sich auf „Was steht noch auf Papier?“.
Setzen Sie mindestens die 3-2-1-Regel um: 3 Kopien, 2 unterschiedliche Medien/Technologien, 1 Kopie außer Haus. Das wird auch als empfehlenswerte Backup-Strategie vom BSI genannt.
Für erhöhte Resilienz: 3-2-1-1-0 (zusätzlich 1 immutable/offline Kopie; „0“ steht für verifizierbare, fehlerfreie Restores - also konsequentes Testen/Verifizieren).
Offsite kann neutral umgesetzt werden: zweiter Standort, Cloud-Backup, Object Storage mit Unveränderlichkeit, Band/Offline-Medien oder ein externer Dienstleister.
Symptom: „Macht der Admin nebenbei“. Vertretung unklar, Dokumentation lückenhaft, Zugangsdaten/Runbooks sind nicht gepflegt.
Risiko: Wissensverlust, stille Fehler, unklare Eskalation – und im Ernstfall entscheidet Zufall über die Wiederherstellungsfähigkeit.
Praxisbild: Ein Schlüsselmitarbeiter verlässt das Unternehmen. Skripte, Passwörter und Logik kennt niemand - die Backup-„Automatik“ wird zur Blackbox.
Definieren Sie Rollen:
Backup Owner (Strategie, Risiko, Reporting)
Operativer Verantwortlicher (Betrieb, Monitoring, Tests)
Notfall-Verantwortlicher (Wiederanlauf, Kommunikation, Priorisierung)
Legen Sie einfache, aber vollständige Dokumentation an: Systeme, Zeitpläne, Aufbewahrung, Restore-Schritte, Kontakt-/Eskalationswege.
Verankern Sie ein „Backup-Review“ in Änderungen: Neue Anwendungen, neue Datenpfade, neue Cloud-Dienste → Backup-Konzept nachziehen.
Symptom: Verlass auf Papierkorb, Versionierung oder Standard-Retention.
Risiko: Nach Fristablauf sind Daten weg; bei Fehlbedienung, Insider-Vorfällen oder Ransomware fehlen belastbare Restore-Punkte; eDiscovery/Prüfungen werden schwierig.
Wichtig: Cloud heißt nicht automatisch „Ihre Daten sind vollständig abgesichert“. In Shared-Responsibility-Modellen bleiben Kunden für Daten/Identitäten und deren Schutz mitverantwortlich. Microsoft beschreibt diese Verantwortung für Cloud-Dienste explizit. In den Google Leitfäden wird auf ein Shared-Responsibility-Modell hingewiesen, bei dem Kunden insbesondere für Inhalte und Zugriffsrichtlinien verantwortlich sind.
Prüfen Sie, ob Sie für SaaS eine echte Backup-Strategie haben (nicht nur „Retention“).
Definieren Sie Wiederherstellungsszenarien: Einzeldatei, kompletter User, kompletter Bereich/Team, Punkt-in-Zeit.
Planen Sie Aufbewahrung nach Bedarf (Compliance, Verträge, Projekte) und nicht nur nach Standard-Fristen.
Symptom: Alle Systeme werden gleich behandelt. Backup-Frequenz und Restore-Methodik sind überall identisch.
Risiko: Kritische Systeme stehen zu lange; das Unternehmen ist zwar „irgendwann“ wieder da - aber zu spät.
Praxisbild: ERP-Restore dauert 48 Stunden, akzeptabel wären vier. Ergebnis: Lieferfähigkeit, Abrechnung und Produktion stehen.
So vermeiden Sie es:
Machen Sie eine einfache Kritikalitätsklassifizierung (z. B. Gold/Silber/Bronze):
Gold: kurze RTO/RPO, schnelle Restore-Optionen, häufigere Sicherung
Silber: Standard-Backups, klare Restore-Priorität
Bronze: weniger kritisch, längere Wiederherstellungszeiten akzeptabel
Leiten Sie daraus technisch passende Verfahren ab (z. B. Image-Backups für schnelle Systemwiederherstellung, häufigere Sicherung geschäftskritischer Datenbanken).
Symptom: Backup-Server/Repository im gleichen AD-Kontext, gleiche Admin-Identitäten, keine Unveränderlichkeit, keine Trennung.
Risiko: Angreifer verschlüsseln oder löschen zuerst die Backups, um den Druck zu erhöhen.
Praxisbild: Ransomware trifft Produktivsysteme und Backup-Repository. Es bleiben nur alte Offline-Stände oder das Unternehmen zahlt.
So vermeiden Sie es:
Setzen Sie auf offline/immutable Backups (Unveränderlichkeit/Write-Once-Read-Many, Object-Lock-Mechanismen, gehärtete Repositories).
Trennen Sie Identitäten und Rechte: separate Backup-Admins, MFA, „least privilege“, getrennte Verwaltungswege.
Prüfen Sie regelmäßig, ob Backups wirklich außerhalb des Einflusses kompromittierter Accounts liegen.
Die Empfehlung, offline, verschlüsselte Backups vorzuhalten und Restores regelmäßig zu testen, wird in aktuellen #StopRansomware-Empfehlungen ausdrücklich genannt.
Symptom: Backup-Jobs laufen „im Hintergrund“. Fehlermeldungen werden übersehen, Kapazitäten laufen voll, niemand hat einen Überblick.
Risiko: Wochenlange Fehljobs und im Incident stellt sich heraus: Es gibt keine verwertbaren Restore-Punkte.
So vermeiden Sie es:
Technisches Monitoring: Dashboards, Alarmierung, automatisches Ticketing, Kapazitätsprognosen.
Management-Reporting (monatlich, kurz):
Erfolgsquote der Jobs
Abdeckung kritischer Systeme
letzter Restore-Test (Datum/Ergebnis)
Status Offsite/Immutable
Top-Risiken & Maßnahmen
Das Reporting ist nicht „Bürokratie“, sondern schafft Entscheidungsfähigkeit: Wo investieren Sie sinnvoll und wo ist das Risiko bereits sauber reduziert?
Neben der Bedrohungslage steigt auch der Erwartungsdruck an nachweisbare Resilienz. In Deutschland ist die nationale Umsetzung der NIS-2-Richtlinie zum 6. Dezember 2025 in Kraft getreten mit erhöhten Anforderungen an Cybersicherheit für betroffene Organisationen. (Hinweis: Ob Ihr Unternehmen direkt betroffen ist, hängt von Kriterien wie Branche und Größe ab.)
Wenn Sie bei einer Frage zögern, ist das bereits ein Signal:
Haben wir im letzten Quartal mindestens einen vollständigen Restore eines kritischen Systems durchgeführt?
Gibt es eine Offsite-Kopie getrennt vom Standort der Produktivsysteme?
Ist mindestens eine Kopie immutable/offline und organisatorisch getrennt verwaltet?
Sind Verantwortlichkeiten, Vertretung und Dokumentation klar geregelt?
Sind Microsoft 365/Google Workspace & Co. im Backup-Konzept enthalten?
Haben wir definierte RPO/RTO pro Systemklasse und erreichen wir sie realistisch?
Gibt es Monitoring und ein kurzes Reporting an IT-Leitung/Geschäftsführung?
Ein Backup-Konzept ist nicht nur „Speicherplatz plus Zeitplan“. Es ist ein Zusammenspiel aus Zielen (RPO/RTO), Architektur (3-2-1/3-2-1-1-0), Security (immutable/offline, getrennte Identitäten), Prozessen, Monitoring und regelmäßigen Restore-Tests. Genau diese Punkte entscheiden im Ernstfall, ob Sie innerhalb weniger Stunden wieder arbeitsfähig sind oder ob aus einem IT-Vorfall eine Unternehmenskrise wird.