Backup-Mythen im Alltag: „Wir haben doch RAID“ – und 9 weitere Klassiker

Es beginnt oft harmlos. Ein Kollege löscht „aus Versehen“ einen Ordner im Fileshare. Oder ein Update kippt eine Anwendung aus der Kurve. Oder jemand klickt auf eine Mail, die eigentlich schon beim ersten Hinsehen nach Phishing riecht. Dann folgt diese eine Frage, die in vielen IT-Abteilungen wie ein Reflex kommt:

„Kein Problem – wir haben doch ein Backup, oder?“

Und plötzlich wird es still. Denn was viele im Alltag „Backup“ nennen, ist in Wahrheit etwas ganz anderes: Redundanz, Synchronisation, ein Papierkorb, ein Snapshot – oder schlicht Hoffnung.

Zeit, mit den 10 häufigsten Backup-Mythen aufzuräumen. Ohne Moralpredigt. Dafür mit klaren Gegenmassnahmen, die im KMU-Alltag funktionieren.

Mythos 1: „Wir haben doch RAID – also sind die Daten sicher.“

Realität: RAID schützt primär gegen den Ausfall einer Festplatte, nicht gegen Datenverlust. Löschen, Verschlüsseln durch Ransomware, falsche Rechte, kaputtes Dateisystem, Controller-Defekt – all das repliziert RAID brav mit. Heise bringt’s auf den Punkt: RAID ersetzt kein Backup.

Was stattdessen tun:

• Backup separat vom Produktivsystem (anderes System/Storage/Account)
• Mindestens eine Kopie offline oder unveränderlich (immutable)
• Restore regelmässig testen

Mythos 2: „Unsere Daten liegen in der Cloud – da ist Backup inklusive.“

Realität: Cloud-Anbieter sichern ihre Plattform – aber Ihre Datenverantwortung bleibt. Das ist exakt der Kern des Shared-Responsibility-Modells: Wer was absichert, hängt vom Servicemodell ab – und Kundenseite bleibt immer ein Teil der Verantwortung. [Quelle: Microsoft Learn]

Was stattdessen tun:

• Für SaaS (z. B. M365) ein eigenes Backup-Konzept definieren
• Klären: Was ist Restore-Ziel? Ein einzelnes Mail? Eine Site? Ein ganzer Tenant?
• Rechte/Accounts trennen: Backup-Account ≠ Admin-Account

Mythos 3: „Der Papierkorb reicht – zur Not stellen wir es wieder her.“

Realität: Papierkörbe sind praktische Komfortfunktionen – aber kein Backup-Plan. Beispiel SharePoint/OneDrive: Standard- und zweiter Papierkorb ergeben zusammen typischerweise rund 93 Tage – danach wird’s dünn, je nach Policy und Szenario. [Quelle: Microsoft Learn]

Was stattdessen tun:

• Aufbewahrungsanforderungen (Compliance) schriftlich festlegen
• „Wiederherstellbarkeit“ als Ziel: Versionen + echtes Backup + Restore-Prozess

Mythos 4: „Snapshots sind Backups.“

Realität: Snapshots sind oft der schnellste Weg zurück, aber häufig im selben Storage/Account/Trust-Bereich wie die Produktivdaten. Wenn Ransomware Admin-Rechte bekommt oder Storage-Zugriffe kompromittiert sind, sind Snapshots gerne gleich mit betroffen.

Was stattdessen tun:

• Snapshots als erste Verteidigungslinie – Backup als zweite
• Snapshots replizieren (anderswo) und zusätzlich immutable/offline sichern
• Zugriffe streng: Wer darf Snapshots löschen?

Mythos 5: „Wir synchronisieren alles auf ein zweites NAS – fertig.“

Realität: Synchronisation ist… Synchronisation. Sie kopiert auch Fehler. Wenn jemand „2025_final_final“ löscht oder verschlüsselt, landet genau das auf dem Ziel. Schnell, zuverlässig – und katastrophal konsequent.

Was stattdessen tun:

• Backup braucht Historie (Versionen/Generationen)
• „Time Travel“ ermöglichen: gestern, letzte Woche, letzter Monat
• Sync gern zusätzlich – aber nicht als alleinige Absicherung

Mythos 6: „Backup läuft nachts. Mehr müssen wir nicht wissen.“

Realität: Ein grüner Haken heisst nur: Irgendetwas ist gelaufen. Die entscheidende Frage lautet: Können wir wiederherstellen – in der Zeit, die das Business akzeptiert? Ohne Restore-Test bleibt Backup ein Gefühl, kein Nachweis.

Was stattdessen tun:

• RTO/RPO definieren (Wie schnell? Wie viel Datenverlust maximal?)
• Monatlicher Restore-Test (klein anfangen: eine VM, ein Share, eine Mailbox)
• Reporting auf Ergebnis: „Restore erfolgreich“ statt „Job erfolgreich“

Mythos 7: „Ransomware? Uns trifft’s nicht.“

Realität: Das BSI ist da sehr klar: Backups sind eine der wichtigsten präventiven Massnahmen, um Verfügbarkeit nach einem Ransomware-Vorfall wiederherzustellen – und sie sollten offline bzw. isoliert vorliegen. [Quelle: BSI]
Warum? Weil Angreifer heute gezielt Backups suchen und zerstören, bevor sie verschlüsseln.

Was stattdessen tun:

• Mindestens eine Kopie offline/air-gapped oder immutable
• Admin-Konten härten (MFA, getrennte Rollen, minimale Rechte)
• „Assume breach“: Backup-Umgebung so planen, als wäre das Netz kompromittiert

Mythos 8: „Wir sichern alles – dann sind wir auf der sicheren Seite.“

Realität: „Alles“ klingt gut, ist aber häufig teuer, langsam und unübersichtlich. In der Praxis endet das in Backups, die zu lange laufen – und Restores, die niemand beherrscht. Für viele KMU ist gezielte Priorisierung die bessere Strategie: Was ist geschäftskritisch? Was muss wie schnell zurück?

Was stattdessen tun:

• Tiering: kritisch / wichtig / nice-to-have
• Für kritisch: kürzere Intervalle, schnellere Restore-Wege
• Für Archiv: längere Aufbewahrung, günstiger Storage

Mythos 9: „Wir haben Backups offsite – damit ist die Sache erledigt.“

Realität: Offsite ist wichtig, aber nicht automatisch sicher. Wenn Offsite per VPN/SMB „dauerverbunden“ ist und dieselben Credentials nutzt, ist es im Zweifel nur ein weiteres Laufwerk im selben Angriffsraum. Moderne Regeln ergänzen deshalb Isolation und Unveränderlichkeit (Stichwort: 3-2-1).

Was stattdessen tun:

• Offsite ja – aber mit Netzwerk-/Account-Trennung
• Immutable Storage oder WORM-Mechanismen prüfen
• „Break-glass“: Wie kommt ihr im Worst Case an die letzte saubere Kopie?

Mythos 10: „Restore macht dann schon irgendwer.“

Realität: In Stresssituationen zählt keine Theorie, sondern ein geübter Ablauf. Wer hat Zugriff? Wo liegen Keys/Passwörter? Welche Systeme zuerst? Wie kommunizieren wir? Ohne Plan wird Restore zum Improvisationstheater – und kostet genau dann Zeit, wenn sie am teuersten ist.

Was stattdessen tun:

• Mini-Runbook (1–2 Seiten): Prioritäten, Ansprechpartner, Schritte
• Zugangsdaten sicher und verfügbar (aber nicht im kompromittierbaren System)
• Einmal im Quartal: „Fire Drill“ mit einem realen Restore-Szenario

Der Praxis-Shortcut: 7 Checks, die Mythen sofort entlarven

Kurze Selbstprüfung:

1. Haben wir mindestens 3 Kopien der kritischen Daten?
2. Liegen sie auf mindestens 2 unterschiedlichen Medien/Plattformen?
3. Gibt es eine Kopie extern (offsite)?
4. Gibt es eine Kopie offline/immutable?
5. Können wir Restore zeitnah durchführen (RTO) – und wissen wir das, weil wir es getestet haben?
6. Sind Backup-Accounts getrennt und geschützt (MFA, minimale Rechte)?
7. Haben wir einen Plan, wer was im Ernstfall macht?

Fazit: Backup ist kein Produkt – sondern ein Versprechen

RAID, Cloud, Snapshots, Papierkorb, Replikation – all das sind wertvolle Bausteine. Aber sie werden erst dann zu „Backup“, wenn am Ende ein Versprechen steht, das du einlösen kannst:

„Wir bekommen die Daten zurück – vollständig, sauber, rechtzeitig.“

Wenn Sie bei einem der Mythen innerlich genickt haben: perfekt. Dann haben Sie gerade die Stellen gefunden, an denen sich mit überschaubarem Aufwand die grösste Resilienz holen lässt. Und genau da lohnt es sich, nicht länger auf Hoffnung zu setzen, sondern auf ein Backup-Konzept, das Restore wirklich kann.