FAQ

IT-Backup & Co.& - Sie fragen, Empalis antwortet: Unsere Experten erklären IT-Backup Fachkonzepte und -begriffe aus Beratersicht.

Ein Backup (Datensicherung) bedeutet, auf einen früheren Stand der Daten zurückkehren zu können.

Man braucht ein Backup für den Fall von Datenverlust, Manipulation oder fehlendem Zugriff auf die Originaldaten.

 

Die Implementierung einer Backup-Umgebung hängt unter anderem von den Anforderungen an Aufbewahrungszeit, Anzahl der Kopien (auch Remote) und Restore-Geschwindigkeit ab. Auch die zu sichernde Umgebung gilt es zu berücksichtigen, um die in Frage kommenden besten Backup-Tools zu bestimmen.

Microsoft365 speichert Daten lediglich zeitlich begrenzt auf 93 Tage bei SharePoint und OneDrive, zusätzlich nochmal 14 Tage als Sicherung im Default für SharePoint. Wird jedoch der Papierkorb zu groß, fängt er auch vorher an, Daten zu Löschen

 

Bei Mail ist der Standard 14 Tage Aufbewahrung, erweiterbar auf 30 Tage.

 

Um Daten sicher zu speichern, sind anschlussfähige Lösungen notwendig. Hier gibt es vielfältige Lösungsmöglichkeiten, die in der Auswahl von Ihren Bedarfen und Anforderungen abhängig sind.

 

 

 

 

Bei einem Recovery / einer Wiederherstellung holt man Daten aus einem zuvor erstellten Backup / einer Datensicherung zurück.

 

Gründe dafür gibt es viele, sei es aus versehentlichem oder absichtlichem Verändern, Überschreiben oder Löschen der Daten, Ausfall der Hardware, Fehler in der Software, Virusbefall, Katastrophen usw. Dabei werden die Daten an den ursprünglichen oder einem neuen Speicherort zurückgeschrieben.

 

Das Backup / die Datensicherung soll also vor Verlusten schützen. Allerdings kann auch das Backup selbst durch die vorher genannten Probleme betroffen werden. Es läuft auf Hardware, es wird Software für das Backup eingesetzt, Daten können schon länger verändert, überschrieben oder durch Viren befallen sein.

 

Die Gefahr bei Hardwareausfällen oder regionalen Katastrophen kann man durch weit entfernte Backup-Kopien abmildern. Aber ob Backups wirklich, so wie erwartet und gewünscht, wiederherstellbar sind, stellt man meist erst im Ernstfall fest. Durch regelmäßige Restore-Tests und Scans der gesicherten Daten läßt sich das schon vorab herausfinden.

 

Idealerweise sollten dabei alle gesicherten Daten geprüft werden, da der Restore einzelner Daten oder Systeme meist gut funktioniert, aber noch kein Beweis ist, ob auch die gesamte Umgebung wiederherstellbar ist. Aufgrund der Datenmengen sollten diese Tests auch automatisiert erfolgen.

RTO steht für "Recovery Time Objective" und bezieht sich auf die Zeit, die eine Anwendung, System oder Prozess ausfallen darf - ohne, dass ein signifikanter Schaden für das Unternehmen entsteht. Dies beinhaltet auch die Zeit der Wiederherstellung.

 

Beispiel: Beträgt eine RTO drei Stunden, muss viel Geld bezahlt werden: für Ausfallrechenzentren, Automatisierung, Telekommunikation usw. da hier eine komplette Wiederherstellung in drei Stunden erreicht werden soll. Wird die RTO auf drei Wochen angegeben, entsteht deutlich mehr Zeit, um neue Ressourcen anzuschaffen und eine Wiederherstellung durchzuführen.

 

RPO steht für "Recovery Point Objective" und bezieht sich auf den maximalen Datenverlust, welches ein Unternehmen hinnehmen kann, der zwischen einem Backup und dem Ausfall des Systems entsteht.

 

Beispiel: Ist es zu ertragen, dass Sie von einem Dokument eine Stunde Ihrer Arbeit, vier Stunden Ihrer Arbeit verlieren oder sogar Tage  und Wochen verlieren?

 

Diese Festlegung ist sehr wichtig, da man so den Abstand einer Datensicherung festlegen kann. Beträgt die RPO sechs Stunden, so muss alle sechs Stunden eine Datensicherung erfolgen. Wenn das Backup nur alle 12 Stunden laufen würde, wäre die Gefahr zu hoch, dass von zu viel Datenverlust auszugehen wäre. Wenn es jede Stunde laufen würde, wären jedoch die Kosten für die Ressourcen (Speicher, usw.) zu hoch.

Bei der 3-2-1 Regelung handelt es sich um die „golden Rule“ der Backup-Lösungen. Die Bezeichnung schlüsselt sich wie folgt auf:

  • Nutzung von 3 Datenkopien (Original und 2 Backups)
  • Auf mindestens 2 Speichertypen (HDD / Wechselmedien / Cloud)
  • Mit 1ner Offsite-Kopie (an einem externen Ort / Bandsicherung)

Die Idee hinter dem Konzept: Ausschluss des sogenannten Single Point of Failure (SPOF) - ein Risiko im Design bzw. der Implementierung - um somit zu verhindern, dass z.B. eine Malware-Attacke in der Lage wäre, das komplette System lahmzulegen oder um sicherzustellen, dass sich im Falle einer Umweltkatastrophe, wie einer Überflutung, alle Daten an einem sicheren Ort befinden.

 

Im Betrieb kann das 3-2-1 Konzept wie folgt aussehen:

 

Auf einer Master-Sicherheitskopie wird von einer Backup Software erstellt. Diese Kopie wird nun an 2 Stellen repliziert: a) Auf einen 2. Server (z.B. in einem redundanten Serverraum) für den schnellen operativen Zugriff und b) auf ein anderes Datenmedium (z.B. Cloud)
Die 3. Kopie erfolgt auf Band und wird an einen anderen Standort ausgelagert.
 

Hier sollte auch in Betracht gezogen werden, dass das Thema Cyber-Attacken über die letzten Jahre sehr akut geworden ist und man im Falle eines klassischen Backups an nur einem Standort Gefahr läuft, sämtliche Daten zu verlieren. Ein aktuelles Beispiel ist Log4j. Daher erachten wir wie andere Experten das 3-2-1 Konzept als unabdingbar für eine moderne Datensicherung unter heutigen Anforderungen.

 

Der Disaster Recovery Plan sollte am besten ein Dokument sein, welches beinhaltet, was wann und wie getan werden sollte, wenn eine Katastrophe eintritt. In dem Plan sollte definiert sein, welche Maßnahmen für ein Recovery benötigt werden.

 

Nehmen wir mal an, dass Ihr Unternehmens-Standort bis auf die Grundmauer durch einen Brand zerstört wurde. Was würden Sie nun machen?

 

Nun muss also neue Hardware besorgt und der Backup-Server wieder errichtet werden. Danach werden alle Backup-Daten auf dem Backup-Server wiederhergestellt, damit man daraus später die Clients wiederherstellen kann, um wieder produktiv zu arbeiten.

 

Doch wie stelle ich den Backup-Server wieder her?

Dafür gibt es einen DR-Planfile. Zum Beispiel steht in einem Disaster Recovery-Planfile für IBM Spectrum Protect definiert, wie der TSM-Server aufgebaut und konfiguriert war, wo welche Backup-Daten abgelegt wurden, und z.B. welche LTO-Bänder benötigt werden, um alle kompletten Backups wiederherstellen zu können.

 

Backup ist erst die halbe Miete: Die Kontrolle der Backups mit Analyse- und Monitoring Tools ist bekannt. Einige Software-Hersteller bieten so genannte "Health Checks" der Backups an. Damit ist sichergestellt, dass die Backups auch valide und brauchbar sind.

 

Ein erfolgreiches Backup der Daten nützt jedoch niemanden, wenn der Restore fehl schlägt. Laut der aktuellen Veeam Studie "Data Protection Trends Report 2022" waren die befragten Organisationen und Unternehmen nur zu 64% Wiederherstellung ihrer Daten in der Lage. Das bedeutet, dass mehr als 1/3 der Daten nicht wiederhergestellt werden konnten. Teils, weil bereits bei der Sicherung schon unbemerkte Fehler passierten, oder die Wiederherstellung nicht funktionierte. Daher ist es nicht nur sinnvoll, ein regelmäßigen Restore-Test durchzuführen, sondern eher eine Pflicht.

 

So wie es eine strukturierte Backup-Strategie gibt, ist auch die Wiederherstellung als ein Prozess im Backup-Konzept zu etablieren. Ein Recovery-Plan mit regelmäßigen Wiederherstellungstests gilt für alle Backups.

 

"Den" Schutz vor Ransomware gibt es nicht. Eine Verbesserung des Schutzes erreicht man durch mehrere verschiedene Ansatzpunkte:

 

Als Basis dient die 3-2-1 Regel, d.h. 3 Kopie an 2 unterschiedlichen Standorten, davon 1 Offsite. Diese kann man auch noch erweitern, Veeam hat bspw. daraus eine 3-2-1-1-0 Regel gemacht. Hier wird noch 1 Immutable-Backup (ein nicht veränderbarer Datensatz) und 0 Fehler Restore (bedeutet regelmäßige Restore-Tests) hinzugefügt. Dies allein ist aber nur ein Maßnahmenbündel, um sich vor Ransomware zu schützen. 

 

Zum Schutz des Backup-Umfelds gehört auch der Schutz der Sicherungsumgebung, d.h. Trennung der Dienste und Zugriffe auf verschiedene Accounts (eben nicht aus Bequemlichkeit alles unter dem Admin-User ausführen), da viele Angriffe sich bevorzugt auf Windows-Umgebungen konzentrieren, die Backup-Server unter Linux betreiben, Netzwerkverbindungen nur bei Bedarf auf die Nodes zu nutzen und nicht permanent offen lassen.  

 

Zu denken, ein erfolgreiches Backup wäre ausreichend, ist an der Stelle zu kurz gedacht. Nur ein durchdachtes und strukturiertes Backup in Verbindung mit Überlegungen im Bereich Netzwerksicherheit und nutzungsspezifischen Zugriffsrechten auf Daten und Dienste, dazu die regelmäßige Prüfung der Backups und Tests der Wiederherstellung, führt hier zum Ziel des Schutzes gegen Ransomware Angriffe. 

 

Fazit: Nur ein stimmiges Konzept bietet einen Schutz! 

 

„Eingeschränkte“ Business Continuity - auch im Notfall

 

Beim einem Angriff kann man mit den Backup-Daten eine Notfall-Produktion (z.B. ReadOnly-Mode) zur Verfügung stellen:

  • Notfallproduktion in einem „sicheren“ Bereich (Notfall-RZ / -Cloud usw.) 
  • Bereitstellung von wichtigen Informationen  (verifizierte / überprüfte / sichere Versionen usw.). Nicht ganz aktuell aber kann keinen weiteren Schaden anrichten usw.

Vorbereitung/Training geht nur mit Backup-Daten bzw. einer Disaster Recovery-Lösung für den Fall X

Heute ist es nicht mehr die Frage, ob es passiert, sondern wann es passiert: Nur wer mit dem „wirklichen“ Disaster Recovery-Fall (Worst Case Fall) rechnet, hat auch eine Chance.

 
Bei entsprechenden Übungen von Notfallverfahren (DR-Test) können die Auswirkungen RTO und RPO im Disaster-Fall minimiert werden. Jedoch nur mit den Backup-Daten können DR-Verfahren wirklich getestet werden - mit produktiven Daten ist dies nur sehr eingeschränkt möglich. Im „Worst Case Fall“ sind zudem nur die Backup-Daten noch vorhanden.

Bedrohungserkennung / Forensik

 

Eine Bedrohungserkennung erfordert, dass Backupdaten analysiert und nach „schlafenden“ Bedrohungen untersucht werden. Auch „ältere“ Backup-Versionen können mit aktuellsten Verfahren überprüft werden. Es gilt auszuwerten: Konnte der Befall nicht entdeckt werden - oder konnte eine frühzeitige Erkennung von langfristigen geplanten Attacken erfolgreich Angriffe verhindern? 

Hilfe und Unterstützung in der Forensik (Wann / Was / Wo usw.) bieten wichtige Lessons Learned.

Und nach dem Angriff…?

 

Nach einem Angriff versucht man den Restore der Daten/Systeme mit möglichst wenig RTO und RPO - und den Aufbau der Produktion mit möglichst wenig negativen Überraschungen.