Aufbewahrung in Microsoft 365 ist kein Backup-Konzept

In Microsoft 365 existieren Papierkorb, Versionen, Aufbewahrungsrichtlinien, Archivierungsfunktionen, Wiederherstellungswege und eine eigene Backup-Lösung. Gerade diese Vielfalt führt zu einer gefährlichen Verkürzung: „Die Daten sind in der Cloud und werden aufbewahrt, also ist das Backup geklärt.“

Aufbewahrung und Wiederherstellung verfolgen jedoch unterschiedliche Ziele. Compliance kann verlangen, bestimmte Inhalte unverändert zu erhalten oder nach einer Frist zu löschen. Der Betrieb muss nach einem Fehler dagegen möglichst schnell wieder mit einem brauchbaren Datenstand arbeiten können. Beides kann sich ergänzen, ist aber nicht dasselbe.

Ein belastbares Konzept beginnt deshalb nicht mit der Frage, welches Produkt gekauft wird. Es beginnt mit den Ereignissen, gegen die sich die Organisation schützen muss, und dem Zustand, den sie danach wiederherstellen will.

Fünf Begriffe, fünf verschiedene Fragen

Die konkrete Funktionsweise hängt von Dienst, Lizenz, Konfiguration und Produktstand ab. Für die Entscheidung hilft zunächst eine funktionale Trennung:

Fähigkeit	Primäre Frage
Versionierung	Kann eine frühere Fassung eines einzelnen Inhalts wieder genutzt werden?
Papierkorb und native Wiederherstellung	Kann kürzlich gelöschter oder veränderter Inhalt innerhalb der vorgesehenen Produktgrenzen zurückgeholt werden?
Aufbewahrung	Welche Inhalte müssen aus Compliance-, Rechts- oder Informationsgründen erhalten oder gelöscht werden?
Archivierung	Welche nicht mehr aktiv genutzten Inhalte sollen geordnet, auffindbar und kostengerecht fortbestehen?
Backup	Wie wird nach Datenverlust oder schädlicher Veränderung ein benötigter Arbeitsstand in einer vereinbarten Zeit wiederhergestellt?

Diese Fähigkeiten können technisch aufeinander aufbauen oder überlappen. Sie bleiben trotzdem unterschiedlichen Anforderungen verpflichtet. Eine Aufbewahrungskopie kann für Recherche oder eDiscovery geeignet sein, ohne den gewünschten operativen Restore-Ablauf für ein komplettes Team oder einen konsistenten früheren Stand bereitzustellen.

Microsoft Purview beschreibt Aufbewahrungsrichtlinien und -bezeichnungen als Instrumente, um Inhalte zu erhalten und zu löschen. Microsoft dokumentiert zugleich Microsoft 365 Backup als gesonderte Lösung für Wiederherstellungsszenarien. Schon diese Produkttrennung zeigt: „wird aufbewahrt“ und „kann wie benötigt wiederhergestellt werden“ sind keine austauschbaren Aussagen.

Szenarien vor Funktionen

Die Anforderungen werden klarer, wenn das Team konkrete Verlust- und Wiederherstellungssituationen durchgeht:

• Ein Nutzer löscht versehentlich eine einzelne Datei.
• Ein Ordner oder Postfach wird erst spät als fehlend erkannt.
• Viele Dateien werden gleichzeitig verschlüsselt oder überschrieben.
• Ein Team, eine Site oder ein Benutzerkonto wird falsch gelöscht.
• Eine fehlerhafte Synchronisation verteilt eine unerwünschte Änderung.
• Inhalte müssen für eine rechtliche oder regulatorische Anforderung erhalten bleiben.
• Konfiguration, Berechtigungen, Gruppen oder Identitäten sind beschädigt.
• Der Microsoft-Dienst selbst ist vorübergehend nicht verfügbar.

Nicht jedes dieser Ereignisse wird von derselben Funktion, im selben Umfang oder mit demselben Zeitverhalten abgedeckt. Besonders wichtig ist die Grenze zwischen Daten und Konfiguration. Selbst wenn Dateien und Nachrichten gesichert sind, müssen möglicherweise Sites, Teams, Berechtigungen, Gruppen, Workflows oder Identitätsbezüge rekonstruiert werden. Der tatsächliche Leistungsumfang einer nativen oder externen Lösung ist deshalb gegen die eigene Umgebung zu prüfen.

RPO und RTO müssen verständlich werden

Zwei Begriffe helfen, wenn sie nicht als reine Technikwerte behandelt werden:

• Das Recovery Point Objective (RPO) beschreibt, wie viel Datenänderung zwischen letztem nutzbaren Stand und Störung höchstens verloren gehen darf.
• Das Recovery Time Objective (RTO) beschreibt, innerhalb welcher Zeit eine benötigte Leistung wieder verfügbar sein soll.

Für einen wenig genutzten Archivbereich können andere Ziele gelten als für ein operatives Auftragspostfach oder eine zentrale Projektablage. Die Werte dürfen nicht allein von der IT geschätzt werden. Der Fachbereich muss erklären, welche Arbeit nachgeholt werden kann, wann ein Stillstand kritisch wird und welcher Datenstand fachlich konsistent ist.

Der BSI-Baustein CON.3 Datensicherungskonzept ordnet Sicherungsanforderungen, Verantwortlichkeiten und Wiederherstellungstests in ein systematisches Konzept ein. Der Grundsatz gilt auch in SaaS-Umgebungen: Die Plattformwahl nimmt der Organisation nicht die Entscheidung ab, welcher Wiederherstellungsstand wann benötigt wird.

Eine Anforderungsmatrix statt einer Backup-Debatte

Eine kompakte Matrix verbindet Geschäftsbedarf und technische Prüfung:

Feld	Zu klärende Frage
Service und Daten	Welche Arbeitsleistung und welche Microsoft-365-Inhalte sind betroffen?
Verlustszenario	Löschen, Überschreiben, Verschlüsselung, Fehlkonfiguration, Ausfall oder Compliance-Fall?
benötigter Zustand	Einzelobjekt, kompletter Bereich, konsistenter Zeitpunkt oder nur lesbarer Nachweis?
RPO	Wie aktuell muss der wiederhergestellte Stand sein?
RTO	Wann muss die Arbeit wieder möglich sein?
Aufbewahrung	Was muss wie lange erhalten oder gelöscht werden und warum?
Abdeckung	Welche Daten, Metadaten, Berechtigungen und Konfigurationen umfasst die Lösung tatsächlich?
Zugriffstrennung	Wer darf Sicherungen verändern, Wiederherstellungen auslösen und Ergebnisse einsehen?
Wiederherstellungsweg	Wohin wird restauriert, wie wird geprüft und wie werden Konflikte behandelt?
Testnachweis	Wann wurde das Szenario zuletzt vollständig und erfolgreich erprobt?

Die Matrix verhindert zwei typische Fehler: eine pauschale Behauptung, native Funktionen reichten immer aus, und die ebenso pauschale Forderung nach einem Drittprodukt. Die richtige Lösung hängt vom geforderten Ergebnis ab.

Konstruiertes Beispiel: Aufbewahrt, aber nicht arbeitsfähig

Das folgende Beispiel ist konstruiert.

Ein Projektbereich in SharePoint unterliegt einer Aufbewahrungsanforderung. Nach einer massenhaften Verschlüsselung zahlreicher Dateien sind frühere Inhalte grundsätzlich noch erhalten. Das Projektteam benötigt jedoch einen zusammenhängenden, nutzbaren Arbeitsstand vor dem Ereignis, einschließlich passender Struktur und Zugriffsrechte.

Die Compliance-Verantwortliche kann nachweisen, dass relevante Inhalte nicht endgültig verschwunden sind. Der Betrieb hat damit noch nicht beantwortet, wie der gesamte Bereich in der notwendigen Zeit wieder arbeitsfähig wird. Einzelnes Suchen, Exportieren und Zurückkopieren kann für einen Rechtsnachweis genügen, aber das vereinbarte RTO verfehlen.

Das Problem ist nicht, dass Aufbewahrung „schlecht“ wäre. Sie erfüllt einen anderen Zweck. Erst die Szenariomatrix zeigt, ob native Wiederherstellung, Microsoft 365 Backup, ein anderer Sicherungsdienst oder eine Kombination den benötigten Arbeitsstand liefern kann.

Aufbewahrung besitzt eigene Nebenwirkungen

Aufbewahrungsregeln dürfen nicht beiläufig als zusätzlicher Schutzschalter konfiguriert werden. Sie beeinflussen Löschung, Speicher, Auffindbarkeit und den Umgang mit personenbezogenen oder vertraulichen Inhalten. „Alles für immer behalten“ ist weder automatisch rechtssicher noch wirtschaftlich sinnvoll.

Microsoft erläutert für SharePoint und OneDrive, wie aufbewahrte Inhalte verarbeitet und in dafür vorgesehenen Bereichen erhalten werden. Diese Mechanismen und Produktdetails können sich ändern. Vor Umsetzung sind daher aktuelle Dokumentation, Lizenzierung und die konkrete Mandantenkonfiguration zu prüfen.

Die fachliche Verantwortung für Fristen liegt zudem nicht allein bei der IT. Datenschutz, Recht, Compliance, Records Management und die jeweiligen Informations-Owner müssen den Zweck und die zulässige Dauer festlegen. Die IT übersetzt diese Vorgaben in Konfiguration und Betrieb, darf sie aber nicht erfinden.

Zugriffstrennung gehört zum Wiederherstellungskonzept

Eine Sicherung ist weniger belastbar, wenn dieselbe kompromittierte Identität Produktivdaten und Sicherung ungehindert verändern oder löschen kann. Zu prüfen sind deshalb:

• getrennte administrative Rollen,
• starke Authentisierung und Notfallzugänge,
• Protokollierung von Richtlinienänderungen und Restores,
• Schutz vor versehentlicher oder böswilliger Löschung von Sicherungen,
• kontrollierte Freigabe besonders weitreichender Wiederherstellungen,
• Zugriff auf wiederhergestellte vertrauliche Inhalte.

Trennung darf den Notfall nicht blockieren. Vertretung, Zugang und Entscheidungsrecht müssen vorab getestet sein. Der gleiche Grundsatz gilt für externe Freigaben: Der Beitrag „Externe Freigaben in Microsoft 365 brauchen ein Ablaufdatum“ beschreibt, warum technische Berechtigung und fachliche Verantwortung gemeinsam geführt werden müssen.

Ein Restore-Test endet nicht beim erfolgreichen Job

Microsoft beschreibt für Microsoft 365 Backup unterschiedliche Wiederherstellungsabläufe. Ob ein technisch erfolgreicher Restore den Betrieb wiederherstellt, muss die Organisation selbst prüfen.

Ein realistischer Test beantwortet:

1. Erkennt der Service Desk das Szenario und eskaliert an die richtige Rolle?
2. Kann die befugte Person den passenden Wiederherstellungspunkt auswählen?
3. Wird an den ursprünglichen oder einen alternativen Ort restauriert?
4. Sind Daten, Versionen, Metadaten und Berechtigungen wie benötigt vorhanden?
5. Kann der Fachbereich den Geschäftsvorgang fortsetzen?
6. Werden Änderungen seit dem Wiederherstellungspunkt kontrolliert nachgeführt?
7. Bleiben Aufbewahrungs- und Datenschutzanforderungen eingehalten?

Der allgemeine Beitrag „Ein Backup ist erst nach einem erfolgreichen Restore belastbar“ vertieft die organisatorische Testlogik. Für Microsoft 365 muss sie auf die konkreten Dienste und Abhängigkeiten übertragen werden.

Produktentscheidung erst nach der Lückenanalyse

Nach der Anforderungsmatrix werden vorhandene Funktionen geprüft. Für jedes Szenario gibt es dann drei mögliche Ergebnisse:

• Die native Fähigkeit erfüllt Ziel und Nachweis ausreichend.
• Eine Konfigurations-, Prozess- oder Lizenzlücke muss geschlossen werden.
• Eine zusätzliche Backup- oder Archivlösung ist erforderlich.

Bei der Produktauswahl zählen nicht nur Sicherungsumfang und Preis. Relevant sind auch Wiederherstellungsgeschwindigkeit, Granularität, Datenstandort, Verschlüsselung, Rollenmodell, Exportfähigkeit, Mandantenwechsel, Protokollierung, Anbieterabhängigkeit und regelmäßig nachweisbare Tests. Produkt- und Lizenzangaben sind zeitabhängig und müssen zum Entscheidungszeitpunkt anhand aktueller Herstellerunterlagen geprüft werden.

Der pragmatische Start ist kein vollständiges Leistungsverzeichnis. Wählen Sie drei reale Szenarien: versehentliche Einzellöschung, breit wirkende schädliche Änderung und Verlust eines geschäftskritischen Bereichs. Legen Sie für jedes benötigten Stand, RPO, RTO, Umfang und Owner fest. Führen Sie anschließend den vorhandenen Wiederherstellungsweg tatsächlich durch. Erst die sichtbare Lücke zwischen Anforderung und Testergebnis begründet die nächste technische oder vertragliche Entscheidung.