Wie setze ich die 3-2-1-Backup-Regel mit NAS und Cloud praktisch um, ohne Abo-Wildwuchs und mit verlässlichem Restore?

3-2-1 präzise definieren: Was als Backup zählt (und was nicht) – inklusive typischer Fehlkonzepte wie Sync, RAID und Snapshots

Die 3-2-1-Regel: Begriffe, die in der Praxis oft verwässern

Die 3-2-1-Regel ist nur dann hilfreich, wenn die verwendeten Begriffe streng ausgelegt werden: 3 Kopien der Daten (mindestens ein Primärbestand plus zwei zusätzliche Kopien), auf 2 unterschiedlichen Medientypen oder Speichersystem-Klassen, und mindestens 1 Kopie außer Haus beziehungsweise logisch/physisch so getrennt, dass ein einzelnes Schadereignis nicht alle Kopien gleichzeitig kompromittiert. Viele Setups „fühlen“ sich nach 3-2-1 an, erfüllen es aber nicht, weil sie eher Verfügbarkeit als Wiederherstellbarkeit optimieren.

Entscheidend ist die Eigenschaft „Backup“: Eine Sicherung ist eine zeitpunktbezogene, versionierte Kopie, die sich gezielt und vollständig zurückspielen lässt, auch wenn das Quellsystem gerade defekt, verschlüsselt oder administrativ kompromittiert ist. Daraus folgt: Nicht jedes Duplikat ist ein Backup, und nicht jede „Sicherung“ ist im Ernstfall wiederherstellbar, wenn keine Historie, keine Integritätsprüfung und keine Trennung existiert.

Wann etwas als Backup zählt: Mindestkriterien für echte Wiederherstellbarkeit

Ein Backup ist kein Produktmerkmal, sondern ein überprüfbares Ergebnis. Unabhängig von Werkzeugen sollten mindestens vier Kriterien erfüllt sein: Erstens muss die Sicherung gegen unbeabsichtigte Änderungen geschützt sein (z. B. durch getrennte Berechtigungen oder Unveränderlichkeit). Zweitens braucht es Versionen (Point-in-Time), um auf einen Zustand vor Fehlern oder Malware zurückzugehen. Drittens muss die Wiederherstellung operational möglich sein, also ohne Spezialwissen oder improvisierte Schritte. Viertens muss die Integrität nachweisbar sein, etwa durch Prüfsummen/Blockprüfungen oder regelmäßige Restore-Tests.

• Zeitbezug statt Spiegel: Ein Backup hat definierte Wiederherstellungspunkte (RPO), typischerweise über Rotation/Retention; eine reine 1:1-Kopie ohne Historie ist kein Ersatz.
• Versionierung/Retention: Mindestens mehrere Stände (z. B. „täglich 14“, „monatlich 12“) sind erforderlich; „letzter Stand“ reicht bei schleichender Korruption oder unbemerkter Verschlüsselung nicht.
• Trennung und Zugriffskontrolle: Die Backup-Ziele dürfen nicht mit denselben Admin-Credentials wie die Produktion vollständig lösch- oder überschreibbar sein; getrennte Konten, getrennte Schlüssel, getrennte Verwaltungsebenen sind zentrale Bausteine.
• Wiederherstellbarer Inhalt: Es muss klar sein, ob Dateien, Applikationsdatenbanken, Systemzustände oder ganze Maschinen/Volumes gesichert werden; „irgendwie gesichert“ ist kein definierter Restore.
• Nachweis der Konsistenz: Für Anwendungen mit laufenden Writes (z. B. Datenbanken, VM-Disks) braucht es applikationskonsistente Snapshots/Quiescing oder applikationsseitige Dumps; andernfalls ist der Restore zwar möglich, aber das Ergebnis unbrauchbar.

Typische Fehlkonzepte: Sync, RAID und Snapshots im 3-2-1-Kontext

In der Praxis scheitert 3-2-1 oft an Begriffsmischungen. Synchronisation, Redundanz (RAID) und Snapshots haben jeweils ihren Platz, lösen aber andere Probleme als Backups. Wer sie gleichsetzt, baut Systeme, die im Normalbetrieb „robust“ wirken, im Ernstfall jedoch genau das nicht liefern, was zählt: eine saubere Rückkehr zu einem bekannten, intakten Zustand.

Synchronisation kann Bestandteil einer Backup-Architektur sein, wenn sie gezielt auf ein Backup-Ziel schreibt, dort aber zusätzlich mit Versionierung/Retention und Löschschutz kombiniert wird. RAID ist eine Verfügbarkeitsmaßnahme innerhalb eines Systems, zählt aber nicht als zweite Kopie. Snapshots sind wertvoll, insbesondere für schnelle lokale Wiederherstellungen, erfüllen allein jedoch nicht die Forderung nach einer unabhängig wiederherstellbaren Kopie, solange sie nicht gegen Löschung/Manipulation gehärtet und nicht außerhalb des primären Ausfallradius abgelegt sind.

„Zwei Medien“ und „eine Kopie außer Haus“: Trennschärfe statt Wortklauberei

Der Punkt „2 Medien“ wird häufig zu eng (nur „zwei Festplatten“) oder zu weit (zwei Verzeichnisse auf demselben NAS) interpretiert. Zweck der Anforderung ist, gemeinsame Fehlerdomänen zu reduzieren: unterschiedliche Controller-/Firmware-Risiken, unterschiedliche Dateisysteme, unterschiedliche Zugriffs- und Verwaltungspfade. In modernen Umgebungen kann das „zweite Medium“ auch eine andere Speicherkategorie sein, etwa lokaler NAS-Storage plus objektbasiertes Storage (S3-kompatibel) oder NAS plus Wechselmedium, solange die Fehlerdomänen real getrennt sind.

„1 Kopie außer Haus“ bedeutet nicht zwingend „öffentliches Internet“; es bedeutet, dass ein Ereignis wie Diebstahl, Überspannung, Brand, Wasserschaden oder ein vollständiger Admin-Compromise nicht gleichzeitig alle Kopien zerstört oder unbrauchbar macht. Eine Offsite-Kopie muss daher räumlich getrennt oder zumindest so isoliert sein, dass Produktion und Backup nicht mit denselben Schlüsseln, Token oder Identitäten vollständig verwaltet werden können.

• Unzureichend: Primärdaten und „Backup“ auf demselben NAS, nur in einem anderen Ordner; bei Verschlüsselung oder Fehlbedienung ist beides betroffen.
• Grenzwertig: Snapshots auf demselben Storage ohne separate Admin-Rolle; bei kompromittiertem Admin-Account sind auch Snapshots löschbar.
• Robust: Lokales Backup auf NAS plus Offsite-Kopie in separatem Sicherheitskontext (eigenes Konto, eigene Keys, eigene Aufbewahrungsregeln), idealerweise mit Unveränderlichkeit (z. B. S3 Object Lock im Compliance- oder Governance-Modus, sofern organisatorisch passend).
• Robust (physisch): Zusätzliches Offline-/Air-Gap-Medium, das nur für das Backup-Fenster verbunden ist; der Air Gap reduziert die Angriffsfläche, ersetzt aber nicht automatisch Versionierung und Test-Restores.

Wer 3-2-1 sauber einhalten will, sollte daher jedes Element danach bewerten, welche Ausfallarten es abdeckt: Hardwaredefekt, Bedienfehler, Softwarefehler, Malware/Ransomware, Insider/Account-Übernahme, Standortverlust. Erst wenn die zusätzliche Kopie auch gegen die relevanten gemeinsamen Fehlerdomänen geschützt ist, „zählt“ sie im Sinne der Regel.

Backup-Design für echte Wiederherstellbarkeit: Datei vs. Image, Versionierung, Aufbewahrung und Immutable Backups als Schutz gegen Ransomware

„Wiederherstellbarkeit“ ist eine Design-Eigenschaft, kein Zufallsprodukt. Ein Backup-Konzept ist nur dann belastbar, wenn es sowohl die fachliche Anforderung (welcher Datenstand wird benötigt?) als auch die technische Realität (wie schnell und wie sicher lässt sich dieser Stand zurückholen?) abdeckt. In der Praxis scheitert das häufig an zwei Punkten: Es existiert nur eine einzige Backup-Form (z. B. reine Dateisynchronisation) oder es fehlt die zeitliche und logische Trennung, die bei Ransomware und Bedienfehlern den Unterschied macht.

Datei-Backup vs. Image-Backup: unterschiedliche Ziele, unterschiedliche Risiken

Dateibasierte Backups sichern Dateien und Ordner (inklusive Metadaten, Berechtigungen je nach Tool/Protokoll) und eignen sich besonders für Benutzer- und Projektdaten, geteilte Datenablagen sowie Systeme, bei denen die Rücksicherung einzelner Dateien häufig vorkommt. Image-Backups (Block- oder Volume-basiert) bilden dagegen einen konsistenten Stand eines Systems ab und sind die Grundlage für Bare-Metal-Restores, schnelle Wiederherstellung nach Defekten und saubere Rollbacks nach Fehlkonfigurationen.

Wichtig ist die Kombination: Datei-Backups liefern Granularität (ein Dokument von gestern), Image-Backups liefern Geschwindigkeit (ein ganzer Rechner wieder lauffähig). Wer nur Images erstellt, hat oft unnötig große Datenmengen und trotzdem schlechte Einzeldatei-Restores; wer nur Dateisicherungen nutzt, kann bei Systemausfällen in langwierige Neuinstallationen geraten und riskiert, dass versteckte Abhängigkeiten (Treiber, Bootloader, Konfiguration) fehlen.

Versionierung ist kein Luxus: Schutz vor stillen Fehlern und „sauber verschlüsselten“ Backups

Ohne Versionierung ist ein Backup oft nur eine zeitversetzte Kopie des aktuellen Zustands. Das hilft nicht, wenn Daten unbemerkt beschädigt werden (z. B. defekte Datenbankseiten, Sync-Fehler, versehentliches Überschreiben) oder wenn Ransomware Dateien verschlüsselt und die Sicherung den verschlüsselten Zustand übernimmt. Versionierung bedeutet: mehrere Wiederherstellungspunkte mit definierten Aufbewahrungsregeln, idealerweise mit unveränderlichen Snapshots oder append-only Backup-Formaten.

Praktisch bewährt sind Aufbewahrungspläne, die kurze Intervalle für schnelle Rücksprünge vorhalten (z. B. stündlich/täglich) und längere Intervalle für Compliance und „lange Latenz“ bei Fehlerentdeckung (wöchentlich/monatlich). Entscheidend ist, dass Aufbewahrung nicht nur „wie viele Versionen“, sondern auch „wie lange“ umfasst und dass Löschvorgänge selbst gegen Manipulation abgesichert sind.

• Granularität festlegen: Definieren, ob für bestimmte Datenquellen stündliche Versionen erforderlich sind (z. B. Arbeitsverzeichnisse) oder tägliche Stände ausreichen (z. B. Archivdaten).
• Aufbewahrung als Zeitplan formulieren: Statt „30 Versionen“ besser „30 Tage täglich, 12 Monate monatlich“, damit der Schutz auch bei variabler Backup-Frequenz stabil bleibt.
• Löschkonzept absichern: Backup-Löschungen dürfen nicht allein von kompromittierbaren Admin-Zugängen abhängen; bevorzugt getrennte Rollen, separate Credentials oder zusätzliche Schutzmechanismen im Ziel.

Aufbewahrung und Datenhygiene: Retention, Rotation, legaler Rahmen, Speichereffizienz

Aufbewahrung (Retention) ist ein Spannungsfeld: Zu kurz erhöht das Risiko, zu lang erhöht Kosten und Komplexität und kann datenschutzrechtlich problematisch werden, wenn personenbezogene Daten unnötig lange in Backups verbleiben. Technisch sollte Retention so umgesetzt werden, dass alte Stände automatisiert auslaufen (Rotation), ohne dass dadurch neue Risiken entstehen (z. B. „kompletter Backup-Satz gelöscht“ durch falsche Policy).

Speichereffizienz ist dabei kein Selbstzweck, aber sie beeinflusst, ob Retention in der Praxis durchgehalten wird. Deduplizierung und inkrementelle Verfahren senken den Platzbedarf, erhöhen aber die Abhängigkeit von konsistenter Kettenintegrität. Deshalb gehören Integritätsprüfungen (Prüfsummen, regelmäßige Verify-Jobs) und ein klares Verständnis des Backup-Formats zum Design. Für Images gilt zusätzlich: Applikationskonsistenz (z. B. VSS-Snapshots unter Windows) entscheidet darüber, ob ein Restore nicht nur bootet, sondern auch Datenbanken und Mailstores sauber starten.

Immutable Backups gegen Ransomware: Unveränderlichkeit als zweite Verteidigungslinie

Immutable Backups sind Backups, die nach dem Schreiben für eine definierte Zeit nicht verändert oder gelöscht werden können (WORM-Prinzip). Das adressiert ein zentrales Ransomware-Muster: Angreifer verschlüsseln nicht nur produktive Daten, sondern löschen oder manipulieren Backups. Unveränderlichkeit ersetzt keine Zugriffstrennung, reduziert aber die Auswirkung kompromittierter Konten erheblich.

In der Praxis existieren mehrere technische Ansätze, die jeweils korrekt einzuordnen sind: Unveränderliche Snapshots auf einem Storage, Backup-Repositories mit „Object Lock“ auf S3-kompatiblem Speicher oder speziell gehärtete Backup-Ziele mit append-only Semantik. Wichtig ist, die Schutzwirkung nicht zu überschätzen: Wenn ein Angreifer die Retention-Policy verändern oder Object-Lock-Einstellungen im Ziel verwalten darf, ist „immutable“ nur ein Etikett. Deshalb müssen Policy-Änderungen organisatorisch und technisch abgesichert werden (z. B. getrennte Admin-Rollen, separate Zugangsdaten, MFA wo möglich, Change-Prozess).

• S3-Objektsperre korrekt verstehen: Immutable Speicherung in object-basierten Zielen erfordert typischerweise aktivierte Object-Lock-Funktionalität und eine definierte Retention (Governance/Compliance je nach Implementierung); ohne diese Konfiguration bleibt ein Bucket trotz s3://-Ziel veränderlich.
• Snapshot-Lock nicht mit Backup verwechseln: Unveränderliche Snapshots sind ein starker Baustein, ersetzen aber keine externe Kopie; sie liegen häufig auf demselben System wie die Primärdaten und teilen damit gewisse Ausfallrisiken.
• Backup-Zugänge minimieren: Backup-Jobs sollten mit dedizierten Konten arbeiten, deren Rechte auf genau die benötigten Pfade/Repositories beschränkt sind; für Cloud-Ziele bedeutet das insbesondere restriktive Policies statt „Full Access“ auf *.
• Unveränderlichkeit testbar machen: Es muss nachvollziehbar sein, dass ein Backup-Stand innerhalb der Retention nicht löschbar ist (z. B. Löschversuch mit eingeschränktem Account, Audit-Logs, Policy-Review).

Design-Checks: Woran sich echte Wiederherstellbarkeit im Backup-Design erkennen lässt

Ein praxistaugliches Design lässt sich anhand weniger technischer Fragen prüfen, bevor das erste Desaster eintritt. Dazu gehören: Gibt es getrennte Wiederherstellungspunkte (Versionen) mit nachvollziehbarer Retention? Sind die Backups gegen Manipulation abgesichert (Immutable/Write-Once, getrennte Credentials)? Ist die Wiederherstellung granular genug (Einzeldatei) und schnell genug (Systemimage), um realistische RTO/RPO-Ziele zu treffen? Und: Sind Integritätsprüfungen sowie konsistente Snapshots für kritische Anwendungen Bestandteil der Routine?

Wenn diese Punkte nicht sauber beantwortet werden können, liegt das Problem meist nicht beim Tool, sondern in der Architektur: falsche Backup-Form für den Einsatzzweck, fehlende Versionierung oder eine Retention, die sich mit wenigen Klicks aushebeln lässt. Genau diese Design-Fehler machen aus „Backup vorhanden“ im Ernstfall „Restore unmöglich“.

Konkrete Architektur mit NAS und Offsite-Kopie: Protokolle und Tools (Hyper Backup, rsync, rclone, S3), Trennung, Verschlüsselung, Restore-Tests und Runbooks

Zielbild: Lokales NAS als Backup-Ziel plus getrennte Offsite-Kopie

Eine praxistaugliche 3-2-1-Umsetzung mit NAS und Cloud beginnt mit einer sauberen Rollenverteilung: Das produktive System (PCs/Server/VMs) sichert auf ein lokales Backup-Ziel (NAS). Von dort wird eine zusätzliche Kopie an einen physisch oder logisch getrennten Ort repliziert (Offsite), idealerweise mit objektbasierter Unveränderlichkeit (Object Lock) oder zumindest mit strikt getrennten Zugangsdaten und Aufbewahrungsregeln. Entscheidend ist die Trennung des „Blast Radius“: Ein kompromittiertes Endgerät darf nicht gleichzeitig das NAS-Backup und die Offsite-Kopie löschen oder verschlüsseln können.

In der Praxis funktioniert das zuverlässig, wenn (a) das NAS nicht als bloßes Netzlaufwerk für „Drag-and-drop-Backups“ dient, sondern als dediziertes Backup-Ziel mit Versionierung und Snapshot-Strategie, (b) die Offsite-Stufe mit separaten Identitäten/Schlüsseln arbeitet und (c) die Wiederherstellung als eigener Prozess geplant und getestet wird, statt als theoretische Option zu gelten.

Protokolle und Tools richtig einordnen: Hyper Backup, rsync, rclone, S3

Die Werkzeugwahl sollte sich weniger an Marken orientieren als an Eigenschaften: Transport (wie werden Daten übertragen), Repository-Format (wie werden Versionen abgelegt), Integrität (wie werden Bitfehler und Manipulation erkannt) und Wiederherstellungsweg (wie kommt man ohne Spezial-Umgebung wieder an die Daten). Viele NAS-Ökosysteme bieten integrierte Backup-Apps wie Hyper Backup, die inkrementelle Versionen, Zeitpläne, clientseitige Verschlüsselung und Integritätsprüfungen bündeln. Das ist praktikabel, solange Export-/Restore-Pfade klar dokumentiert sind.

rsync ist ein robustes Dateisynchronisationswerkzeug mit Delta-Transfer. Es ist besonders geeignet, um Dateibäume effizient zu spiegeln oder inkrementelle Kopien auf ein zweites System zu übertragen. Für „echte“ Versionierung braucht es allerdings ein Repository-Konzept (z. B. Hardlink-Rotation, Snapshotting auf Dateisystemebene oder ein Backup-Tool, das Versionen verwaltet). rclone ist eine universelle Datentransfer-Schicht zu Cloud-Speichern (inklusive S3-kompatibler Ziele) und eignet sich, um Daten in Object Storage zu kopieren oder zu replizieren, vorausgesetzt, man gestaltet Berechtigungen und Retention konsequent. S3-kompatibler Object Storage ist für Offsite besonders interessant, weil sich serverseitige Aufbewahrung (Retention) und bei geeigneter Konfiguration Unveränderlichkeit (Object Lock) erzwingen lassen, unabhängig davon, ob ein Client kompromittiert wird.

• Hyper Backup (als Konzept): Repository mit Versionen und Integritätsprüfung, oft inkl. clientseitiger Verschlüsselung; Restore erfolgt typischerweise über ein Restore-Tool oder direkt aus dem Repository, je nach Format.
• rsync (Transport + Abgleich): Effizient für Dateibäume; in Kombination mit Snapshots (z. B. Btrfs) entsteht Versionierung, ohne dass rsync selbst ein Backup-Repository verwaltet.
• rclone (Cloud-Transport): Brücke von Dateisystem zu Objekt- oder Cloud-Backends; relevant sind getrennte Credentials, serverseitige Retention und klare Restore-Prozeduren (Download, Mount, Rehydrierung).
• S3-kompatibler Speicher (Zielsystem): Geeignet für Offsite und Immutability (abhängig von Anbieter/Deployment); zwingend sind Bucket-Policies, separate Zugänge und getestete Restore-Pfade.

Trennung (Separation): Identitäten, Netzpfade, Admin-Zugänge und Löschschutz

„Offsite“ ist nicht automatisch „getrennt“. In der Praxis scheitert 3-2-1 oft daran, dass dieselben Admin-Zugänge, derselbe Passwortmanager-Account oder dieselbe Netzwerkdomäne sowohl produktive Systeme als auch NAS und Cloud steuern. Ransomware nutzt genau diese Pfade: gemountete Shares, gespeicherte Zugangsdaten, API-Tokens und administrative Sessions. Ziel ist, dass ein einzelner kompromittierter Kontext nicht gleichzeitig alle Kopien zerstören kann.

Bewährt sind getrennte Dienstkonten (least privilege), getrennte Verwaltungsoberflächen (z. B. NAS-Admin nicht identisch mit Backup-Operator), und wenn möglich ein logisch separater Management-Zugang. Für Offsite sollten API-Keys nur das minimale Recht besitzen (z. B. Schreiben in einen Bucket/Prefix; Löschen nur, wenn es organisatorisch nötig ist und nicht zur Umgehung von Retention/Immutability genutzt werden kann). Wenn ein Ziel Unveränderlichkeit unterstützt, sollte diese serverseitig erzwungen werden, sodass auch ein kompromittierter Client nicht durch „Delete“ oder verkürzte Aufbewahrung die Daten sofort entfernt.

• Getrennte Credentials: NAS-Backup-User ohne Adminrechte; Offsite-Account/Tokens getrennt von NAS-Admin und getrennt vom Produktivsystem (keine Wiederverwendung von Secrets).
• Kein dauerhafter Mount als Laufwerk: Backups nicht über permanent gemountete SMB/NFS-Laufwerke der Clients ablegen; stattdessen Pull-Modelle oder agentbasierte Pushs mit minimalen Rechten nutzen.
• Trennung von Netzwerkpfaden: Backup-Ziel per dediziertem VLAN/Firewall-Regeln erreichbar machen; Management-Zugriff (Admin-GUI/SSH) auf separate Quellnetze beschränken.
• Löschschutz durch Retention: Auf Offsite-Ebene Aufbewahrung erzwingen (z. B. S3 Object Lock, sofern verfügbar) und sicherstellen, dass verwendete Schlüssel die Retention nicht reduzieren oder Object-Lock-Einstellungen verwalten dürfen.

Verschlüsselung: In Transit, At Rest und Schlüsselverwaltung ohne Selbstsabotage

Verschlüsselung ist nur dann ein Sicherheitsgewinn, wenn Schlüssel und Wiederherstellung zusammen gedacht werden. Transportverschlüsselung (z. B. TLS bei S3-APIs oder SSH bei rsync) ist Standard und schützt gegen Abhören und Manipulation unterwegs. Für Offsite ist zusätzlich Verschlüsselung „at rest“ relevant: entweder serverseitig im Zielsystem oder clientseitig vor dem Upload. Clientseitige Verschlüsselung reduziert den Trust in den Cloud-Betreiber, erhöht aber die Anforderungen an Schlüsselmanagement und Runbooks.

Konsequent ist: Schlüsselmaterial gehört nicht ausschließlich auf das NAS, das selbst von Ransomware oder Fehlbedienung betroffen sein kann. Gleichzeitig darf es nicht nur in Köpfen oder in ungetesteten „Notizzetteln“ existieren. Praktisch sind getrennte, dokumentierte Aufbewahrungsorte (z. B. Passworttresor mit Notfallzugriff, versiegelte Recovery-Codes im Tresor) und klare Verantwortlichkeiten. Bei clientseitiger Verschlüsselung muss der Restore-Prozess ausdrücklich den Zugriff auf Schlüssel, Passphrasen und eventuell benötigte Konfigurationsdateien enthalten.

• Transport absichern: rsync -e ssh für Übertragungen über unsichere Netze; S3-Zugriffe ausschließlich via https:// (TLS) und mit Zeit-/IP-Restriktionen, sofern verfügbar.
• Clientseitig verschlüsseln, wenn der Offsite-Ort nicht voll vertraut ist: Bei Tools mit Verschlüsselungsfunktion die Parameter, Schlüsselableitung und das Restore-Werkzeug im Runbook festhalten; Schlüssel getrennt vom Backup-Repository lagern.
• Schlüssel-Wiederherstellung testen: Mindestens quartalsweise eine Entschlüsselung in einer Testumgebung durchführen, um Tippfehler, gesperrte Accounts oder fehlende Dateien früh zu entdecken.

Restore-Tests und Runbooks: Wiederherstellbarkeit nachweisen statt hoffen

Ein Backup ist erst dann belastbar, wenn die Wiederherstellung unter realistischen Bedingungen geübt wurde: nicht nur „Datei geöffnet“, sondern mit den gleichen Zugangsdaten, dem gleichen Netzwerkpfad, den gleichen Verschlüsselungs- und Retention-Eigenschaften wie im Ernstfall. Restore-Tests sollten zwei Perspektiven abdecken: schnelle lokale Wiederherstellung (NAS) und Worst-Case-Wiederherstellung aus Offsite (zeitaufwendig, Bandbreite, Rehydrierung, Zugriff auf Schlüssel). Wichtig ist ein reproduzierbarer Ablauf, der auch bei Personalwechsel funktioniert.

Ein Runbook ist dabei kein Roman, sondern eine präzise Handlungsanleitung mit konkreten Entscheidungen: Welche Systeme werden zuerst wiederhergestellt, welche Abhängigkeiten existieren (DNS, Identität, Datenbanken), welche RTO/RPO sind realistisch, und wie wird verifiziert, dass Daten korrekt sind. Ergänzend sollten Prüfschritte definiert werden, die Manipulation und stille Bitfehler aufdecken (Integritätsprüfungen des Backup-Tools, Prüfsummen-Checks, Applikations-Selbsttests). Die Ergebnisse der Restore-Tests gehören als Protokoll zur Backup-Dokumentation, inklusive Dauer, gefundenen Problemen und Korrekturmaßnahmen.

• Minimaler Restore-Test (monatlich): Einzeldatei plus Ordnerstruktur aus dem NAS-Repository in ein separates Testverzeichnis wiederherstellen und mit Prüfsummen/Anwendungsöffnung validieren; Testpfad z. B. /restore-tests/2026-01/.
• Offsite-Drill (vierteljährlich oder halbjährlich): Restore ausschließlich aus der Offsite-Kopie durchführen (nicht über das NAS), inklusive Download/Export und Entschlüsselung; Bandbreitenannahmen dokumentieren und Ist-Zeit messen.
• Runbook-Pflichtpunkte: Kontaktliste, Credential- und Schlüsselzugriff (Notfallpfad), Reihenfolge der Wiederherstellung, Verifikationsschritte, Abbruchkriterien, und Ablageort der Logs (z. B. \\fileserver\runbooks\backup-restore.pdf oder ein internes Wiki mit Offline-Export).
• Manipulationsresistenz prüfen: Stichprobe, ob Offsite-Objekte/Versionen innerhalb der Retention nicht löschbar sind (ohne Policies zu ändern); Nachweis im Testprotokoll festhalten.