Immer wieder hört man Schreckensmeldungen, wonach ein Anbieter von einem Hacker heimgesucht wurde und Unternehmensdaten vernichtet wurden – sei es gelöscht oder verschlüsselt. Dabei ist es gar nicht so schwer, ein Backup der wichtigsten Unternehmensdaten Malwaresicher auch automatisiert zu sichern.
Wichtig zu verstehen ist dabei, dass eine Cloud oder eine externe Festplatte kein Backup im technischen Sinne sein können. Es geht um den Prozess sowie das 3-2-1 Prinzip. Ebenso muss man sich mit den Begriffen ‚Recovery Point Objective‘ (RPO), ‚Recovery Time Objective‘ (RTO) sowie ‚Recovery Time Actual‘ (RTA) auseinandersetzen.
Der Backupprozess muss vor menschlichen Fehlern möglichst abgeschottet werden. Deswegen ist eine externe Festplatte, die man wöchentlich ansteckt, einfach absolut fehl am Platz. Gleichzeitig ist die externe Festplatte, die permanent mit dem zu sichernden System verbunden ist, viel zu anfällig für Angreifer.
Die „Cloud“ ist allein Betrachtet aus zwei Gründen kein sicherer Speicherort für ein Backup:
- Änderungen des Datenbestands dürfen nicht Live geschrieben werden – wenn gelöschte Dateien sofort ins „Backup“ synchronisiert werden, bringt das ganze Backup nichts.
- Es gibt Meldungen, wonach die großen Anbeiter wie onedrive oder Google Drive die Inhalte derer Clouddrives regelmäßig nach Pornografie scannen. Die Anbieter machen das nicht weil ihnen langweilig ist, sondern weil sie vom Gesetzgeber dazu gezwungen werden. Wenn nun aber ein Selbständiger oder auch ein kleines Unternehmen mit 2-3 Mitarbeitern onedrive oder google Drive zum Austausch von Dateien benutzt, sich aber das Bild vom eigenen Kind am Strand ohne Badehose versehentlich darunter befindet, ist der Account unrettbar verloren.
Wie also erstellt man nun sein eigenes, malwaresicheres Backup?
Das 3-2-1-Prinzip ist eine bewährte Methode für die Datensicherung, um sicherzustellen, dass Daten effektiv geschützt und wiederhergestellt werden können. Die Grundidee hinter dem 3-2-1-Prinzip besteht darin, mehrere Kopien der Daten auf unterschiedlichen Speichermedien an differenten geographischen Orten zu haben, um sich vor Datenverlust durch verschiedene Szenarien wie Hardware-Ausfälle, menschliche Fehler, oder Katastrophen abzusichern.
Die Bedeutung des 3-2-1-Prinzips:
3 Kopien der Daten: Es werden mindestens drei Kopien der zu sichernden Daten erstellt. Dies bedeutet, dass neben der Originalkopie auf dem primären Speicher zwei zusätzliche Kopien erstellt werden.
2 verschiedene Speichermedien: Die Datenkopien sollten auf zwei unterschiedlichen Arten von Speichermedien gespeichert werden. Das bedeutet, dass man nicht nur auf eine Art von Speichermedium vertraut. Zum Beispiel könnten Kopien auf Festplatten und zusätzlich auf magnetischen Bändern oder Cloud-Speicher gesichert werden.
1 Kopie an einem anderen Ort: Mindestens eine der Kopien sollte an einem physisch getrennten Ort von der ursprünglichen Datenquelle aufbewahrt werden. Dies kann vor Ort in einem anderen Gebäude oder extern über Cloud-basierte Dienste erfolgen. Das Ziel ist es, die Daten vor Katastrophen wie Feuer, Überschwemmungen oder anderen örtlichen Zwischenfällen zu schützen.
Durch die Einhaltung des 3-2-1-Prinzips kann man sicherstellen, dass selbst bei Ausfällen eines Speichermediums, menschlicher Fehler oder größeren Katastrophen immer noch auf sicherheitskopierte Daten zugegriffen werden kann.
RPO:
Stellen wir uns einen betriebsweiten Vorfall vor, bei dem der gesamte Datenspeicher ausfällt und viele Anwendungen betroffen sind. Hier beschreibt der RPO-Wert den Zeitraum des Datenverlusts der Anwendungen. Anders ausgedrückt: Der Zeitraum zwischen dem letzten zugreifbaren Datenstand und dem Schadenseintritt. RPO kann als Service-Level-Ziel oder als Kennzahl für die Verlusttoleranz verstanden werden. Welchen Zeitraum mit Datenverlusten kann das Unternehmen realistisch betrachten, wenn ein Speicherausfall den Zugriff auf die Daten beeinträchtigt? Wenn der RPO-Wert im Geschäftskontinuitätsplan als Zeitraum von zwölf Stunden festgelegt wird und das letzte bekannte verfügbare Daten-Backup vor dem Ausfall neun Stunden zurückliegt, würden wir also die definierte RPO einhalten.
RTO:
RTO ist ebenfalls ein Service-Level-Ziel. Mit ihm legen wir die erwartete Zielvorgabe für die Wiederherstellung der Betriebsbereitschaft fest. RTO bezeichnet den Zeitraum, den wir festgelegt haben, bis zu dem betroffene Services nach einer Störung (in unserem Beispiel aufgrund eines Speicherproblems) wiederhergestellt sein müssen. Bei einem kleinen Zwischenfall in einem Hochverfügbarkeitsszenario könnte unser RTO-Wert fünf Minuten betragen. In dieser Zeit müsste eine lokale Kopie der Daten zugreifbar gemacht werden. Im Falle eines Disaster-Recovery-Szenarios, in dem unser primärer Standort und der DR-Standort weit voneinander entfernt sind, müssen am DR-Standort umfangreiche Daten-Backups verfügbar gemacht werden (in der Regel durch asynchrone Replikation). Dazu müssen viele Verbindungen neu konfiguriert und Services neu gestartet werden, was zu einem RTO von mehreren Stunden oder sogar Tagen führen würde. Wichtig hierbei ist auch die Betrachtung der Datenmengen, des Speicherortes und der verfügbaren Internetleitung: Wenn wir eine RTO von 12 Stunden festlegen aber 5 TB Daten über eine 16 MBit „schnelle“ DSL-Leitung herunterladen müssen, ist der Servicelevel per Definition nicht realistisch.
RTA:
RTA bezieht sich auf die Zeit, die tatsächlich vergeht, bis die Daten vollständig wiederhergestellt sind und eine Datenkopie für die Anwendungen zugänglich ist. Während RTO ein Sollwert ist, der als Ziel festgelegt wird, ist RTA die tatsächlich benötigte Zeit. Für eine gute Daten-Governance und -Compliance muss die erreichte RTA unter dem im BC/DR-Plan festgelegten RTO-Wert liegen. In manchen Fällen simulieren wir ein DR-Szenario in einer unabhängigen Testumgebung und untersuchen die Wirksamkeit unserer Backup- und Recovery-Tools durch die Messung der RTA. Falls wir dabei feststellen, dass die RTA-Zeit länger ist als die RTO-Zeit, sollten wir unsere Notfallwiederherstellungsstrategie noch einmal überarbeiten, um eine schnellere Wiederherstellung des Geschäftsbetriebs zu gewährleisten.
Der Unterschied zwischen RTO und RTA ist dabei an einem Beispiel einfach zu erklären:
Wir bleiben bei unserem Beispiel der 5 TB Daten, die irgendwo auf einem Onlinespeicher liegen. Der Onlinespeicher liefert max. 10 GBit/s, also 10.000 MBit/s also max. 1200MByte/s. Sofern unser Büro auch mit 10 GBit/s angeschlossen ist, ist eine RTO von 5*1024*1024/1200 = 4.369s = 73 Min. = 1,25 Stunden.
Praktisch gibt es aber immer Leitungsverluste und auch die Festplatte bei uns kann die Daten vielleicht nur mit 1.000 MByte/s schreiben.
Hieraus ergibt sich dann eine RTA von 5*1024*1024/1000 = 5.243s = 1,5 Stunden
Aber sind wir mal ehrlich: Wer hat schon 10GE am Büro anliegen? Die meisten von uns dürften mit 50-200MBit/s arbeiten, also 0,05 bis 0,2GE arbeiten.
Im Beispiel ist dabei allerdings nur die reine Transferzeit berücksichtigt. Gehen wir davon aus, dass unser System an einem Freitag abend um 19 Uhr gestorben ist, müssen wir den Admin aus dem Wochenende holen (Reaktionszeit?), der muss ins Büro kommen (Fahrtzeit), den konkreten Fehler feststellen (Prüfzeit), evtl. neue Festplatten besorgen (Lieferzeit), das neue System zusammenbauen und installieren (Setup-Zeit) und kann erst danach mit dem Download des Backups beginnen, welches danach auch noch auf die einzelnen Zielsysteme ausgerollt werden muss (Wiederherstellungszeit). Sofern also der Büroserver an einem Freitag abend um 19 Uhr gestorben ist und wir annehmen, dass der Mediamarkt um die Ecke keine Hardware bereitstellen kann, vergeht ganz schnell eine Woche, bis zum Abschluss des Restores.
Ihr habt Fragen zum Thema Backup oder IT-Infrastruktur? Der Author arbeitet hauptberuflich als IT-Systemadmin und Infrastruktur-Architekt für kleine und große Unternehmen in ganz Europa und betreibt am Standort Helsinki eigene Infrastruktur für Onlineshops, Backups und remote Workstations. Komplexe Infrastrukturen sind die Leidenschaft des Authors.
