Ein Backup ist nur dann nützlich, wenn es verfügbar bleibt, sobald das ursprüngliche System nicht verwendet werden kann. Dieses einfache Prinzip ist der Grund, warum ein Offsite-Backup zu jeder ernsthaften Disaster-Recovery-Strategie gehört. Eine zweite Kopie auf demselben Server, NAS oder in demselben Rack kann bei versehentlichem Löschen helfen. Sie bietet jedoch wenig Schutz, wenn ein Brand, Diebstahl, eine Überschwemmung, ein Ransomware-Vorfall oder ein kompromittiertes Administratorkonto die gesamte Umgebung betrifft.
Ein Offsite-Backup schafft eine physische und logische Distanz zwischen den Produktionsdaten und ihrer Wiederherstellungskopie. Für ein Unternehmen kann diese Trennung den Unterschied ausmachen zwischen der Wiederherstellung eines Servers innerhalb weniger Stunden und einem tagelangen Neuaufbau anhand unvollständiger Aufzeichnungen. Sie verändert außerdem die Sichtweise auf die Backup-Strategie: weg von einer routinemäßigen Aufgabe zum Kopieren von Dateien, hin zu einer betrieblichen Kontrolle zur Unterstützung der Geschäftskontinuität.
Das ist besonders für Agenturen und kleine Unternehmen relevant, die ihre Web-, Anwendungs-, Datenbank-, Virtualisierungs- oder kundenorientierten Server selbst verwalten. Diese Organisationen verfügen möglicherweise nicht über ein großes Infrastrukturteam, sind aber denselben Ausfallarten ausgesetzt wie größere Unternehmen. Wenn ein Produktionsserver unter der Kontrolle des Kunden steht, müssen seine Backups genauso sorgfältig geschützt werden wie der Server selbst.
Was ein Offsite-Backup tatsächlich bedeutet
Ein Offsite-Backup ist eine Kopie von Geschäftsdaten, die an einem anderen physischen Ort als das geschützte System gespeichert wird. Die Kopie kann sich in einem anderen Gebäude, einem separaten Rechenzentrum oder einer dedizierten Speicherumgebung in einer anderen Region befinden. Entscheidend ist nicht nur die Entfernung in Kilometern. Das Backup sollte von der Produktionsumgebung getrennt sein, damit ein einzelner Vorfall nicht ohne Weiteres beide Kopien zerstören, verschlüsseln oder löschen kann.
Ein typischer Server-Backup-Prozess erfasst ausgewählte Daten, den Systemstatus, Anwendungen oder vollständige Maschinenabbilder nach einem festgelegten Zeitplan. Das daraus entstehende Backup wird vom Produktionsstandort weg übertragen, meist über eine verschlüsselte Verbindung. Anschließend wird es für einen definierten Aufbewahrungszeitraum gespeichert und bei Bedarf für die Wiederherstellung bereitgestellt.
Ein gutes Offsite-Backup zeichnet sich durch mehrere klar unterscheidbare Eigenschaften aus:
- Standorttrennung: Das Backup ist nicht von denselben Räumlichkeiten, demselben Rack, derselben Stromversorgung oder demselben lokalen Speicher wie die Produktion abhängig.
- Zugriffstrennung: Gewöhnliche Serveradministratoren können nicht automatisch jede Wiederherstellungskopie ändern oder entfernen.
- Vertraulichkeit: Die Daten werden bei der Übertragung und im Ruhezustand verschlüsselt, wobei die Kontrolle über den Entschlüsselungsschlüssel eindeutig geregelt ist.
- Aufbewahrung: Backups bleiben lange genug verfügbar, um Bedienfehler, verspätete Entdeckungen sowie gesetzliche oder vertragliche Anforderungen abzudecken.
- Wiederherstellbarkeit: Die Organisation weiß, wie sie die Daten abruft, und hat getestet, ob das wiederhergestellte System nutzbar ist.
Diese Eigenschaften hängen zusammen, sind aber nicht austauschbar. Eine Offsite-Kopie, die ein Administrator mit denselben Zugangsdaten wie auf dem Produktionsserver löschen kann, ist zwar geografisch getrennt, aber nicht gut isoliert. Ein stark verschlüsseltes Backup, das niemand entschlüsseln kann, ist in gewisser Hinsicht sicher, in einer Krise jedoch nutzlos. Eine lange Aufbewahrungsdauer gleicht nicht aus, dass ein Backup nie wiederhergestellt wurde und möglicherweise unvollständig ist.
Warum eine lokale Kopie allein nicht ausreicht
Lokale Backups sind weiterhin wertvoll. Sie können einen schnellen Wiederherstellungsweg für eine gelöschte Datei, eine beschädigte Datenbank oder eine ausgefallene Festplatte bieten. Die Wiederherstellung aus einem Speicher am selben Standort ist oft schneller, als ein großes Serverabbild über eine Internetverbindung herunterzuladen. Lokale Kopien können daher eine wichtige Ebene einer umfassenderen Backup-Strategie bilden.
Das Problem beginnt, wenn die lokale Kopie als vollständiger Disaster-Recovery-Plan betrachtet wird. Produktionssysteme und lokale Backups teilen häufig dieselben Risiken:
Hardwareausfall
Festplatten fallen aus, RAID-Arrays verschlechtern sich und Backup-Appliances können Defekte entwickeln. Wenn Produktions- und Backupdaten auf dasselbe Speichersubsystem angewiesen sind, kann ein einzelner Hardwarevorfall beide betreffen. Selbst wenn sich das Backup auf einem separaten lokalen Gerät befindet, können ein Stromereignis oder ein Problem mit der Umgebung sowohl den Produktionsserver als auch das Gerät mit den Wiederherstellungsdaten beschädigen.
Diebstahl und physischer Verlust
Ein Server und seine lokale Backup-Appliance sind bei einem Einbruch attraktive Ziele. Tragbare Laufwerke lassen sich besonders leicht entfernen, und ein Angreifer muss die Daten nicht verstehen, wenn die Hardware verkauft oder als Druckmittel verwendet werden kann. Physischer Verlust wirft außerdem Fragen zur Vertraulichkeit auf, wenn Backups nicht ordnungsgemäß verschlüsselt sind.
Brand, Überschwemmung und andere standortweite Ereignisse
Ein Brand, ein geplatztes Rohr, ein schwerer Sturm oder die Evakuierung eines Gebäudes kann jedes Gerät in einem Serverraum gleichzeitig unzugänglich machen. Ein lokales Backup kann vollkommen intakt und dennoch nicht erreichbar sein, wenn das Gebäude nicht betreten werden darf. Disaster Recovery geht davon aus, dass der primäre Standort selbst nicht verfügbar sein kann, und nicht nur eine einzelne Festplatte ausfällt.
Ransomware und zerstörerische Schadsoftware
Ransomware zielt häufig auf angeschlossene Speicher, eingebundene Laufwerke und Backup-Verwaltungsoberflächen. Wenn ein lokales Backup ständig eingebunden und über ein kompromittiertes Administratorkonto erreichbar ist, kann die Schadsoftware es gemeinsam mit den Produktionsdaten verschlüsseln oder löschen. Ein Backup, das lediglich als weiteres beschreibbares Ziel in derselben Umgebung existiert, ist keine zuverlässige letzte Verteidigungslinie.
Kompromittierte Administratoren und gestohlene Zugangsdaten
Nicht jeder zerstörerische Vorfall beginnt mit Schadsoftware. Ein gestohlenes privilegiertes Passwort, ein missbrauchtes Konto oder ein versehentlich ausgeführter Befehl kann Produktionsdaten und lokale Kopien entfernen. Backups benötigen Schutz vor denselben Zugangsdaten und Vertrauensbeziehungen, die die von ihnen geschützten Systeme steuern. Andernfalls kann ein Angreifer, der den Server kontrolliert, auch die Wiederherstellungsoptionen kontrollieren.
Beim Vergleich lokaler und ausgelagerter Backups innerhalb einer Disaster-Recovery-Strategie lautet die praktische Frage daher nicht, ob lokale Backups nützlich sind. Entscheidend ist, ob die Organisation mindestens eine Kopie besitzt, die außerhalb der Reichweite eines standortweiten Vorfalls und einer kompromittierten Produktionsumgebung bleibt.
Lokale, ausgelagerte und cloudbasierte Kopien im Vergleich
Die Begriffe lokal, ausgelagert und cloudbasiert beschreiben unterschiedliche Aspekte eines Backup-Konzepts. Sie sollten nicht als gegenseitig ausschließende Kategorien verstanden werden. Auch der Begriff „Cloud“ allein beweist nicht, dass ein Backup isoliert oder wiederherstellbar ist.
Lokales Backup
Ein lokales Backup wird in der Nähe des geschützten Servers gespeichert, etwa auf einer zweiten Festplatte, einem NAS, einem Wechsellaufwerk oder einer Backup-Appliance in denselben Räumlichkeiten. Der wichtigste Vorteil ist die Geschwindigkeit. Eine lokale Wiederherstellung kann sinnvoll sein, wenn ein Unternehmen schnell eine einzelne Datei oder eine aktuelle Datenbankkopie benötigt.
Die Schwächen liegen in der Gefährdung und Abhängigkeit. Lokale Kopien können durch Feuer, Diebstahl, Überschwemmung, Stromprobleme, Ransomware und kompromittierte Administratorkonten betroffen sein. Außerdem werden sie bei einem Standortwechsel oder Hardware-Upgrade möglicherweise übersehen. Ein lokales Backup sollte am besten als schnelle Wiederherstellungsebene und nicht als alleiniger Disaster-Recovery-Mechanismus betrachtet werden.
Offsite-Backup
Ein Offsite-Backup wird außerhalb des Produktionsstandorts gespeichert und sollte durch separate Zugriffskontrollen geschützt sein. Es ist für Szenarien ausgelegt, in denen der lokalen Umgebung nicht vertraut werden kann oder sie nicht erreichbar ist. Ein gut konzipierter Offsite-Service kann kleinen Organisationen außerdem eine strukturierte Möglichkeit bieten, Aufbewahrung, Verschlüsselung und Wiederherstellungsverfahren zu verwalten, ohne selbst eine zweite Einrichtung aufbauen zu müssen.
Ein Offsite-Backup wird je nach verfügbarer Bandbreite, Datenmenge und Wiederherstellungsmethode möglicherweise langsamer wiederhergestellt als eine lokale Kopie. Dieser Nachteil ist akzeptabel, wenn die Alternative darin besteht, nach einem standortweiten Vorfall über keine nutzbare Kopie zu verfügen. Der Service sollte im Hinblick auf die erforderliche Wiederherstellungszeit ausgewählt und nicht nur anhand seines Speicherorts beurteilt werden.
Cloudbasiertes Backup
Cloudbasiertes Backup bedeutet, dass die Backupdaten mithilfe einer Infrastruktur gespeichert werden, auf die über ein Netzwerk zugegriffen wird, häufig in einem vom Anbieter betriebenen Rechenzentrum. Es kann sich dabei um ein Offsite-Backup handeln, aber beide Begriffe sind nicht identisch. Ein Cloud-Backup kann schlecht isoliert sein, wenn Produktionszugangsdaten es löschen können, wenn seine Aufbewahrung ungeschützt geändert werden kann oder wenn sich alle Kopien innerhalb derselben Ausfalldomäne befinden.
Bei der Bewertung eines Cloud- oder Hosting-Backup-Services sollte man fragen, wo die Daten gespeichert werden, wer darauf zugreifen kann, wie Verschlüsselungsschlüssel verwaltet werden, ob Backups unveränderbar sind und wie die Wiederherstellung erfolgt. „In der Cloud“ ist ein Bereitstellungsmodell, aber keine vollständige Sicherheitsbeschreibung.
Wie der 3-2-1-Ansatz die Disaster Recovery unterstützt
Der 3-2-1-Ansatz bleibt eine nützliche Grundlage für Backup-Strategien:
- 3 Datenkopien: die Produktionskopie plus mindestens zwei Backup-Kopien.
- 2 unterschiedliche Speicher- oder Medientypen: Dadurch wird die Abhängigkeit von einer Technologie oder Ausfallart reduziert.
- 1 Kopie außerhalb des Standorts: Dies schützt vor dem Verlust des primären Standorts.
Das Modell ist bewusst einfach gehalten. Es ermutigt Organisationen, nicht jede Kopie auf demselben Server, Festplatten-Array oder in denselben Räumlichkeiten abzulegen. Außerdem lässt es Raum für fortgeschrittene Kontrollen wie unveränderbaren Speicher, Offline-Kopien und getrennte administrative Identitäten.
Eine moderne Auslegung ergänzt häufig eine weitere „1“: Eine Kopie sollte isoliert oder unveränderbar sein. Unveränderbarkeit bedeutet, dass Backupdaten während eines definierten Schutzzeitraums nicht geändert oder gelöscht werden können, selbst wenn ein Konto oder ein Produktionsserver kompromittiert wurde. Das ist besonders für die Widerstandsfähigkeit gegen Ransomware und für Vorfälle wichtig, bei denen ein Angreifer Beweise löschen oder Wiederherstellungspunkte entfernen will.
Unveränderbarkeit bedeutet nicht, dass jedes Backup dauerhaft aufbewahrt wird. Sie gilt normalerweise für das konfigurierte Aufbewahrungsfenster. Sobald dieses endet, kann das Backup gemäß der Richtlinie ablaufen. Deshalb müssen Aufbewahrungseinstellungen bewusst festgelegt werden, statt einen bequemen Standardwert zu übernehmen.
RPO und RTO: Wiederherstellungsziele in Backup-Entscheidungen umsetzen
Backup-Häufigkeit und Wiederherstellungsdesign sollten auf den geschäftlichen Anforderungen basieren. Zwei Kennzahlen helfen dabei, diese Anforderungen in praktische Entscheidungen zu übersetzen: das Recovery Point Objective oder RPO und das Recovery Time Objective oder RTO.
Recovery Point Objective
Das RPO beschreibt, wie viele aktuelle Daten ein Unternehmen nach einem Vorfall maximal verlieren kann. Ein RPO von 24 Stunden kann bedeuten, dass die Organisation den Verlust eines Tages an Transaktionen oder Aktualisierungen akzeptiert. Ein RPO von einer Stunde erfordert eine häufigere Erfassung und Übertragung. Ein in Minuten gemessenes RPO kann eine andere Architektur erfordern als herkömmliche zeitgesteuerte Server-Backups.
Das RPO ist nicht lediglich eine Einstellung in einer Backup-Konsole. Es hängt davon ab, wie oft Backups ausgeführt werden, ob die Jobs erfolgreich abgeschlossen werden, wie schnell Daten übertragen werden können und ob die Quelldaten konsistent sind. Ein Datenbank-Backup, das erstellt wird, während noch Transaktionen geschrieben werden, liefert möglicherweise keinen sauberen Wiederherstellungspunkt, wenn die Anwendung nicht angemessen behandelt wird.
Recovery Time Objective
Das RTO beschreibt, wie schnell ein Service nach einem Ausfall wiederhergestellt werden muss. Eine kleine interne Anwendung kann möglicherweise einen Tag Ausfallzeit tolerieren. Eine Agentur, die Kundenanwendungen hostet, oder ein Unternehmen, das Bestellungen verarbeitet, benötigt vielleicht ein deutlich kürzeres Wiederherstellungsfenster.
Das RTO beeinflusst den Backup-Typ und den Wiederherstellungsprozess. Die Wiederherstellung eines vollständigen Serverabbilds kann schneller sein als der Neuaufbau eines Betriebssystems und die erneute Installation jeder Anwendung, erfordert aber weiterhin geeignete Zielinfrastruktur. Ein Service mit einem anspruchsvollen RTO benötigt möglicherweise vorab geplante Ersatzkapazitäten, dokumentierte DNS- oder Netzwerkänderungen und ein getestetes Verfahren, um Abhängigkeiten in der richtigen Reihenfolge wiederherzustellen.
RPO und RTO sollten pro Service festgelegt und nicht für die gesamte Organisation geschätzt werden. Eine Datenbank, eine Website, ein Dateiserver und ein internes Überwachungssystem können jeweils unterschiedliche Prioritäten haben. Die Auflistung dieser Prioritäten hilft einem kleinen Unternehmen, seine Anstrengungen dort einzusetzen, wo Ausfallzeit und Datenverlust den größten Schaden verursachen würden.
Die Aufbewahrung ist Teil des Wiederherstellungsdesigns
Die Aufbewahrung bestimmt, wie weit zurück eine Organisation wiederherstellen kann. Sie sollte mehr berücksichtigen als nur den Zeitraum zwischen zwei Backups. Unternehmen entdecken Datenbeschädigungen, unbefugte Änderungen oder versehentliches Löschen häufig erst Tage oder Wochen nach dem ursprünglichen Ereignis. Wenn das Backup-System nur die letzten Kopien behält, kann jeder Wiederherstellungspunkt dasselbe Problem enthalten.
Eine sinnvolle Aufbewahrungsrichtlinie berücksichtigt:
- Wie lange ein versehentliches Löschen unbemerkt bleiben kann.
- Wie lange Schadsoftware vor ihrer Entdeckung unbemerkt aktiv bleiben kann.
- Vertragliche, gesetzliche oder kundenbezogene Anforderungen.
- Wie alt die Daten sein müssen, die für finanzielle, betriebliche oder rechtliche Untersuchungen benötigt werden.
- Die Speicher- und Übertragungskosten für die Aufbewahrung älterer Wiederherstellungspunkte.
- Ob unterschiedliche tägliche, wöchentliche oder monatliche Wiederherstellungspunkte erforderlich sind.
Die Aufbewahrung sollte auch zur Art des Servers passen. Ein Entwicklungsserver benötigt möglicherweise nur kurzlebige Wiederherstellungspunkte, während eine Produktionsdatenbank oder ein Repository für Kundenprojekte eine längere Historie erfordern kann. Die Richtlinie sollte in klarer Sprache dokumentiert werden, damit die für die Wiederherstellung verantwortliche Person versteht, was „30 Tage“ oder „12 Monate“ tatsächlich bedeutet.
Unveränderbarkeit macht das Aufbewahrungsfenster aussagekräftiger, weil sie verhindert, dass Wiederherstellungspunkte während des benötigten Zeitraums verändert werden. Sie macht Überwachung jedoch nicht überflüssig. Ein Backup-Job kann technisch erfolgreich abgeschlossen werden, obwohl ein erforderliches Volume ausgeschlossen, ein falscher Zeitplan verwendet oder eine Datenmenge erzeugt wurde, die nicht wiederhergestellt werden kann.
Verschlüsselung und die Frage, wer den Schlüssel besitzt
Offsite-Daten sollten sowohl vor unbefugter Offenlegung als auch vor Zerstörung geschützt werden. Verschlüsselung trägt dazu bei, dass eine gestohlene Festplatte, eine abgefangene Übertragung oder ein unrechtmäßig aufgerufener Speicherort keine Geschäfts- oder Kundeninformationen preisgibt.
Es gibt zwei getrennte Fragen zur Verschlüsselung. Erstens: Sind die Daten verschlüsselt, während sie vom Server des Kunden zum Backup-Speicherort übertragen werden? Zweitens: Sind sie während der Speicherung verschlüsselt? Beide Aspekte sind wichtig. Eine Verschlüsselung während der Übertragung schützt kein gespeichertes Backup, das für unbefugte Betreiber lesbar ist. Eine Verschlüsselung im Ruhezustand schützt wiederum keine Daten, die über eine unsichere Verbindung übertragen werden.
Der Besitz des Schlüssels ist ebenso wichtig. Wenn ein Anbieter den einzigen Entschlüsselungsschlüssel besitzt, hat der Kunde möglicherweise nur begrenzte Kontrolle über die Vertraulichkeit. Wenn der Kunde den Schlüssel kontrolliert und der Anbieter ihn nie besitzt, wird die Gefährdung reduziert. Gleichzeitig steigt jedoch die Verantwortung: Der Kunde muss den Schlüssel schützen und sicherstellen, dass autorisierte Mitarbeiter ihn bei Bedarf für die Wiederherstellung verwenden können.
Das schafft ein praktisches Gleichgewicht. Die Kontrolle über den Schlüssel kann eine stärkere Trennung zwischen Backup-Service und geschützten Daten unterstützen, doch ein verlorener Schlüssel kann die Wiederherstellung unmöglich machen. Das Schlüsselmanagement sollte daher dokumentiert, der Zugriff eingeschränkt und ein Wiederherstellungsverfahren festgelegt werden, in dem erläutert wird, wie das autorisierte Team den Schlüssel im Notfall erhält und verwendet. Verschlüsselung ersetzt keine betriebliche Planung.
Warum Unveränderbarkeit und Isolation die Ransomware-Wiederherstellung verändern
Bei der Ransomware-Wiederherstellung geht es nicht nur darum, eine aktuelle Kopie zu besitzen. Entscheidend ist, eine Kopie zu haben, die ein Angreifer nach der Übernahme der Produktionsumgebung nicht verschlüsseln oder löschen konnte.
Isolation begrenzt die Wege, über die ein Angreifer Backupdaten erreichen kann. Sinnvolle Maßnahmen sind separate Zugangsdaten, eingeschränkter Netzwerkzugriff, begrenzte Verwaltungsoberflächen und Speicher, der vom geschützten Server aus nicht kontinuierlich beschreibbar ist. Diese Kontrollen verringern die Wahrscheinlichkeit, dass ein kompromittiertes Administratorkonto jede Ebene des Wiederherstellungssystems beeinflussen kann.
Unveränderbarkeit ergänzt eine Regel, die Änderungen an Backupobjekten für einen definierten Zeitraum verhindert. Wenn ein Angreifer versucht, aktuelle Wiederherstellungspunkte zu löschen, kann die Speicherrichtlinie sie bis zum Ende der Aufbewahrungsfrist bewahren. So erhält die Organisation Zeit, den Vorfall zu erkennen, ihn einzudämmen und einen sauberen Wiederherstellungspunkt auszuwählen.
Keine der beiden Kontrollen garantiert allein eine erfolgreiche Wiederherstellung. Ein Angreifer kann die Quelle kompromittieren, bevor das Backup erstellt wird, oder die Organisation stellt fest, dass das Backup eine kritische Anwendung nicht erfasst hat. Wiederherstellungstests sind deshalb unerlässlich. Ein Unternehmen sollte wissen, welche Wiederherstellungspunkte verfügbar sind, wie es darauf zugreift, wie der Verschlüsselungsschlüssel bereitgestellt wird und wie der wiederhergestellte Server vor der erneuten Verbindung mit der Produktion validiert wird.
Was das für Agenturen und kleine Unternehmen bedeutet
Agenturen und kleine Unternehmen verwalten ihre Infrastruktur häufig mit begrenztem Personal. Eine Person kann für Kundenprojekte, Server-Updates, Benutzerzugriffe, Überwachung und Backup-Warnungen zuständig sein. Die technische Umgebung kann ein Hosting-Control-Panel, virtuelle Maschinen, Datenbanken, Quellcode-Repositories, Dateifreigaben und mehrere kundenorientierte Services umfassen.
Diese Konzentration der Verantwortung birgt praktische Risiken. Ein Backup-Job wird möglicherweise einmal eingerichtet und anschließend ignoriert. Warnungen gehen vielleicht an ein altes Postfach. Ein ehemaliger Auftragnehmer kann weiterhin Zugriff haben. Ein lokales NAS ist möglicherweise voll. Ein Serverabbild kann vorhanden sein, ohne dass jemand weiß, ob es auf Ersatzhardware wiederhergestellt werden kann.
Ein Offsite-Backup hilft, indem es die Wiederherstellungskopie von der täglichen Administration des Servers trennt. Es beseitigt nicht den Bedarf an kompetenter Verwaltung, kann aber die Zahl der Single Points of Failure reduzieren. Außerdem kann eine Agentur glaubwürdiger antworten, wenn ein Kunde fragt, wie seine Anwendung, Datenbank oder Projektdaten nach einem schweren Vorfall wiederhergestellt würden.
Für Unternehmen, die Produktionsserver betreiben, besteht der erste Schritt darin, festzustellen, was in welcher Reihenfolge wiederhergestellt werden muss. Eine Webanwendung kann von einer Datenbank, Objektspeicher, DNS-Einträgen, Geheimnissen, Zertifikaten und externen Integrationen abhängen. Ein Backup, das nur die Webdateien wiederherstellt, stellt den Service möglicherweise nicht wieder her. Der Wiederherstellungsplan sollte diese Abhängigkeiten dokumentieren und zwischen Datenwiederherstellung und vollständiger Service-Wiederherstellung unterscheiden.
Safenix ist für Server vorgesehen, die vom Kunden kontrolliert werden. Der Service bietet Offsite-Backups für Geschäftsserver, wobei die Daten in Deutschland gespeichert, mit einem Schlüssel verschlüsselt werden, den Safenix niemals besitzt, und für die Dauer des konfigurierten Aufbewahrungsfensters unveränderbar bleiben. Er ist kein Backup-Plan für eine Website auf Shared Hosting. Der Kunde benötigt Kontrolle über den geschützten Server; ein Shared-Hosting-Konto bietet nicht dasselbe Maß an Serverzugriff oder Backup-Kontrolle.
Einen Offsite-Backup-Service bewerten
Der richtige Service sollte zu den Systemen, Wiederherstellungszielen und Verantwortlichkeiten des Unternehmens passen. Der Preis ist wichtig, aber niedrige Speicherkosten helfen nicht, wenn die Wiederherstellung unklar ist oder das Zugriffsmodell des Anbieters die Isolation beeinträchtigt.
Bei der Bewertung von Offsite-Backup-Optionen für vom Unternehmen kontrollierte Server, Aufbewahrung und Wiederherstellungstests sollte man fragen, wie der Service zu den erforderlichen RPO- und RTO-Werten passt, wo die Daten gespeichert werden, wer die Verschlüsselungsschlüssel kontrolliert und wie die unveränderbare Aufbewahrung umgesetzt wird. Bestätigen Sie, dass der Service für die Server ausgelegt ist, die das Unternehmen tatsächlich verwaltet, statt davon auszugehen, dass eine Website auf Shared Hosting auf dieselbe Weise eingebunden werden kann.
Kurze Checkliste zur Bewertung
- Umfang: Kann der Service die Betriebssysteme, Anwendungen, Datenbanken und Datenvolumes schützen, die wichtig sind?
- Standort: Ist der Speicherort eindeutig und bietet er eine sinnvolle Trennung vom Produktionsstandort?
- Verschlüsselung: Werden die Daten bei der Übertragung und im Ruhezustand verschlüsselt? Wer erstellt, kontrolliert und schützt den Entschlüsselungsschlüssel?
- Isolation: Kann ein kompromittierter Serveradministrator jedes Backup löschen oder verändern?
- Unveränderbarkeit: Sind Wiederherstellungspunkte während des gesamten konfigurierten Aufbewahrungsfensters unveränderbar?
- Aufbewahrung: Kann die Richtlinie eine verspätete Entdeckung, Kundenanforderungen und das RPO der Organisation abdecken?
- Wiederherstellung: Wie werden Dateien, Datenbanken und vollständige Server wiederhergestellt und welche Infrastruktur wird dafür benötigt?
- Tests: Kann das Unternehmen einen Wiederherstellungstest durchführen, ohne auf einen echten Vorfall warten zu müssen?
- Betrieb: Wer erhält Fehlermeldungen, prüft sie und handelt, wenn ein Backup-Job nicht abgeschlossen wird?
- Verantwortung: Welche Aufgaben übernimmt der Anbieter und welche verbleiben beim Kunden?
Den ersten Wiederherstellungstest planen
Ein erster Wiederherstellungstest muss keine dramatische Übung für den vollständigen Ausfall eines Standorts sein. Er sollte kontrolliert, dokumentiert und für einen realen geschäftlichen Bedarf repräsentativ sein. Ziel ist der Nachweis, dass die Organisation ein Backup in nutzbare Daten oder einen nutzbaren Server umwandeln kann.
- Wählen Sie ein realistisches Szenario. Wählen Sie beispielsweise das versehentliche Löschen eines kritischen Ordners, die Beschädigung einer Datenbank oder den Verlust eines Produktionsservers.
- Definieren Sie das erwartete Ergebnis. Legen Sie fest, welcher Wiederherstellungspunkt verwendet wird, welche Daten vorhanden sein müssen und wie schnell der Test abgeschlossen sein soll.
- Bestätigen Sie Zugriff und Schlüssel. Stellen Sie sicher, dass die autorisierte Person für die Wiederherstellung den Backup-Service erreichen kann und den erforderlichen Verschlüsselungsschlüssel über den dokumentierten Prozess erhält.
- Verwenden Sie ein isoliertes Ziel. Stellen Sie die Daten auf einem Testserver oder in einer Testumgebung wieder her, die die Produktion nicht überschreiben und wiederhergestellte Daten nicht unnötig offenlegen kann.
- Prüfen Sie mehr als die Dateiexistenz. Überprüfen Sie Berechtigungen, Datenbankkonsistenz, Anwendungsstart, Konfiguration, Abhängigkeiten und repräsentative Benutzerabläufe.
- Messen Sie das Ergebnis. Erfassen Sie die Zeit, die benötigt wird, um den Wiederherstellungspunkt zu finden, die Daten zu übertragen, die Wiederherstellung abzuschließen und den Service nutzbar zu machen.
- Dokumentieren Sie Probleme und aktualisieren Sie den Plan. Korrigieren Sie fehlende Zugangsdaten, unklare Anweisungen, Netzwerkbeschränkungen, inkompatible Hardware oder unrealistische Annahmen.
Führen Sie nach einer erfolgreichen technischen Wiederherstellung eine geschäftliche Prüfung durch. Können die richtigen Personen auf das wiederhergestellte System zugreifen? Sind Kundendatensätze lesbar? Funktionieren geplante Jobs, Integrationen und Zertifikate? Entsprechen die wiederhergestellten Daten dem erforderlichen Zeitpunkt? Ein Server, der startet, ist nicht automatisch ein wiederhergestellter Service.
Offsite-Backups in die Geschäftskontinuität integrieren
Geschäftskontinuität hängt von mehr ab, als Daten an einem anderen Ort aufzubewahren. Sie erfordert eine abgestimmte Abfolge von Entscheidungen, um den Betrieb fortzusetzen, wenn die normale Infrastruktur nicht verfügbar ist. Ein Offsite-Backup liefert einen der wichtigsten Bausteine: eine Wiederherstellungskopie, die vom Ereignis getrennt ist, das die Produktion betrifft.
Der Prozess sollte technische Backup-Einstellungen mit geschäftlichen Prioritäten verbinden. Identifizieren Sie kritische Services, weisen Sie RPOs und RTOs zu, legen Sie die Aufbewahrung entsprechend dem Risiko einer verspäteten Entdeckung fest und dokumentieren Sie, wer die Wiederherstellung autorisieren darf. Fügen Sie Kontaktdaten, Serverinventare, Abhängigkeiten und den Speicherort der Anweisungen für Verschlüsselungsschlüssel hinzu. Bewahren Sie die Dokumentation auch dann verfügbar auf, wenn die primäre Umgebung ausgefallen ist.
Überprüfen Sie den Plan nach größeren Änderungen. Eine neue Datenbank, ein größeres Speichervolume, eine migrierte Anwendung oder eine Änderung im Kundenvertrag kann die Dauer von Backups und den Bedarf an Aufbewahrung verändern. Auch Personaländerungen können beeinflussen, wer reagieren kann. Eine Backup-Strategie, die vor zwei Jahren zum Unternehmen passte, unterstützt die aktuelle Arbeitslast möglicherweise nicht mehr.
Das stärkste Konzept kombiniert normalerweise eine schnelle lokale Wiederherstellung mit einer isolierten Offsite-Kopie. Lokaler Speicher kann alltägliche Vorfälle schnell bewältigen, während ein unveränderbares Offsite-Backup vor Ereignissen schützt, die lokaler Speicher nicht übersteht. Regelmäßige Wiederherstellungstests verbinden beide Ebenen anschließend mit einem tatsächlichen Wiederherstellungsprozess.
Ein praktischer Standard für Server-Backups
Für einen vom Unternehmen kontrollierten Server sollte eine zuverlässige Lösung fünf Fragen klar beantworten:
- Wie viele aktuelle Daten kann sich das Unternehmen leisten zu verlieren?
- Wie schnell muss jeder wichtige Service zurückkehren?
- Wo wird die Wiederherstellungskopie gespeichert und kann derselbe Vorfall sie ebenfalls betreffen?
- Kann ein kompromittierter Administrator sie verändern oder zerstören?
- Wann wurde der letzte erfolgreiche Wiederherstellungstest durchgeführt und was hat er bewiesen?
Wenn die Antworten unklar sind, verfügt das Unternehmen möglicherweise über Backups, aber nicht über Disaster Recovery. Ein Offsite-Backup löst das Standortproblem. Isolation, Verschlüsselung, Aufbewahrung und Tests entscheiden jedoch darüber, ob die Kopie unter höchstem Druck vertrauenswürdig ist.
Für Agenturen und kleine Unternehmen ist dieses Maß an Vorbereitung nicht übertrieben. Ein einzelner Produktionsserver kann ein Kundenportal, einen Onlineshop, einen internen Workflow oder eine umsatzgenerierende Anwendung unterstützen. Ihn zu schützen bedeutet, sowohl für alltägliche Fehler als auch für seltene Katastrophen zu planen. Eine lokale Kopie kann die Wiederherstellung beschleunigen. Eine ausgelagerte, verschlüsselte und unveränderbare Kopie bietet dem Unternehmen jedoch einen realistischen Weg zurück, wenn die lokale Umgebung kompromittiert wurde oder verloren gegangen ist.