DATENSICHERUNG · SICHERUNGSARCHITEKTUR
Die 3-2-1-Regel fordert mindestens drei Datenkopien auf zwei Speicherarten, davon eine an einem anderen Ort. Als Merkhilfe ist das nützlich. Eine belastbare Sicherung entsteht jedoch erst, wenn die Kopien unterschiedliche Ausfälle überstehen und tatsächlich wiederhergestellt werden können.
Drei synchronisierte Ordner können denselben Löschfehler enthalten. Zwei verschiedene Geräte können mit demselben Administratorkonto erreichbar sein. Eine Cloudkopie ist räumlich entfernt und kann trotzdem über ein kompromittiertes Konto gelöscht werden. Ein unbeschrifteter USB-Datenträger ist offline, hilft aber nicht, wenn niemand Schlüssel, Inhalt oder letzten erfolgreichen Lauf kennt.
Dieser Leitfaden übersetzt 3-2-1 in ein Verfahren für kleine Unternehmen. Er führt von Datenklassen und Wiederherstellungszielen über Speicher-, Standort- und Rechtewahl bis zu Aufbewahrung, Überwachung und Restoretest. Die Tabellen dienen als Prüfraster für vorhandene Sicherungen und als Arbeitsgrundlage für eine neue Architektur.
Kapitelübersicht
3-2-1 verstehenFehlerbereicheDatenklassenArchitekturvariantenOffline und unveränderbarUmsetzungKontrolleRestoretest
1. Die 3-2-1-Regel beschreibt Mindestvielfalt, keine fertige Backupstrategie
Gezählt werden der produktive Datenbestand und zwei zusätzliche Sicherungskopien. Die Kopien sollen auf mindestens zwei Speicherarten liegen; mindestens eine befindet sich außerhalb des primären Standorts.
| Merkregel | Gemeinte Grundidee | Zusätzlich zu klären |
|---|---|---|
| 3 Kopien | Ein Produktivstand plus mindestens zwei Sicherungsstände vermeiden die Abhängigkeit von einer einzigen Kopie. | Sind die Stände zeitlich, technisch und administrativ wirklich voneinander getrennt? |
| 2 Speicherarten | Unterschiedliche Technik reduziert gemeinsame Medien- oder Gerätefehler. | Teilen beide Ziele trotzdem denselben Server, Controller, Standort oder Anbieter? |
| 1 Kopie außer Haus | Brand, Wasser, Diebstahl und Standortausfall treffen nicht alle Kopien. | Bleibt die Kopie bei Kontoübernahme, Ransomware und Internetausfall nutzbar? |
Die Regel sagt weder, wie häufig gesichert wird, noch wie viele ältere Generationen erhalten bleiben. Sie bestimmt keine Verschlüsselung, keine Administrationsrechte, keinen Wiederherstellungsschlüssel und kein Wiederanlaufziel. Auch die Begriffe „Speicherart“ und „Kopie“ müssen konkret interpretiert werden. Ein RAID-Spiegel besteht zwar aus mehreren Datenträgern, bildet aber einen gemeinsamen logischen Produktivbestand und zählt nicht als mehrere unabhängige Sicherungen.
Wann eine Kopie als eigenständig gelten kann
- Sie besitzt einen eigenen Datenstand und ist nicht nur eine Ansicht derselben Quelle.
- Ihr Verlust oder ihre Beschädigung zerstört die anderen Kopien nicht automatisch.
- Ein Fehler im Produktivsystem überschreibt sie nicht unmittelbar.
- Inhalt, Sicherungszeitpunkt und Aufbewahrung sind nachvollziehbar.
- Zugriff und Wiederherstellung sind mit benannten Rollen möglich.
- Die Kopie wurde durch einen Restore oder einen gleichwertigen praktischen Test geprüft.
2. Kopien werden nach unabhängigen Fehlerbereichen bewertet
Räumliche Trennung allein genügt nicht. Eine Sicherung kann am anderen Ende Deutschlands liegen und trotzdem mit demselben kompromittierten Konto, Backupclient oder Löschbefehl erreichbar sein.
| Fehlerbereich | Prüffrage | Beispiel einer wirksamen Trennung |
|---|---|---|
| Datenträger | Liegen Produktivstand und Sicherung auf demselben physischen Medium? | Eigenständiges Zielgerät oder externer Speicherdienst |
| Gehäuse und Controller | Fallen beide Kopien bei Defekt des NAS oder Controllers aus? | Backup außerhalb des Produktiv-NAS |
| Strom und Netzwerk | Teilen beide Ziele Stromkreis, Switch, Router oder Standort? | Zweite Kopie an anderem Ort oder zeitweise physisch getrennt |
| Identität | Kann dasselbe Konto Produktivdaten und alle Sicherungen löschen? | Getrennte Backupidentität mit eigenem MFA- und Wiederherstellungsweg |
| Administration | Besitzt ein kompromittierter Systemadministrator automatisch Vollzugriff auf Backupziele? | Getrennte Rollen und eingeschränkte Löschrechte |
| Backupclient | Kann Schadsoftware auf dem Quellsystem gespeicherte Zielzugänge verwenden? | Kurzlebige Zugangsdaten, Pull-Verfahren oder Ziel mit eingeschränkter Schreibweise |
| Software | Erzeugen dieselbe fehlerhafte Anwendung oder derselbe Job alle Kopien? | Zweite Technik oder unabhängiger Kontroll- und Exportweg |
| Anbieter | Fallen Produktivdienst und Cloudbackup gemeinsam aus? | Separate Plattform oder exportierbare Kopie außerhalb des Hauptanbieters |
| Zeit | Enthalten alle Kopien bereits unbemerkte Löschung oder Korruption? | Ausreichende Generationen über die wahrscheinliche Erkennungszeit |
| Standort | Treffen Brand, Wasser, Diebstahl oder Zutrittsverlust sämtliche Kopien? | Geschützte Kopie außerhalb desselben Gebäudes |
| Schlüssel | Gehen Sicherung und Entschlüsselungsweg gemeinsam verloren? | Redundant geschützter Schlüssel an getrenntem Ort |
Schritt für Schritt: Eine vorhandene Kopie auf Unabhängigkeit prüfen
- Produktive Datenquelle und Sicherungsziel eindeutig benennen.
- Physische Geräte, Speicherpools und Standorte beider Seiten erfassen.
- Verwendete Konten, Rollen und gespeicherte Zugangsdaten dokumentieren.
- Prüfen, ob ein normaler Benutzer oder Quelladministrator alte Sicherungen löschen kann.
- Backupclient und dessen Reichweite auf dem Quellsystem bestimmen.
- Ermitteln, ob Änderungen sofort repliziert oder als getrennte Generationen geschrieben werden.
- Lösch- und Überschreibschutz des Ziels praktisch mit einem Testobjekt prüfen.
- Aufbewahrungsdauer mit der typischen Erkennungszeit von Fehlern vergleichen.
- Standort-, Strom-, Netzwerk- und Anbieterabhängigkeiten markieren.
- Entschlüsselungsschlüssel und Wiederherstellungsgerät als eigene Abhängigkeiten aufnehmen.
- Mindestens einen realistischen gemeinsamen Ausfall durchspielen.
- Restlücken mit Ersatzmaßnahme, Verantwortung und Testtermin dokumentieren.
3. Nicht jeder Datenbestand benötigt dasselbe Intervall und dieselbe Architektur
Die Sicherung wird nach Geschäftsfolgen geplant. Häufig geänderte Auftragsdaten benötigen andere Intervalle als unveränderte Archivunterlagen; ein rekonstruierbarer Softwareinstaller ist anders zu behandeln als einmalige Kundendokumentation.
| Datenklasse | Führende Quelle | Änderungsrate | Maximal tragbarer Datenverlust | Benötigte Rückkehr |
|---|---|---|---|---|
| Aktive Projektdateien | Definierte Teamablage | Mehrmals täglich | Wenige Arbeitsstunden, falls geschäftlich festgelegt | Dateien, Versionen, Ordnerstruktur und Berechtigungen |
| E-Mail und Kalender | Cloudmandant | Laufend | Abhängig von Auftrags- und Kommunikationsprozess | Postfächer, Anhänge, Termine, Rechte und Suchbarkeit |
| Buchhaltungsdaten | Fachanwendung oder zentrale Ablage | Täglich bis monatlich | Seit letzter freigegebener Buchung | Datenbank, Belege, Nummernkreise und Auswertung |
| Geräte- und Netzkonfiguration | Produktivsystem | Bei Änderung | Keine nicht dokumentierte Konfigurationsänderung | Importierbarer Export plus Versions- und Gerätezuordnung |
| Vertrags- und Stammdaten | Fachanwendung oder Dokumentenablage | Regelmäßig | Nach festgelegtem Geschäfts- und Nachweiserfordernis | Inhalt, Zuordnung, Metadaten und Lesbarkeit |
| Arbeitsplatzprofile | Endgerät und Cloudprofil | Laufend | Nur lokale geschäftliche Daten, die nicht anderweitig geführt werden | Benutzerdaten; Standardsoftware kann neu installiert werden |
Die Tabelle wird mit tatsächlichen Werten gefüllt. „Täglich“ ist kein Selbstzweck: Entstehen in einem Arbeitstag hundert nicht rekonstruierbare Vorgänge, kann ein tägliches Intervall zu groß sein. Werden Unterlagen nur monatlich ergänzt, kann eine tägliche Vollsicherung unnötig sein. Tolerierbarer Datenverlust, Änderungsrate, Speicherbedarf und Wiederherstellungsdauer werden gemeinsam betrachtet.
| Bestandteil | Warum für den Wiederanlauf nötig | Prüfung |
|---|---|---|
| Systemkonfiguration | Ohne Einstellungen lässt sich Hardware oder Dienst nicht gleichartig aufbauen. | Export auf Testsystem einlesen oder Struktur prüfen |
| Berechtigungen | Dateien ohne Rollenmodell können zu offen oder unzugänglich zurückkehren. | Erlaubten und verweigerten Zugriff testen |
| Datenbank und Transaktionsprotokolle | Bloßes Kopieren geöffneter Dateien kann inkonsistente Stände erzeugen. | Anwendungsgeeignetes Sicherungsverfahren und Konsistenztest |
| Schlüssel und Zertifikate | Verschlüsselte Daten oder Dienste bleiben ohne passenden Schlüssel unbrauchbar. | Zuordnung, Ablaufdatum und getrennten Zugriff prüfen |
| Lizenzen und Installationsquellen | Ersatzsystem benötigt ausführbare, zulässige Software. | Download-, Vertrags- und Aktivierungsweg dokumentieren |
| Cloudkonfiguration und Identitäten | Daten allein rekonstruieren keine Mandantenrollen, Regeln oder Integrationen. | Export, Infrastrukturvorlage oder dokumentierten Neuaufbau testen |
| Wiederherstellungsanleitung | Reihenfolge und Abhängigkeiten sind im Notfall nicht aus Dateien ablesbar. | Vertretung führt abgegrenzten Test aus |
4. Architekturvarianten werden gegen reale Ausfälle verglichen
Es gibt keine universelle Kombination aus NAS, USB und Cloud. Entscheidend ist, welche Kopie schnell verfügbar, welche gegen Angriffe getrennt und welche außerhalb des Standorts wiederherstellbar bleibt.
| Ausgangslage | Kopie 1 | Kopie 2 | Kopie 3 | Besondere Kontrolle |
|---|---|---|---|---|
| Lokaler Dateiserver | Produktiver Server | Versioniertes Backup auf getrenntem lokalen Ziel | Verschlüsselte Offline- oder Offsite-Kopie | Lokales Ziel nicht mit normalen Domänenrechten löschbar |
| NAS als führende Ablage | Produktives NAS mit RAID | Backup auf eigenständiges Zielgerät | Verschlüsselte Kopie an anderem Standort oder geeignetem Cloudziel | RAID und interne Snapshots nicht als zusätzliche Geräte zählen |
| Microsoft-365-Dateien | Produktiver Cloudmandant | Anbieterinterne Versionen und Aufbewahrung als schnelle Ebene | Getrennt administriertes Backup oder definierter Export außerhalb des Mandanten | Wiederherstellung von Inhalt, Berechtigungen und Metadaten prüfen |
| Einzelne Notebooks | Lokale Arbeitsdaten | Automatisierte zentrale Sicherung | Getrennte Standort- oder Cloudkopie der zentralen Sicherung | Lokale Dateien außerhalb synchronisierter Ordner erfassen |
| Cloud-Fachanwendung | Produktive SaaS-Daten | Anbieterfunktionen oder regelmäßiger anwendungsgeeigneter Export | Geschützte Kopie außerhalb des Anbieters | Importierbarkeit, Beziehungen und vollständiger Exit testen |
Eine Kopie kann mehrere Eigenschaften verbinden. Ein verschlüsseltes Wechselmedium ist eine zweite Speicherart, kann offline sein und außerhalb des Standorts lagern. Ein Cloud-Objektspeicher kann offsite, versioniert und gegen Überschreiben geschützt sein. Dennoch werden Konto, Löschrecht, Anbieterabhängigkeit, Schlüssel und Wiederherstellungsbandbreite einzeln geprüft.
| Ziel | Stärke | Typische Grenze | Geeignet, wenn |
|---|---|---|---|
| Lokales Backup-NAS | Schnelle Sicherung und Rücksicherung großer Datenmengen | Standort- und Netzwerkangriff können gemeinsam wirken | Rechte getrennt und zusätzliche Offsite-Kopie vorhanden sind |
| Rotierende externe Datenträger | Physisch trennbar und transportierbar | Manueller Wechsel, Verlust, Alterung und Schlüsselpflege | Wechsel, Verschlüsselung, Lagerung und Test verbindlich organisiert sind |
| Cloud-Objektspeicher | Räumliche Trennung, skalierbare Aufbewahrung und mögliche Unveränderbarkeit | Internet, Kostenmodell, Konto und Konfiguration | Rechte, Löschschutz, Schlüssel und Rücksicherungszeit getestet sind |
| Cloud-zu-Cloud-Backup | Automatisierte Sicherung von SaaS-Daten | Kann trotz Anbietertrennung von zentraler Identität oder Fehlkonfiguration abhängen | Eigener Wiederherstellungsweg und granularer Restore geprüft sind |
| Band oder anderes Wechselmedium | Hohe Kapazität und klare physische Trennung möglich | Laufwerk, Medienverwaltung und Wiederherstellungsprozess erforderlich | Volumen und Aufbewahrung den Betriebsaufwand rechtfertigen |
5. Offline, unveränderbar und administrativ getrennt sind verschiedene Eigenschaften
Eine Sicherung kann räumlich entfernt und online erreichbar sein. Sie kann unveränderbar gespeichert und trotzdem mit einem mächtigen Konto vorzeitig löschbar sein. Jede Schutzwirkung wird separat geprüft.
| Schutzform | Wirkung | Verbleibende Abhängigkeit | Praktischer Test |
|---|---|---|---|
| Physisch offline | Datenträger ist außerhalb des Sicherungslaufs nicht elektronisch erreichbar. | Wechselprozess, sichere Lagerung, Medium und Schlüssel | Quelladministrator kann getrennte Kopie nicht auflisten oder löschen. |
| Netzwerkseitig getrennt | Ziel erlaubt nur definierte Verbindungen oder Zeitfenster. | Firewall, Backupclient und Zieladministration | Unzulässiger Quellzugriff wird technisch verweigert. |
| Administrativ getrennt | Produktivadministrator besitzt keine vollständigen Backuprechte. | Backupidentität, MFA und Notfallwiederherstellung | Produktivkonto kann vorhandene Generationen nicht entfernen. |
| Unveränderbare Aufbewahrung | Objekte können während einer festgelegten Frist nicht überschrieben oder gelöscht werden. | Korrekte Konfiguration, Frist, Anbieter und gegebenenfalls privilegierte Sonderwege | Testobjekt lässt sich vor Fristende nicht verändern oder entfernen. |
| Nur anhängbarer Zugriff | Backupclient kann neue Daten schreiben, aber alte Stände nicht verändern. | Zielkontrolle und korrekte Rechtezuweisung | Client schreibt neue Generation und scheitert beim Löschen einer alten. |
Trennwirkung prüfen: Eine Einstellung mit dem Namen „immutable“, „locked“ oder „geschützt“ ist noch kein Ergebnis. Mit einem Testobjekt wird kontrolliert, welches Konto es schreiben, lesen, überschreiben und löschen kann, wie lange die Sperre gilt und ob ein übergeordnetes Administrationskonto sie verkürzen kann. Der Test darf produktive Sicherungen nicht gefährden.
Offline-Sicherungen benötigen trotzdem regelmäßige Aktualisierung. Ist ein Medium fast immer getrennt, aber nur zweimal im Jahr beschrieben, kann der Datenverlust zu groß sein. Umgekehrt kann eine häufig aktualisierte Onlinekopie bei einem Angriff gefährdet sein. Deshalb werden schnelle Sicherungsintervalle und starke Trennung als zwei eigene Anforderungen geplant.
6. Schritt für Schritt: Die 3-2-1-Architektur im Unternehmen umsetzen
Die Reihenfolge verhindert, dass zuerst Speicher gekauft und erst danach nach einem Sicherungszweck gesucht wird.
- Geschäftlich verantwortliche Person und technische Umsetzung benennen.
- Datenquellen, Systeme und Standorte vollständig inventarisieren.
- Führende Datenbestände von Synchronisation, Cache, Archiv und vorhandenen Sicherungen trennen.
- Daten in Klassen mit ähnlicher Bedeutung und Änderungsrate zusammenfassen.
- Je Klasse maximal tragbaren Datenverlust und Wiederanlaufzeit festlegen.
- Notwendige Inhalte einschließlich Konfiguration, Rechte, Schlüssel und Anwendungen definieren.
- Vorhandene Kopien und Ziele mit Standort, Konto, Aufbewahrung und Status erfassen.
- RAID, Snapshots und synchronisierte Ordner korrekt einordnen und nicht doppelt zählen.
- Gemeinsame Geräte-, Standort-, Identitäts- und Anbieterfehler markieren.
- Lokale schnelle Sicherung für kurze Wiederherstellungszeiten auswählen.
- Zweite Sicherung gegen Produktivadministration und Ransomwarezugriff trennen.
- Mindestens eine geeignete Kopie außerhalb des primären Standorts vorsehen.
- Speicherarten nach Volumen, Änderungsrate, Transport und Wiederherstellungsziel wählen.
- Persönliche Backupkonten, MFA und Vertretung einrichten.
- Verschlüsselung aktivieren und Schlüssel außerhalb des Sicherungsziels redundant schützen.
- Backupjobs mit Quellen, Ausschlüssen, Intervallen und Bandbreitenfenstern konfigurieren.
- Versionen und Aufbewahrung an Fehlererkennungszeit und Geschäftsvorgaben anpassen.
- Lösch-, Überschreib- und Trennwirkung mit Testobjekten prüfen.
- Warnungen für Jobfehler, Kapazität, ausbleibende Daten und Zielprobleme konfigurieren.
- Verantwortliche und Vertretung als persönliche Empfänger testen.
- Wiederherstellungsanleitung und Notfalldokumentation außerhalb der Produktiv-IT ablegen.
- Einzeldatei, Ordner, Berechtigung und Anwendung auf getrenntes Ziel wiederherstellen.
- Dauer und Datenstand mit den festgelegten Zielen vergleichen.
- Technische und fachliche Abnahme dokumentieren.
- Restlücken priorisieren und erst nach erfolgreichem Nachtest schließen.
| Prüffeld | Bestanden, wenn |
|---|---|
| Kopien | Produktivstand und mindestens zwei klar identifizierte Sicherungsstände vorhanden sind. |
| Speicher | Mindestens zwei geeignete Speicherarten ohne gemeinsame Einzelkomponente genutzt werden. |
| Standort | Mindestens eine Kopie einen vollständigen Verlust des Hauptstandorts übersteht. |
| Administration | Ein kompromittiertes Produktivkonto nicht alle Sicherungen löschen kann. |
| Zeit | Intervall und Versionstiefe die festgelegten Datenverlust- und Erkennungsziele erfüllen. |
| Schlüssel | Verschlüsselte Sicherungen auch bei Verlust des Quellsystems entschlüsselbar sind. |
| Überwachung | Fehler und ausbleibende Sicherungen Verantwortliche und Vertretung erreichen. |
| Restore | Ein realer Geschäftsfall aus einer getrennten Kopie innerhalb der Zielzeit funktioniert. |
7. Aufbewahrung und Überwachung machen aus Kopien einen verlässlichen Prozess
Die Anzahl der Generationen richtet sich danach, wann ein Fehler erkannt wird. Eine lange Aufbewahrung ohne Kapazitätskontrolle und eine kurze Aufbewahrung ohne Geschäftsbezug sind gleichermaßen problematisch.
| Kontrolle | Zu prüfen | Abweichung bedeutet | Reaktion |
|---|---|---|---|
| Jobstatus | Letzter Lauf, Dauer, Datenmenge und Fehler | Sicherungsstand kann fehlen oder unvollständig sein. | Betroffene Quellen und letzte brauchbare Generation bestimmen. |
| Quellenabdeckung | Neue Freigaben, Datenbanken, Geräte und Cloudbereiche | Neue Geschäftsdaten werden möglicherweise nicht gesichert. | Inventar und Jobumfang aktualisieren, anschließend testen. |
| Kapazität | Freier Raum, Wachstum und Aufbewahrungsdruck | Jobs oder Generationen können vorzeitig ausfallen. | Ursache und Trend bewerten, nicht blind alte Stände löschen. |
| Trennwirkung | Löschrechte, Netzwerkzugang und Offline-Wechsel | Angriff kann mehrere Kopien gleichzeitig erreichen. | Rechte, Zeitfenster oder physische Trennung korrigieren. |
| Schlüsselzugang | Vertretung, Lesbarkeit und Zuordnung | Sicherung ist im Notfall möglicherweise nicht entschlüsselbar. | Getrennten Schlüsselweg erneuern und Probeentschlüsselung durchführen. |
| Restore | Inhalt, Integrität, Rechte, Funktion und Zeit | Joberfolg hat keine belastbare Wiederherstellung ergeben. | Fehlerursache beheben und denselben Test wiederholen. |
| Offsite-Verfügbarkeit | Zugriff bei Ausfall von Büro, Hauptkonto und normalem Internetweg | Standortkopie ist nur theoretisch vorhanden. | Ersatzgerät, Zugang und Rückholweg praktisch prüfen. |
Änderungen am Betrieb lösen eine sofortige Prüfung aus. Neue Teamablage, weitere Datenbank, umgezogener Mandant oder ausgetauschtes NAS werden erst dann abgeschlossen, wenn Sicherungsquelle, Kapazität, Rechte, Dokumentation und Restoretest angepasst sind. So verhindert der Änderungsprozess, dass das Backupinventar schleichend unvollständig wird.
8. Der Restoretest prüft die gesamte Kette bis zum nutzbaren Arbeitsergebnis
Ein einzelnes geöffnetes PDF bestätigt Lesbarkeit, aber keine vollständige Wiederherstellung. Der Test wird nach Datenklasse und Geschäftsprozess gestaffelt.
| Stufe | Test | Aussage |
|---|---|---|
| 1 – Objekt | Einzelne Datei oder Nachricht in getrennten Zielordner zurückholen | Auswahl, Zugriff und grundlegende Lesbarkeit funktionieren. |
| 2 – Struktur | Ordner mit Unterordnern, Versionen und Berechtigungen wiederherstellen | Zusammenhang und Zugriffsmodell bleiben erhalten. |
| 3 – Anwendung | Datenbank oder Anwendung in isolierter Umgebung starten | Datenstand ist technisch konsistent und verwendbar. |
| 4 – Geschäftsfall | Realen Vorgang mit wiederhergestellten Daten vollständig bearbeiten | Benötigte Inhalte, Funktionen und Übergaben stehen bereit. |
| 5 – Ausfallübung | Wiederanlauf ohne Produktivsystem, Hauptkonto oder Hauptstandort simulieren | Trennung, Vertretung, Dokumentation und Zeitziele sind belastbar. |
Vollständiger Restoretest in zwanzig Schritten
- Datenklasse, Geschäftsfall und gewünschte Sicherungskopie auswählen.
- Erwarteten Datenstand, zulässigen Verlust und Zielzeit festhalten.
- Produktive Quelle gegen unbeabsichtigtes Überschreiben schützen.
- Getrenntes, sauberes Ziel mit ausreichender Kapazität bereitstellen.
- Wiederherstellungsanleitung ohne Hilfe des täglichen Administrators öffnen.
- Backupkatalog und passende Generation identifizieren.
- Schlüssel über den dokumentierten unabhängigen Weg beziehen.
- Restore starten und Beginn protokollieren.
- Fehler, Warnungen und übertragene Datenmenge festhalten.
- Wiederhergestellte Objektzahl oder fachliche Summen gegen Referenz prüfen.
- Dateien unterschiedlicher Typen und Zeitpunkte öffnen.
- Versionen, Metadaten und Berechtigungen stichprobenartig prüfen.
- Fachanwendung mit dem wiederhergestellten Bestand starten.
- Repräsentativen Geschäftsfall vollständig durchführen.
- Ergebnis speichern, erneut öffnen und über vorgesehenen Weg ausgeben.
- Technische und fachliche Prüfung getrennt abzeichnen.
- Gesamtdauer und Teilzeiten mit dem Ziel vergleichen.
- Temporäre Zugänge und Testdaten ordnungsgemäß beseitigen.
- Abweichungen mit Ursache, Maßnahme und Termin dokumentieren.
- Korrektur umsetzen und betroffenen Prüfschritt wiederholen.
Der Test wird mit einer Kopie durchgeführt, die im Schaden tatsächlich verwendet werden soll. Wer immer nur das schnelle lokale Backup prüft, weiß weiterhin nicht, ob die Offsite- oder Offline-Kopie abrufbar, entschlüsselbar und innerhalb der benötigten Zeit übertragbar ist. Die Tests rotieren daher zwischen Kopien und Szenarien.
9. Praxisbeispiel: Microsoft 365, lokales NAS und mobile Notebooks gemeinsam sichern
Ein Unternehmen mit sechs Beschäftigten arbeitet in Microsoft 365, speichert große Projektdateien auf einem Büro-NAS und lässt einzelne Beschäftigte mobil arbeiten. Eine einzige 3-2-1-Zählung für „alle Daten“ wäre ungenau, weil Quellen, Änderungsraten und Wiederherstellungswege verschieden sind.
Die Bestandsaufnahme trennt deshalb drei Datenklassen. E-Mail, Kalender und SharePoint-Dokumente werden im Microsoft-365-Mandanten geführt. Große Plan- und Mediendateien liegen ausschließlich auf dem NAS. Auf Notebooks dürfen geschäftliche Daten nur in freigegebenen synchronisierten Ordnern oder definierten lokalen Fachanwendungsverzeichnissen entstehen. Nicht erfasste Desktop- und Downloadordner gelten bis zur technischen Prüfung als Sicherungslücke.
| Datenklasse | Produktivstand | Schnelle Sicherungsebene | Stark getrennte Kopie | Abnahmetest |
|---|---|---|---|---|
| Microsoft-365-Daten | Exchange, SharePoint und OneDrive im Hauptmandanten | Anbieterinterne Versionen und Aufbewahrung für kurze Rücksetzungen | Getrennt administriertes Backup mit unabhängiger Anmeldung | Nachricht, Ordner, Datei, Berechtigung und Metadaten zurückholen |
| NAS-Projektdateien | Redundanter Produktivspeicher im Büro | Lokale Snapshots und tägliches Backup auf eigenständiges Ziel | Verschlüsselte, gegen Produktivadministration getrennte Standortkopie | Vollständiges Testprojekt mit Ordnerstruktur und Rollen wiederherstellen |
| Lokale Notebookdaten | Definierte Fachanwendungsordner und zulässige lokale Arbeitsbestände | Automatisierte Gerätesicherung oder zentrale Übernahme | Geht in die getrennte Sicherung der zentralen Plattform ein | Ersatzgerät einrichten und repräsentativen Arbeitsstand öffnen |
| Konfigurationen | Microsoft-365-, NAS-, Netzwerk- und Geräteeinstellungen | Export nach jeder freigegebenen Änderung | Verschlüsselte technische Anlage im Offline-Notfallpaket | Export zuordnen, lesen und soweit sicher möglich in Testumgebung einspielen |
| Schlüssel und Notfallzugänge | Persönliche Konten im Regelbetrieb | Getrennte Notfallkonten und MFA-Ersatz | Versiegelter oder anderweitig kontrollierter Zugang außerhalb der Hauptidentität | Vertretung meldet sich an und löst protokollierte Sicherheitsmeldung aus |
Die Architektur erfüllt die Merkhilfe nicht durch drei beliebige Speicherorte, sondern durch drei überprüfbare Wirkungen. Die schnelle Ebene behebt alltägliche Lösch- und Versionsfehler. Die getrennte Sicherung übersteht den Ausfall der jeweiligen Produktivplattform. Die Standort- oder Offline-Kopie bleibt verfügbar, wenn Büro oder normale Administration nicht genutzt werden können. Für jede Datenklasse gelten ein eigenes Intervall, eine passende Versionstiefe und ein fachlicher Test.
Monatliche Abnahme des Beispiels in fünfzehn Schritten
- Neue Microsoft-365-Sites, Postfächer und gemeinsam genutzte Bereiche gegen das Backupinventar abgleichen.
- Neue NAS-Freigaben und geänderte Ausschlüsse des Backupjobs prüfen.
- Stichprobe auf zwei mobilen Notebooks nach nicht zentral erfassten Geschäftsdateien durchführen.
- Letzte erfolgreiche Läufe aller Sicherungsketten mit Datum und Datenmenge erfassen.
- Ungewöhnlich kleine, große oder ausgebliebene Datenänderungen untersuchen.
- Freien Speicher und erwartetes Wachstum für die gesamte Aufbewahrungszeit bewerten.
- Mit einem Produktivkonto versuchen, ein ausschließlich dafür angelegtes Testobjekt im getrennten Backup zu löschen.
- Bestätigen, dass der Löschversuch entsprechend dem vorgesehenen Schutz scheitert.
- Schlüsselzugang durch die benannte Vertretung prüfen.
- Eine Microsoft-365-Datei samt früherer Version und Berechtigung wiederherstellen.
- Einen NAS-Projektordner auf ein getrenntes Testziel zurückspielen.
- Eine Datei aus jedem relevanten Dateityp öffnen und fachlich zuordnen.
- Wiederherstellungsdauer und Datenstand gegen die vereinbarten Ziele vergleichen.
- Fehler mit betroffener Datenklasse, Ursache, Verantwortung und Termin dokumentieren.
- Korrekturen durch erneuten Test derselben Sicherungskette abnehmen.
Erst die getrennte Abnahme zeigt, welche Aussage möglich ist. Ein erfolgreicher NAS-Restore belegt nichts über Exchange Online; ein funktionierender Cloudrestore nichts über lokale Fachanwendungsdaten. Der Statusbericht nennt deshalb jede Datenklasse einzeln und kennzeichnet nicht geprüfte Bereiche ausdrücklich. So entsteht keine irreführende Gesamtaussage wie „Backup funktioniert“, wenn nur ein Teil getestet wurde.
Häufige Fragen zur 3-2-1-Backup-Regel
Zählen Produktivdaten, RAID-Spiegel und Snapshot als drei Kopien?
In der Regel nicht als drei unabhängige Kopien. RAID-Spiegel und lokale Snapshots hängen vom selben System, Speicherpool oder Administrationsweg ab. Sie können wertvolle Verfügbarkeits- und Rücksetzebenen sein, benötigen aber zusätzliche getrennte Sicherungen.
Muss eine Offsite-Kopie immer offline sein?
Die klassische 3-2-1-Regel verlangt räumliche Trennung, aber nicht automatisch Offline-Speicherung. Gegen Ransomware und kompromittierte Konten wird deshalb zusätzlich geprüft, ob mindestens eine Kopie physisch, logisch oder administrativ ausreichend getrennt und gegen Veränderung geschützt ist.
Sind zwei Cloudanbieter zwei verschiedene Speicherarten?
Sie können unterschiedliche Plattformen und Standorte bieten, doch die relevante Frage lautet, welche gemeinsamen Konten, Clients, Automationen und Löschrechte bestehen. Die Medienzählung allein beweist keine Unabhängigkeit.
Wie viele Versionen sollten aufbewahrt werden?
So viele und so lange, dass ein Fehler innerhalb der realistischen Erkennungszeit auf einen brauchbaren Stand zurückgesetzt werden kann. Änderungsrate, Datenmenge, Geschäfts- und Aufbewahrungsanforderungen sowie Kosten bestimmen das konkrete Generationenmodell.
Reicht die 3-2-1-Regel als Schutz vor Ransomware?
Nur wenn mindestens eine brauchbare Kopie den Angriff tatsächlich übersteht. Dazu gehören getrennte Rechte, begrenzte Erreichbarkeit, geschützte ältere Generationen, ein geeigneter Wiederherstellungspunkt und ein Restore in einer sauberen Umgebung. Backups verhindern außerdem keinen bereits erfolgten Datenabfluss.
Kann ein kleines Unternehmen die Regel ohne eigene IT-Abteilung umsetzen?
Ja, wenn Umfang, Rollen und Technik passend begrenzt werden. Entscheidend sind ein vollständiges Dateninventar, automatisierte Jobs, klare Wechsel- oder Trennprozesse, persönliche Warnempfänger, getrennte Schlüssel und regelmäßig durchgeführte Wiederherstellungstests.
Weiterführende fachliche Grundlagen
Aus der 3-2-1-Merkregel eine überprüfbare Sicherungsarchitektur machen
fra.digital unterstützt kleine Unternehmen in Frankfurt dabei, Datenklassen und Ausfallziele zu bestimmen, vorhandene Kopien auf gemeinsame Fehlerbereiche zu prüfen und eine passende Backuparchitektur mit getrennten Rechten, geschützten Generationen und dokumentierten Restoretests umzusetzen.
