FAQ

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 XHeute 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.

Das Recovery Point Objective (RPO) ist die Kennzahl zum Ausdruck des tolerierbaren Datenverlustes. Generell kann man sagen: Je kritischer eine Anwendung ist, umso geringer sollte der RPO sein.

Um diesen Wert gering zu halten, müssen Daten häufiger gesichert werden. So kann z. B. durch eine 4-malige tägliche Sicherung der RPO Wert von max. 24 Stunden (bei einer täglichen Sicherung) auf max. 6 Stunden reduziert werden.

Je nach Workload stehen hier verschiedene Technologien zur Verfügung:

Im Dateiumfeld werden Versionierungen von Änderungen und Snapshotverfahren genutzt um den Datenverlust zu minimieren. Diese Snapshots können auch an unabhängige Standby Systeme oder in ein Backup System verlagert werden.

Für Datenbankanwendungen werden geringe RPO Werte durch engmaschige (z. B. alle 10 Minuten) Logsicherungen erreicht. Datenbanken können auch durch ein Rollforward der verfügbaren Logs meist sekundengenau bis zum Zeitpunkt einer Datenkorruption wiederhergestellt werden.

Durch Cluster und Replikationsmechanismen werden die Datenbanken hochverfügbar gemacht und vor Ausfall zusätzlich geschützt.

Für Server und virtuelle Maschinen gibt es die Möglichkeit, eine Continous Data Protection Lösung, welche jeden schreibenden Zugriff auf die Festplatten an eine unabhängige Kopie schickt, zu implementieren. Zusätzlich können Cluster und Replikationssysteme unabhängige Kopien bereitstellen, welche auch mit Backup Systemen geschützt werden können.

Damit eine Backup-Lösung auch für zukünftige Workloads gerüstet ist, ist es sehr wichtig, dass die Lösung skalierbar ist. Zusammen mit einem korrekten Sizing ist man für die Zukunft gerüstet.

Anhand unterschiedlicher Informationen aus der Umgebung, wie z.B. die Anzahl der zu sichernden Server, egal ob virtuell oder physisch, sowie des zu erwartenden jährlichen Datenwachstums (Annual Growth Rate) lässt sich abschätzen, welche Storage- und Backup-Server-Kapazitäten benötigt werden.

Natürlich spielt hier auch die Anzahl aufzubewahrender Kopien, die Aufbewahrungszeit sowie die Verwendung von Deduplizierung eine Rolle.

Performance ist ein kritischer Faktor für die Leistungsfähigkeit einer Data Protection Umgebung. Viele Faktoren haben Einfluss auf die Performance Betrachtung und initial sollten einige Fragen beantwortet werden:

• Welche Werte sind aufgrund der eingesetzten Hardware überhaupt erreichbar?
  -> Performance Bottlenecks werden oft durch eine einzelne Komponente verursacht.
• Ist die Umgebung auf Backup- oder Restore Performance optimiert?
  -> Deduplizierung und Komprimierung sind der Backup Performance zuträglich, aber möglicherweise negativ für die Restore Geschwindigkeit
• Werden alle Backup Versionen aus Performance Gesichtspunkt gleich gewichtet?
  -> Ein Tiering älterer Backup Versionen auf günstigere Speicher verringern die Restore Performance
• Ist die Umgebung für Massen-Restore-Anfragen gewappnet?
  -> Es ist ein großer Unterschied ob nur eine einzelne Datei oder ein Server gleichzeitig wiederhergestellt werden müssen oder ob 100 Server parallel wiederhergestellt werden

Sizing Tools und Blueprints der Hersteller bieten eine gute Grundlage, um Anforderungen abzubilden und Performance Erwartungen zu rechtfertigen.

Das Monitoring und Reporting der Backup Umgebung hilft außerdem, Performance-Engpässe und Trends zu identifizieren.

Des weiteren können regelmäßige Restore Tests helfen, die Performance der Data Protection Umgebung zu validieren und Engpässe aufzuzeigen.

Um eine Backup Umgebung vor Angriffen zu schützen, sind vielschichtige Maßnahmen nötig. Es beginnt damit, dass man seine Umgebung entsprechend "härtet":

Alle unnötigen Dienste müssen deaktiviert werden, User sollten auf die notwendigen Personen beschränkt sein und die Accounts sollten lokal sein und nicht über AD (Active Directory) etc. kommen.

Es sollten Härtungsmaßnahmen auf Betriebssystemseite und in der Backup-Anwendung vorgenommen werden. So gelten Passwortregeln im Betriebssystem und in Spectrum Protect. Eine Mulitfaktor-Authentifizierung kann für die Zugriffe auf die Umgebung als weitere Sicherungsschicht eingerichtet werden.

Damit hat man für Angreifer schon einmal eine Hürde gelegt, die natürlich auch nicht unüberwindlich ist.

Daher sollte das Backup auch entsprechend der 3-2-1 Regel konzeptioniert sein. Es sollte mindestens 3 Kopien der Daten geben, die auf mindestens zwei verschiedenen Medien verteilt sind. Davon ist mindestens eine Version an einem anderen Standort. Idealerweise bieten die verwendeten Medien auch ein Air Gap, das diesen Angreifern eine Änderung der Daten nicht erlaubt. Die Dokumentation für die Wiederherstellung sollte offline verfügbar sein. Dazu sind auch notwendige Passwörter sicher im Tresor zu hinterlegen, damit eine Wiederherstellung auch ohne Zugriff auf interne PasswortSafes und Informationen, die auf internen Server abgelegt waren, gelingt.

Ein Restore der Umgebung sollte auch regelmäßig getestet werden, da man im Desasterfall auf das Geprobte zurückgreifen kann und nicht bei Null anfängt. Für Spectrum Protect sollten die Datenbank Sicherung und die dazu gehörigen Informationen auch an mindestens zwei Standorten und mindestens einmal auf einem Medium sein, welches von Angreifern nicht geändert werden kann (Tape).

Destruktive Befehle sollten nach einem 4-Augen-Prinzip freigeben werden und alle administrativen Operationen, die Auswirkung auf die Wiederherstellbarkeit der Backup Umgebung haben, sollten gemonitored werden.

Damit lassen sich Eingriffe von Angreifern erschweren oder frühzeitig entdecken.

Beim Speichern und Sichern von Daten ist es immer wichtig zu verstehen, um welche Art von Daten es sich handelt. Erst dann lässt sich sagen, ob die aktuelle Strategie noch sinnvoll ist oder ob man sie anpassen sollte:

• Sind die Daten oft im Zugriff?
• Lesend und / oder schreibend?
• Ist ein besonderer Schutz für diese Daten notwendig oder reicht die einmalige Speicherung aus?
• Werden die Daten wenig bewegt, handelt es sich vielleicht sogar um Archivdaten?
• Sind die Datenmengen sehr groß, so dass die Speicherung auf Festplatten auf Dauer zu teuer wird?

Sobald dieses Verständnis erlangt wurde, entweder durch Analysen oder einfach durch Erfahrung, können die wegweisenden Entscheidungen getroffen werden. Beim Thema Backup zum Beispiel ist es immer noch ratsam, über den Einsatz von Tape nachzudenken. Tapes können aus der Tape Library ausgelagert werden, lagern dann "kalt im Schrank" und verursachen keine laufenden Kosten.

Aber nicht nur die Lagerung der Daten verursacht Kosten, sondern auch deren Verarbeitung, sprich: Infrastruktur.

Auf welcher Art von Disk-Storage Daten gelagert werden, hat einen erheblichen Einfluss auf die Kosten. Hierbei gilt es, einen gesunden Mittelweg aus Performance, Verfügbarkeit und Kosten zu finden. Es ist zum Beispiel nicht immer sinnvoll, Backup-Daten auf Block-Storage mit SAN Infrastruktur vorzuhalten. Ein redundant ausgelegtes NAS leistet vielleicht die erforderliche Performance für einen Bruchteil der Kosten, vor allem wenn man sich die Fähigkeiten zur Deduplizierung anschaut.

Nicht zuletzt bietet die verwendete Software ein großes Einsparpotential:

• Laufen vielleicht noch Verträge mit großen Softwarehäusern, die sich über kleinere Anbieter günstiger beziehen lassen?
• Ist die Software an sich noch passend für die Aufgabe oder gibt es mittlerweile andere Anbieter, die die gleiche Leistung für weniger Geld anbieten können?

Dieser Punkt sollte regelmäßig evaluiert und mit dem IT-Partner des Vertrauens diskutiert werden. Das Angebot an leistungsstarken Lösungen ist so umfangreich geworden, dass sich ein regelmäßiges Abwägen lohnt.

Diese Frage kann man eigentlich mit zwei Sätzen beantworten:

Immutable Storage ersetzt das Air Gap beim Backup, wenn man keinen Tape Storage zur Verfügung hat.

Damit wird verhindert, dass gesicherte Daten nachträglich, beispielsweise durch eine Ransomware Attacke, verändert werden können.

Cyber Resilience im Backup-Umfeld bezieht sich darauf, wie gut ein Unternehmen in der Lage ist, auf Cyber-Angriffe oder -Störungen zu reagieren und seine Systeme, Daten und Geschäftsprozesse schnell wiederherzustellen. Es geht darum, sicherzustellen, dass das Backup-System robust und widerstandsfähig genug ist, um den Schutz vor Bedrohungen wie Ransomware, Malware, Phishing-Angriffen oder anderen Cyberattacken zu gewährleisten.

Ein Unternehmen mit einem hohen Maß an Cyber Resilience im Backup-Umfeld hat in der Regel eine Kombination von Technologien, Prozessen und Schulungen implementiert, um seine Daten und Systeme vor Cyber-Angriffen zu schützen und gleichzeitig die Fähigkeit zu haben, schnell auf Störungen zu reagieren und sich von diesen zu erholen. Dazu gehören unter anderem:

• Regelmäßige Backups, die auf unterschiedlichen Speichermedien und Standorten gespeichert werden, um Datenverluste zu vermeiden
• Die Implementierung von Verschlüsselungs- und Authentifizierungstechnologien, um Daten vor unbefugtem Zugriff zu schützen
• Ein schnelles und effektives Incident-Response-Management, um Cyber-Angriffe schnell zu erkennen, zu melden und darauf zu reagieren
• Schulungen für Mitarbeiter, um das Bewusstsein für Cyber-Sicherheit zu erhöhen und das Risiko von Angriffen zu reduzieren

Durch eine hohe Cyber Resilience im Backup-Umfeld kann ein Unternehmen sicherstellen, dass es auch bei Cyber-Angriffen oder anderen Störungen in der Lage ist, seine Geschäftsprozesse aufrechtzuerhalten und schnell wiederherzustellen.