white disc on laptop computer disc player

Brauche ich in Microsoft 365 ein Backup?

Diese Frage ist bei einem Cloud-Projekt essentiell. In diesem Beitrag analysiere ich das Für und Wider und gebe Ihnen einige Ratschläge, wie Sie sich warum entscheiden sollten.

Wenn ich für jedes Mal, wenn ich diese Frage höre, 1 Euro bekommen würde, wäre ich schon im Ruhestand 😉 Es gibt keine wirkliche JA- oder NEIN-Antwort – die Antwort ist eine typische Antwort eines (guten) Beraters: es kommt darauf an! Ich bin mir ziemlich sicher, dass die meisten von Ihnen diese Antwort hassen, aber nehmen Sie es uns nicht übel, wir versuchen nur, die Lösung zu finden, die am besten zu Ihren Bedürfnissen passt. Mit diesem Artikel gebe ich Ihnen einen Überblick darüber, was Microsoft anbietet und was nicht.

In diesem Artikel liefere ich einen Überblick, mit oder gegen welche Argumente und Aussagen ich in meinen Projekten diskutiere und was dahintersteckt. Da dieser Artikel verhältnismßig lang ist, sind Sie gerne eingeladen direkt zu dem für Sie interessanten Punkt zu springen:

Ich brauche ein Backup, weil ich schon immer eines hatte!

Ich muss meine Daten aufgrund einer gesetzlichen Vorschrift aufbewahren

Ich brauche ein Backup, weil ich eine Ordnerstruktur wiederherstellen können muss

Ich brauche ein Backup für den Fall einer versehentlichen Benutzerlöschung

Ich benötige ein Backup für den Fall eines Krypto-Trojaner-Angriffs

Ich brauche eine Ausstiegsstrategie aus Microsoft 365

Zusammenfassung

Weiterführende Links

Ich brauche ein Backup, weil ich schon immer eines hatte!

Falsch. Einfach nur falsch. Falsch falsch falsch falsch falsch falsch falsch falsch. Habe ich schon falsch gesagt? Falsch!

Insofern Ihre Einstellung zu diesem Thema der Überschrift entspricht, sollten Sie genau hier aufhören, mit Clouddiensten zu arbeiten. Was diesen Artikel betrifft, hören Sie auch gerne genau hier auf zu lesen und wechseln Sie zu anderen Seiten wie dieser -> Welcome to Microsoft’s Homepage (archive.org) (und schwelgen Sie dort in Erinnerungen an die gute alte Zeit). Mit einer derartigen unveränderlichen Meinung beweist man, dass man die Funktionsweise von Clouddiensten nicht nur nicht verstanden hat sondern auch kein Interesse hat sich der modernen Technologie zu widmen. Folglich macht eine Diskussion keinen Sinn.

Sofern Sie die Überschrift vertreten aber offen für Diskussionen sind – wunderbar! Dann sind Sie in diesem Artikel genau richtig!

Sie mögen jetzt denken:

Andreas, das ist aber eine sehr extreme Einstellung!

Stimmt. Ich habe in meinem Leben als Consultant und später Architekt für Micrsoft Cloud immer wieder erlebt, dass Personen mit einer vorgefertigten unveränderbaren negativen oder veralteten Grundhaltung diejenigen sind, die ein Cloudprojekt zum scheitern bringen. Darum ist dieses Thema bei mir emotional behaftet. Aber zurück zum Thema. Warum ist die Einstellung Ich brauche ein Backup weil ich schon immer eins gemacht habe denn so falsch?

Um dies zu verstehen muss man analysieren, was die ursprünglichen Gründe für die Anschaffung einer Backupsoftware waren. Wieso fertig(t)en Unternehmen also Backups an?

  • um einen Server nach einem K-Fall Szenarion wieder herstellen zu können (bare metal restore)
  • Desaster Wiederherstellung
  • um eine Datenbank wiederherzustellen (z.B. SQL oder eine Maildatenbank in Exchange)
  • um die Konfiguration einer Software zu sichern (eine Art selbst gestricktes DSC)

Diese Gründe waren und sind für on-premises Systeme absolut valide! Aber wie schaut es mit M365 aus?

  • Serverwiederherstellung -> das ist die Aufgabe des Hosters (Microsoft), nicht Ihre
  • Desaster Wiederherstellung -> das ist die Aufgabe des Hosters (Microsoft), nicht Ihre
  • Datenbankwiederherstellung -> das ist die Aufgabe des Hosters (Microsoft), nicht Ihre
  • Konfigurationen speichern -> dies ist ein nachvollziehbarer Grund, aber dafür benötigt man in M365 keine Backupsoftware. Dies geht wesentlich günstiger.

Heißt im Umkehrschluß: Für die altmodischen Gründe benötigt man kein Backup mehr. Kurz zusammengefasst:

Mit Microsoft 365 ist man kein Administrator eines dedizierten Systems mehr, das man jeden Tag pflegen muss, sondern der Administrator eines Dienstes. Das bedeutet, dass man keinen Server mehr hat, um den man sich liebevoll kümmern muss, damit es ihm gut geht. Diese Aufgabe übernimmt der Hoster. In unserem Fall ist das Microsoft

Ich muss meine Daten aufgrund einer gesetzlichen Vorschrift aufbewahren

Ich kenne viele Kunden, die für diesen Anwendungsfall Backup Software in Betracht ziehen. Grundsätzlich kann man gegen diesen Ansatz aus technischer Sicht nichts sagen. Das Gesetz gibt eine Regel vor wie diese: „Halte alle Daten für X Jahre vor“. WIE diese Regel umgesetzt werden soll, liegt in der Hand des Kunden.

In Microsoft 365 gibt es eingebaute Aufbewahrungsrichtlinien (Retention Policies). Diese kennt man meist bereits aus Exchange, in M365 existieren diese aber für den kompletten Tenant, nicht nur für den Exchange Dienst. Mit den Aufbewahrungsrichtlinien können Daten aus Exchange, OneDrive, SharePoint und Teams problemlos gesichert werden. Es ist konfigurierbar ob die Daten auf Basis von Schlüsselwörtern, Gruppenmitgliedschaften, Dienst, pro Benutzer oder einer Kombination dieser gesichert werden.

Die hier beschriebenen Werkzeuge sind dafür gedacht, gesetzliche Anforderungen zu erfüllen. Sie heben alle Daten auf – für den Benutzer transparent und nicht änderbar. Benötigt man Zugriff auf die gesicherten Daten, steht ein Tool namens eDiscovery zur Verfügung. Die grafische Oberfläche hierfür st zwar untrirdisch hässlich und Lichtjahre von Benutzerkomfort entfernt (das ändert sich vielleicht irgendwann – hoffentlich), aber sie ist da. Sie ist in vielen Lizenzplänen ohne Extrakosten abgedeckt. Das bedeutet „kostenlos“ – oder „ohne Extrakosten“, da keine zusätzlichen Lizenzen beschafft werden müssen. Die Details können auf dieser Seite nachgelesen werden: Microsoft 365 licensing guidance for security & compliance.

Ich brauche ein Backup, weil ich eine Ordnerstruktur wiederherstellen können muss

eDiscovery und Aufbewahrung sind nützliche Funktionen, aber sie sind nicht dazu gedacht, Strukturen 1:1 zu sichern. Hierfür bräuchte dieses Werkzeug auch enorme künstliche Intelligenz, die in der Lage ist, Strukturänderungen zu erkennen und entsprechend zu verarbeiten. Dies ist absolut nicht der Anwendungsfall eines Werkzeugs für gesetzliche Anforderungen.

Für (Ordner)strukturen muss man sich also auf die von Microsoft eingebauten Mechanismen verlassen. Für Outlook, SharePoint und OneDrive ist dies der Papierkorb. Teams können von einem Adminsitrator wiederhergestellt werden. Ein etwas tieferer Blick:

  • Exchange zwingt keinen Outlook Client beim Beenden den Papierkorb zu leeren. Dies kann aber durch einen Administrator vorgegeben werden.
  • Exchange hält alle gelöschten Daten im Papierkorb für 14 Tage. Dieses Zeitfenster kann administrativ auf 30 Tage erweitert werden.
  • Exchange hält Junk Emails für 30 Tage vor. Der Benutzer kann diese früher löschen oder aus dem Junk Ordner verschieben indem er sie als „nicht Junk“ markiert.
  • Exchange hält die Ordnerstruktur nicht vor, wenn der Papierkorb geleert wird.

Für SharePoint und OneDrive:

  • SharePoint Online hält gelöschte Daten in Websitesammlungen (Site collections) für 93 Tage vor. An Tag 94 werden diese endgültig gelöscht.
  • SharePoint Online hält gelöschte Seiten und Websitesammlungen für 93 Tage vor. An Tag 94 werden diese endgültig gelöscht.
  • OneDrive basiert auf SharePoint Technologie -> 93 Tage.
  • Ein gelöschtes OneDrive kann noch für 30 Tage nach Löschung in M365 aufgerufen werden. An Tag 31 wird dieses endgültig gelöscht. Wird der ursprüngliche Benutzer innerhalb von 30 Tagen wiederhergestellt, dann wird OneDrive automatisch wieder verbunden. Die Aufbewahrungsdauer kann administrativ via PowerShell auf bis zu 10 Jahre verlängert werden:
    SetSPOTenant -OrphanedPersonalSitesRetentionPeriod 3560

Für Microsoft Teams:

  • ein gelöschtes Team wird für 30 Tage aufgehoben. Ein Administrator kann es wiederherstellen.
  • Gelöschte Inhalte werden solange aufgehoben wie die Konfiguration des zu Grunde liegenden Dienstes (z.B. SharePoint Online für Dateien).
  • Ein Team kann archiviert werden (=nur Lesezugriff), damit die dort erarbeiteten Daten für einen längeren Zeitraum leicht abrufbar bleiben.

Ich brauche ein Backup für den Fall einer versehentlichen Benutzerlöschung

Das versehentliche Löschen eines Benutzers ist eine blöde Sache, die zum Glück nur sehr selten vorkommt. Aber wenn es passiert, haben Sie einen sehr unglücklichen Benutzer und wollen ihn beruhigen, indem Sie alles wiederherstellen, wie es vorher war. Glücklicherweise hat Microsoft eine 30-tägige Aufbewahrungsfrist für alles eingebaut, wenn ein Benutzer gelöscht wird.

Das heißt, wenn Sie einen Benutzer aus dem AADConnect Sync herausnehmen (z.B. Verschieben in eine andere nicht gesyncte OU), wird der Benutzer in den Azure AD-Papierkorb verschoben (oh – noch ein Papierkorb!) und alle Dienste werden für diesen Benutzer deaktiviert. Wenn Sie diesen Benutzer innerhalb von 30 Tagen wiederherstellen, werden alle Dienste (einschließlich aller Daten) wiederhergestellt und verbunden. Mit anderen Worten: Innerhalb von 30 Tagen wird nichts gelöscht!

Ich benötige ein Backup für den Fall eines Krypto-Trojaner-Angriffs

Ich kann die Angst verstehen, aber dies als Anwendungsfall für ein Backup zu verwenden, ist nicht die richtige Diskussion. Außerdem sollten Sie die besser Eingangstür, die ein solcher Trojaner benutzt, schließen: da viele Virenscanner nicht in der Lage sind, Krypto-Trojaner direkt nach der Veröffentlichung zu erkennen, versuchen sie, durch Ihre Abwehr schlüpfen.

Um dem entgegenzuwirken, gibt es in Microsoft 365 ein Tool namens Microsoft Defender for Endpoint – alter Name Office 365 Advanced Threat Protection. Dieses nutzt verschiedene Technologien wie KI, Heuristik und Sandboxing, um Anhänge auf Malware wie Krypto-Attacken, Spear-Phishing und andere moderne Angriffsarten zu testen. Microsoft war einer der ersten Hersteller, der eine solche Lösung angeboten hat, mittlerweile haben alle großen Player etwas Ähnliches veröffentlicht. Defender for Endpoint ist auf jeden Fall billiger als eine Backup-Software (nur nicht, wenn man ein kostenloses Backup bekommt) und schließt Ihre Haustür zu >99,999%. Ich persönlich sage nie 100%, weil ich der Typ Consultant bin, der sagt „es gibt keine 100%ige Sicherheit“.

Ich brauche eine Ausstiegsstrategie aus Microsoft 365

Viele Unternehmen haben gerne einen Plan B im versiegelten Umschlag im Schreibtisch. Das ist durchaus nachvollziehbar und absolut OK. Während Sie die Ausstiegsstrategie als Plan B definieren, müssen Sie sich überlegen, wie Sie Ihre Daten aus Microsoft 365 herausbekommen können. Ein Backup kann ein sehr einfacher Ansatz dafür sein. Aber stellen Sie sich eine sehr, sehr wichtige Frage:

Wenn ich alles im Backup habe, wie und wo kann ich die Daten wiederherstellen, wenn ich nicht mehr Kunde von Microsoft 365 bin?

Wenn Sie Ihre Ausstiegsstrategie umsetzen, können Sie Ihr Backup logischerweise nicht mehr in Microsoft 365 wiederherstellen. Übrigens macht es meiner Meinung nach auch überhaupt keinen Sinn, etwas auf ein Ziel wiederherzustellen, von dem Sie sowieso weg wollen. Vielleicht haben Sie die Idee, auf Ihre alte On-Prem-Infrastruktur wiederherzustellen. Das Einzige, was man zu dieser Idee sagen kann, ist „Viel Glück!“. Die Online-Dienste haben viele Funktionen, die für On-Premises nie freigegeben wurden und werden. Bestes Beispiel: Microsoft Teams. Es ist unmöglich (!!), Daten auf einen Dienst wiederherzustellen, der nicht den vollen Funktionsumfang bietet, denn wohin soll die Software wiederherstellen, wenn es kein Ziel gibt? Die einzige Möglichkeit die bleibt: Fragmente aus dem Backup herauspicken. Wenn Sie Millionen (oder mehr) Elemente haben, sind Sie damit für die nächsten Monate beschäftigt.

Eine Ausstiegsstrategie mag in der Tat eine gute Idee sein, aber eine Backuplösung ist nicht der richtige Ansatz dafür. An dieses Thema muss man sich wieder mit Hilfe der Boardmittel annähern, zum Beispiel Exchange Hybrid oder mit dedizierten Migrationstools, die den eigenen Anwendungsfall abdecken und sowohl Quelle als auch Ziel unterstützen.

Zusammenfassung

Ich habe Ihnen in diesem Artikel die Fragen und Gedanken gespoilert, mit denen ich mich in den meisten Diskussionen auseinandersetzen muss. Wie Sie sehen, ist es keine leichte Entscheidung. Und das wird sie auch nie sein. Ich persönlich denke, dass in >90% aller Fälle ein Backup nicht notwendig ist. Wenn Sie regulatorische oder gesetzliche Anforderungen haben, die Sie dazu zwingen, alle Daten an einem zweiten (anderen) Ort zu speichern, oder wenn Sie eine 105%ige Versicherung gegen witzige Dinge wie Krypto-Trojaner brauchen, dann können Sie gerne darüber nachdenken. Wenn all das nicht der Fall ist, werfen Sie einen intensiven Blick auf alle Tools, die Microsoft 365 für Sie im Portfolio hat (ohne zusätzliche Kosten!!) und nutzen Sie diese.

Natürlich sind wir offen für weitere Diskussionen – nutzen Sie gerne das Kontaktformular um mit uns in Kontakt zu treten und die Diskussionen zu vertiefen.

Zum Abschluß habe ich noch eine Sammlung von Links, die ich bei der Erstellung dieses Artikelt verwendet habe (ich bin bei den englischen Versionen geblieben, weil die deutschen teilweise furchtbar übersetzt sind – Sie können aber gerne selber nach dem Aufrufen auf Deutsch umstellen):

Exchange Online service description – Service Descriptions | Microsoft Docs

Exchange Online Archiving service description – Service Descriptions | Microsoft Docs

Archive features in Exchange Online Archiving – Service Descriptions | Microsoft Docs

SharePoint service description – Service Descriptions | Microsoft Docs

Restore deleted sites – SharePoint in Microsoft 365 | Microsoft Docs

OneDrive retention and deletion – OneDrive | Microsoft Docs

Use retention labels to manage the lifecycle of documents stored in SharePoint – Microsoft 365 Compliance | Microsoft Docs

Microsoft Teams service description – Service Descriptions | Microsoft Docs

Archive or delete a team in Microsoft Teams – Microsoft Teams | Microsoft Docs

Published by Andreas

Gründer von M365 Evangelists Cloud-Architekt, Strategieberater, Consultant für Microsoft Technologien Graph API Enthusiast, PowerShell Enthusiast