Die jüngsten Ransomware-Attacken auf Unternehmen aller Größen und Branchen haben das Thema Datensicherung wieder in den Fokus der IT-Verantwortlichen gerückt. Das Backup und vor allem die Wiederherstellung waren noch nie triviale Aufgaben. Anwendungen wie Datenbanken oder Groupware nutzen meist eigene Verfahren, um eine applikationskonsistente Sicherung anzufertigen, oder Schnittstellen, die ein Drittanbieter-Datensicherungssystem ansteuern kann, um Daten für ein Backup abzuziehen oder als Teil des Restore zurück in die Anwendung zu injizieren. Mit dem Fortschreiten der Datacenter-Virtualisierung haben sich Verfahren etabliert, die ganze virtuelle Maschinen mittels Snapshots sichern, um aus diesen Daten bei Bedarf vollständige VMs, einzelne Festplatten-Volumes oder sogar spezielle Datensätze wiederherzustellen.

Wenn Unternehmen ihre Anwendungen in die Cloud verschieben, ändern sich die Anforderungen an die Datensicherung, aber auch die Möglichkeiten, diese in ausreichender Qualität durchzuführen. Besonders umfangreich fallen die notwendigen konzeptionellen Anpassungen aus, wenn Sie eine zuvor lokal gehostete Anwendung nicht einfach per "Lift & Shift" auf Cloud-VMs umziehen, sondern fortan als Software-as-a-Service (SaaS) konsumieren. Hier ist ein direkter Zugriff auf die Infrastruktur nicht mehr möglich und auch die mit der zu sichernden Anwendung verzahnten Basisdienste wie Identitäts- oder Compliance-Management haben in der Cloud oft keine ausreichenden Datensicherungs-Schnittstellen.

Die Antwort der großen Cloudprovider auf die Fragen nach der Sicherung von SaaS-Datenbeständen läuft häufig darauf hinaus, dass der Provider die Infrastruktur hochgradig redundant auslegt, um den Verlust von Daten auszuschließen. Um zu verstehen, warum dieser Ansatz oft zu kurz greift und ein Backup auch von in der Cloud gehosteten Daten in vielen Fällen notwendig ist, müssen wir uns fragen, aus welcher Motivation heraus IT-Organisationen eine Datensicherung einrichten.

Es gibt viele Gründe, die Datenbestände ihrer Anwendungen zu sichern:

- Wiederherstellung der Systeme, Anwendungen und Daten bei Totalverlust. Der Verlust kann physischer Natur sein (Brand im Rechenzentrum) oder auch rein digital (Ransomware-Angriff).

- Schutz gegen unbeabsichtigtes Löschen oder Verändern der einzelnen Dateien oder Datensätze. "Unbeabsichtigt" kann dabei sowohl einen Fehler beim Durchführen eines legitimen Vorgangs bedeuten als auch eine mutwillige Beschädigung der Daten zum Beispiel durch einen kürzlich entlassenen Mitarbeiter.

- Zugriff auf vergangene Informationsstände zu Nachweiszwecken. Idealerweise sollte für diesen Anwendungsfall auf digitale Archivierung zurückgegriffen werden. Doch nicht alle Anwendungen und Daten unterliegen einer gesetzlichen oder behördlichen Archivierungsverpflichtung, sodass die Anforderung, die Daten von vor einigen Jahren einsehen zu können, oft rein internen Ursprungs ist. In solchen Fällen scheuen sich viele Organisationen, zu viel zu archivieren, da hieraus unter Umständen Probleme mit dem Datenschutz erwachsen, die nicht so leicht aus der Welt zu schaffen sind.

- Akkreditierungs- oder Zertifizierungsanforderungen. Einige Aufsichtsbehörden und -organisationen verlangen bei einem Audit immer noch lediglich die Einrichtung einer Datensicherung in einer gewissen Güte vorzuweisen. Die Bedrohungen, gegen die diese Datensicherung schützen soll, werden oft nicht einzeln benannt, sodass die auditierten Unternehmen keine Gelegenheit bekommen, die Eigenarten ihrer IT-Infrastruktur zu beleuchten und die Datensicherungsanforderung gegebenenfalls zu entkräften.

Auf diese Anforderungen konnten IT-Organisationen in den herkömmlichen IT-Welten in der Regel sinnvolle technisch-organisatorische Antworten finden. Doch schauen wir einmal in die Cloud und versuchen, die obigen Anforderungen auf die typischen SaaS-Anbieter und konkret auf Microsoft 365 zu projizieren.

Bei dem Bedrohungsszenario "Totalverlust der Infrastruktur" sind sich die meisten SaaS-Anbieter (so auch Microsoft) sicher, durch mehrfache Redundanzen und Georedundanzen gegen solch gravierende Ausfälle ausreichend vorgesorgt zu haben. Die garantierte Verfügbarkeit, die neben der Infrastruktur selbst auch die providerseitigen Netzwerkzugänge einschließt, ist in den Service-Beschreibungen [1] für die einzelnen Microsoft-Onlinedienste geregelt. Diese enthalten auch die dazugehörigen Service Level Agreements (SLA), die die Entschädigung für längere Dienstausfälle regeln.

Theoretisch sieht dieser Vertrag auch eine Entschädigung für die vollständige Zerstörung Ihres Mandanten vor. Sie als Kunde müssen daher selbst beurteilen, ob die vorgesehene Entschädigung den Schaden, den Ihre Organisation durch solch ein katastrophales Ereignis erleiden würde, tatsächlich deckt. Stellen Sie hier eine Differenz zu Ihren Ungunsten fest, müssen Sie Ihren M365-Mandanten mit anderen Mitteln absichern oder eine zusätzliche Ausfallversicherung abschließen.

Anders verhält es sich bei Änderungen oder Löschungen von Daten in den einzelnen Anwendungen Ihres Tenants. Hier endet die Verantwortung und somit auch die Haftung des Cloudproviders deutlich früher. Genaugenommen sind Sie als Kunde immer für Änderungen an den Datenbeständen in den von Ihnen gebuchten SaaS-Anwendungen verantwortlich.

Eine sehr ausführliche Analyse der Aufteilung der Zuständigkeiten zwischen Anbietern und ihren Kunden liefert Forrester Research in seinem zuletzt Ende 2017 erschienenen Bericht [2]. Die in dem Report zusammengetragenen Angaben zu den Angeboten verschiedener Provider bieten eine solide und heute noch weitestgehend gültige Entscheidungsgrundlage für Organisationen, die ihre Clouddaten absichern möchten. Die Ergebnisse, zu denen die Verfasser des Berichts kommen, sollten Sie hingegen sehr kritisch betrachten. Gerade bei kurzfristigem Wiederherstellungsbedarf aufgrund einer unbeabsichtigten Löschung oder Änderung bieten viele der M365-Dienste die Möglichkeit, über Papierkörbe eine frühere Version der Daten wiederherzustellen.

SharePoint Online und das darauf basierende OneDrive for Business sind Paradebeispiele für diese Funktionalität. Bei Exchange Online besteht in vielen Tarifen, wo die Postfachgröße de facto nicht eingeschränkt ist, sogar die Möglichkeit, mittels "Legal Hold" die Postfachdaten auf unbegrenzte Zeit einzufrieren. Auch im Bereich des Identitätsmanagements haben Sie als Administrator die Möglichkeit, irrtümlich gelöschte Objekte wie Accounts oder Gruppen kurzfristig wiederherzustellen. In einem Blogbeitrag [3] zitiert AvePoint – selbst Anbieter eines Backupprodukts für M365 – den erwähnten Forrester-Bericht und schränkt die Notwendigkeit eines externen Backups insofern ein, dass es für die reine Sicherung zu Nachweiszwecken nicht notwendig ist, die Clouddaten zu kopieren oder aus der Microsoft-Cloud herauszubewegen.

Doch nicht alle Dienste der umfangreichen M365-Pakete lassen eine lückenlose Sicherung und vor allem Wiederherstellung "ihrer" Daten zu. Anwendungen wie beispielsweise Planner, die für die Datenspeicherung nicht auf SharePoint Online zurückgreifen, verfügen nicht über einen Papierkorb oder andere Aufbewahrungsmechanismen. Und wichtige Metadaten wie die im Azure AD registrierten Applikationen und die ihnen erteilten Berechtigungen lassen sich, wenn einmal gelöscht oder verändert, nicht mit Bordmitteln des Azure AD wiederherstellen.

Bei allen Entwicklungen, denen die Clouddienste nahezu auf täglicher Basis unterworfen sind, sollten Sie mittelfristig keine Hoffnungen darin setzen, dass die Cloudanbieter eine native Wiederherstellung aller Dienste realisieren werden. Eine solche Funktion, zusammen mit der Möglichkeit, die Backupdaten in einem maschinenlesbaren Format aus der Cloud zu extrahieren, würde nämlich ein valides Offboarding-Szenario darstellen. Ein Wettbewerber könnte damit theoretisch eine vollständige Übertragung des gesamten M365-Tenants in seine eigene Cloud ermöglichen. Dass dies nicht im Interesse der Cloudanbieter ist, liegt auf der Hand.

Viele Architekten für Datenhaltung weisen bereits seit Jahrzehnten darauf hin, dass ein Backupverfahren in erster Linie nicht nach Erfolg, Performance und anderen Merkmalen der Sicherung beurteilt werden sollte, sondern nach der Qualität der Wiederherstellung. In Verbindung mit Microsoft 365 besteht hier ein prinzipielles Problem, auf das M365-Experten wie Tony Redmond [4] bereits häufiger hingewiesen haben. Für die meisten Anwendungen aus dem Microsoft-365-Universum existiert nämlich kein valides Wiederherstellungsziel jenseits von Microsoft 365.

Obgleich Sie ein Exchange-Online- oder SharePoint-Onlinebackup theoretisch auf einem lokalen Server wiederherstellen können, gibt es für die übrigen M365-Anwendungen keine andere Wahl, als sie in einem M365-Tenant wiederherzustellen. Denken Sie nur an Teams: Die Daten sind zwar nahezu vollständig in Azure AD, Exchange Online und SharePoint Online gespeichert, die Funktionalität der Anwendung ist jedoch nicht anhand dieser Daten in einer anderen Umgebung als Microsoft 365 abbildbar. Damit wird noch einmal deutlich, dass das Szenario "Totalverlust der Infrastruktur" beim Design Ihres Cloudbackups keine vorrangige Rolle spielen kann und Sie sich auf das Szenario "Zurückrollen von unbeabsichtigten Änderungen" konzentrieren sollten.

Für einzelne Anwendungen wie etwa Planner sind Exportverfahren als "Datensicherung" denkbar, die die anwendungsspezifischen Daten in Formate anderer Anwendungen konvertieren – also zum Beispiel die Tasks-Aufgaben in Outlook-Aufgaben oder Planner-Projektpläne in Excel-Tabellen. Solche Umwandlungen sind stets mit Beeinträchtigungen des Benutzeralltags sowie mit einem Verlust an Funktionalität verbunden und sollten daher als die letzte Möglichkeit angesehen werden, um eine geschäftskritische Anwendung im Falle des Totalverlusts aufrechtzuerhalten.

Derzeit gibt es kaum fertige Produkte auf dem Markt, um solche Konvertierungen als dauerhafte Prozesse zu etablieren. Sie können sich jedoch der vielfältigen Integrationen in PowerAutomate bedienen, um die strukturierten Daten aus M365-Anwendungen in anderen Formaten abzulegen, wie es beispielsweise unter [5] demonstriert wird.

Kein Unternehmen und keine Organisation existiert heutzutage isoliert. Ein wichtiges Bedrohungsszenario, das Sie mit Backup- und Restore-Mitteln nicht lösen können, ist folgendes: Die Clouddienste sind intakt, aber der Verwaltungs- oder Produktionsstandort ist längerfristig vom Internet und somit von der Cloud abgeschnitten. Viele Anwendungen könnten Sie theoretisch vor Ort weiterbetreiben, doch laufen möglicherweise die Datenbestände mit der ursprünglichen Anwendung auseinander und lassen sich meistens nicht verlustfrei zusammenführen, wenn die Konnektivität wiederhergestellt ist.

Diesen Fall müssen Sie deshalb nicht als Teil Ihrer Datensicherungsstrategie und auch nicht rein technisch, sondern auf einer höheren Ebene als technisch-organisatorischen Aspekt der Business-Resilience-Strategie behandeln. Daraus leiten Sie im nächsten Schritt die Handlungsrichtlinien für Ihre Backupstrategie ab. Sehr oft werden Sie feststellen, dass der Ersatzbetrieb der SaaS-Anwendungen on-premises zwar möglich ist, aus Business-Sicht jedoch keinen Sinn ergibt. Ohne Internetkonnektivität können Sie zwar die interne Funktion der Anwendung nachbauen, die zunehmend wichtigen externen Beziehungen sind aber weiterhin nicht möglich.

Damit Ihre Microsoft-365-Backup-Strategie aufgeht und Sie im Restore-Fall genau das bekommen, was Sie erwarten, müssen Sie also besonders genau formulieren, welche Anwendungen Sie gegen welche Bedrohungsszenarien absichern möchten. Dabei spielen die für Backup üblichen Indikatoren wie RPO (Recovery Point Objective – wie viele Minuten, Stunden oder Tage Arbeit dürfen verloren gehen) und RTO (Recovery Time Objective – wie lange dauert die Wiederherstellung ab Feststellung des Datenverlustes) eine Rolle. Allerdings ist es nahezu unmöglich, eine gemeinsame RPO-/RTO-Richtlinie für alle Anwendungen festzulegen.

Doch auch über das jeweilige Backupziel müssen Sie sich Gedanken machen, um das formulierte Bedrohungsszenario vollständig abzudecken. Bei der Sicherung von Daten aus Cloudanwendungen haben Sie in der Regel drei Möglichkeiten zur Auswahl: Cloudspeicher in der Cloud des gleichen Anbieters, Cloudspeicher in der Cloud eines anderen Anbieters oder On-Premises-Speicher.

Für die typischen SaaS-Anwendungen wie Exchange Online oder SharePoint Online kommen sowohl die Forrester-Analysten [2] als auch die Experten von AvePoint [3] zu dem Ergebnis, dass es nicht sinnvoll ist, Clouddaten auf ein lokales Speicherziel zu sichern. Der bereits bei der Sicherung entstehende Datenverkehr belastet die Internetleitung ins Unternehmen und kann auf Dauer durchaus ins Geld gehen. Bei großen Datenmengen nimmt die Wiederherstellung zurück in die Cloud mitunter viel Zeit in Anspruch, wozu auch die bei den SaaS-Providern übliche Bandbreiten-Drosselung der externen Zugriffe beiträgt. Falls Ihr definiertes Bedrohungsszenario allerdings die Möglichkeit eines dauerhaften Ausfalls der Internetanbindung und damit der Verbindungen in die Cloud beinhaltet, müssen Sie auch einen validierten Restore-Ansatz für dieses Szenario vorsehen, der einen lokalen Backupspeicher und eine ausreichend dimensionierte On-Premises-Infrastruktur einschließt.

Die Anforderungsmatrix für Ihr umfassendes M365-Backup-Design kann beispielsweise so aussehen, wie in der Tabelle "RPO- und RTO-Vorgaben" dargestellt. Mit "Verlust der Konnektivität" ist freilich kein vorübergehender, sondern ein dauerhafter Verlust gemeint, also länger als die RTO.

Ein weiteres Kriterium für die Auswahl der geeigneten Backupverfahren ist die Zeitspanne, über die die Datenstände rückwirkend nachzuvollziehen sind. Um hier eine optimale Kombination aus Bordmitteln und Drittanbieter-Produkten zu bestimmen, müssen Sie sich mit den Aufbewahrungs- und Versionierungsmöglichkeiten der einzelnen Anwendungen beschäftigen. Die Kernanwendungen, deren Datenhaltung auf Exchange Online und SharePoint Online basiert, profitieren von den Aufbewahrungsrichtlinien und dem Legal-Hold-Löschschutz dieser Produkte. Andere Anwendungen wie Planner oder M365-Infrastrukturdienste wie Intune oder Defender for Endpoint bieten keine oder sehr begrenzte Fähigkeiten, um Inhalte automatisch zu versionieren.

Denken Sie daran, dass jegliche Versionierung oder Langzeitaufbewahrung das in der Anwendung vorgehaltene Datenvolumen erhöht, sodass die geltenden Speichergrenzwerte erreicht werden können, obwohl die aktiv genutzte Datenmenge gar nicht so groß ist. In SharePoint Online zum Beispiel kann eine Datei bis zu 50.000 Versionen haben, das Speicherlimit pro Website-Sammlung beträgt 25 TByte. Eine Datei, die an jedem Werktag von 9 bis 17 Uhr stündlich gespeichert wird, erzeugt etwa 2500 Versionen pro Jahr.

Hat Ihre Anforderungsanalyse ergeben, dass Sie für die Kernapplikationen Ihres M365-Mandanten (das heißt, für alle Dienste, deren Datenhaltung auf SharePoint oder Exchange beruht) das Datensicherungsprodukt eines Drittanbieters einsetzen wollen oder müssen, haben Sie die Wahl zwischen zwei grundverschiedenen Speicherstrategien:

- Cloudbackup-Anbieter wie die Klassiker SkyKick [6] und Carbonite [7], die bereits zitierte AvePoint oder die Frankfurter brycks cloud [8] bieten die Sicherung Ihrer M365-Daten in die Public Cloud oder in eigene Rechenzentren. In jedem Fall ist der Storage, auf dem Ihre Daten liegen, im Abonnement enthalten.

- Klassische Backupanbieter wie Veeam [9] oder Veritas [10] lassen Ihnen die freie Wahl des Sicherungsziels. Falls Ihr lokales SAN und die Internet-Downlinks noch Kapazitätsreserven frei haben, können Sie die Clouddaten lokal sichern. Andernfalls bietet sich die Nutzung des S3-kompatiblen Cloudspeichers Ihrer Wahl oder von Azure Blob Storage an. In diesem Fall zahlen Sie die Lizenzen für die eingesetzte Software (meistens pro M365-Benutzer) und die Kosten für den anfallenden Storage pro TByte separat.

Beide Modelle bieten technisch und kaufmännisch gesehen Vor- und Nachteile, die es abzuwägen gilt. Haben Sie viele User, die nur wenig M365-Daten erzeugen, und nur einige Power-User, dürfte sich das Kostenmodell mit separater Storage-Abrechnung auf lange Sicht lohnen. Bei gleichmäßiger Verteilung des genutzten Datenvolumens auf die einzelnen User und hohem Änderungstempo profitieren Sie von den schnellen Anbindungen und dem Inklusiv-Storage der Cloudanbieter.

Sowohl Microsoft als auch Drittanbieter beherrschen das Sichern von Anwendungen, deren Datenhaltung auf Exchange Online und SharePoint Online basiert. Dabei können Sie bereits mit Retention Policies von M365 ein hohes Maß an Schutz gegen unbeabsichtigte Änderungen oder Löschungen erreichen – um den Preis des hohen Speicherverbrauchs innerhalb der Anwendungen. Drittanbieter erlauben Ihnen, diese Daten in eine Public Cloud oder auf einen lokalen Storage zu sichern.