M365-Restore für OneDrive, SharePoint und Teams prüfen

Bei einer M365-Wiederherstellung müssen das richtige Objekt, ein geeigneter Sicherungszeitpunkt und ein freigegebenes Ziel zusammenpassen. Eine Datei kann erfolgreich zurückgeschrieben worden sein und trotzdem am falschen Ort liegen oder für die falschen Personen sichtbar sein. Dieser Ablauf führt deshalb vom begrenzten Auftrag bis zur fachlichen Abnahme für OneDrive, SharePoint und Teams.

Diese Anleitung behandelt Sophos Backup and Recovery M365 im Rubrik-hosted Bereitstellungsmodell. Ziel-, Überschreib- und Wiederherstellungsoptionen hängen vom Workload und der Tenant-Konfiguration ab. Vor der Ausführung den konkreten Wiederherstellungsdialog und die zugehörige Workload-Hilfe prüfen.

Einrichtung, Subscription, SLA-Zuweisung und den getrennten Exchange-Test beschreibt Sophos Backup & Recovery M365 einrichten und einen Restore prüfen. Der folgende Ablauf setzt eine eingerichtete Sicherung voraus und erweitert weder Microsoft-Berechtigungen noch den bestellten Produktumfang.

Den Wiederherstellungsauftrag eingrenzen

Vor dem Zugriff auf einen Snapshot werden Quelltenant, Subscription und zuständige Person festgehalten. Dazu gehören der betroffene Benutzer oder die Site, der genaue Objektpfad, das vermutete Verlust- oder Änderungsereignis mit Zeitzone und der gewünschte Zustand. Bei einem Sicherheitsvorfall muss ein geeigneter, noch nicht kompromittierter Zeitpunkt mit der Incident-Verantwortung abgestimmt sein. Die neueste Sicherung ist dann nicht automatisch die richtige.

Für einen Pilot werden ausschliesslich freigegebene Testkonten und harmlose Testdaten verwendet. backup-pilot@example.invalid, Restore-Pilot-2026-10-29.txt und Restore-Abnahme sind Beispiele für einen Testbenutzer, eine Datei und ein gewünschtes Prüfziel; sie sind keine vorhandenen Tenantobjekte. Vor einem realen Auftrag werden sie durch bestätigte eigene Testwerte ersetzt.

Für das Ziel wird schriftlich entschieden, ob Daten am ursprünglichen Ort oder getrennt davon benötigt werden. Ein anderer Zielbenutzer, eine andere Site oder Subscription darf nicht allein gewählt werden, weil der Assistent dies anbietet. Berechtigungen, Datenregion und die Verantwortung für das Ziel gehören in dieselbe Freigabe.

Dateikonflikte vor dem Schreiben klären

Im Ziel können gleichnamige Dateien, neuere Bearbeitungen oder gesperrte Dokumente vorhanden sein. Vor der Bestätigung muss deshalb klar sein, ob der konkrete Ablauf überschreibt, umbenennt, überspringt oder eine getrennte Kopie erstellt. Diese Varianten nicht aus dem Verhalten eines Exchange-Restores ableiten. Rubrik unterscheidet bei OneDrive beispielsweise Erfolgs- und Teilergebnisse und kann umbenannte Objekte wegen Namenskonflikten ausweisen. Daraus folgt keine allgemeine Konfliktregel für alle Workloads.

Ist die Auswirkung des angebotenen Modus nicht eindeutig, wird noch kein Restore ausgelöst. Zuerst werden die workloadbezogene Hilfe und gegebenenfalls der Supportfall geklärt. Ein vermeintlich schneller In-place-Restore darf keine aktuelle Bearbeitung ohne Zustimmung ersetzen.

Den richtigen Snapshot und die Workload-Hilfe öffnen

1. In Sophos Fusion (ehemals Sophos Central) My Products > Backup and Recovery M365 öffnen. Nach der Weiterleitung die Rubrik-Organisation kontrollieren.
2. Inventory > SaaS > Microsoft 365 öffnen. Die für den Auftrag bestätigte Subscription bestimmen; nicht anhand eines ähnlichen Anzeigenamens raten.
3. Schutzumfang, SLA-Zuweisung und vorhandene Sicherungen des betroffenen Objekts kontrollieren. Ein grüner Integrationsstatus beweist noch keinen Snapshot mit der benötigten Dateiversion.
4. Vor einem Schreibauftrag das Help-Symbol und im Help Center die zum Workload passende Hilfe öffnen. Für SharePoint ist der dokumentierte Hilfetitel Backup and recovery of SharePoint sites and site collections, für Teams Teams data recovery. Für OneDrive im Help Center nach OneDrive und dem vorgesehenen Wiederherstellungsweg suchen.
5. Den Zeitpunkt gegen das Ereignis und die Zeitzone vergleichen. Das ausgewählte Objekt im Snapshot gegen Quelle, Pfad und erwarteten Inhalt prüfen. Quelle, Umfang, Ziel und Konfliktverhalten vor dem letzten schreibenden Schritt noch einmal mit dem Auftrag abgleichen.

Die folgenden Prüfungen ersetzen die genaue workloadbezogene Klickfolge nicht. Eine für Exchange dokumentierte Auswahl wie Recover to a new folder ist keine Zusage, dass derselbe Dialog für OneDrive, SharePoint oder Teams existiert. Passt die Hilfe nicht zum angebotenen Ablauf, wird vor der Wiederherstellung gestoppt und der Unterschied geklärt.

OneDrive: eine bestimmte Dateiversion nachweisen

Für ein begrenztes Testszenario legt die freigegebene Testperson eine harmlose Textdatei mit eindeutigem Namen an. Der Inhalt erhält zunächst den Prüfwert Alpha. Nach einem bestätigten Snapshot wird die Datei auf Bravo geändert und erneut gesichert. Beide Zeitpunkte und die jeweils erwartete Version werden notiert. Dieses Szenario ist ein Prüfplan, kein bereits beobachtetes Produktergebnis.

Für die Wiederherstellung wird bewusst der Snapshot mit Alpha gewählt. Vor dem Start werden der bestätigte Zielbenutzer, der vollständige Pfad und der Umgang mit der inzwischen vorhandenen Bravo-Datei geprüft. Wenn eine getrennte Kopie im gewählten Ablauf unterstützt und freigegeben ist, erleichtert sie den Vergleich. Ein solcher Modus wird nicht vorausgesetzt; bei ungeklärtem Überschreiben wird nicht fortgefahren.

Nach dem Auftrag werden zuerst Jobmeldung und Objektzahlen geprüft, einschliesslich Warnungen, Teilfehlern und Umbenennungen. Danach öffnet die Testperson die tatsächlich erzeugte Datei am dokumentierten Ziel. Sie muss den erwarteten Prüfwert enthalten. Wurde ein zusätzlicher Zielordner oder ein anderer Dateiname verwendet, wird genau dieser Pfad protokolliert. Eine unveränderte Datei am alten Ort ist kein Ersatznachweis.

Zusätzlich werden Zugriff und Freigaben kontrolliert: Die vorgesehene Testperson muss die Datei öffnen können; ein nicht berechtigtes Testkonto darf dadurch keinen neuen Zugang erhalten. Eine in einem Pilot geprüfte Textdatei bestätigt noch keinen vollständigen Benutzer-Restore und keine Erhaltung sämtlicher Freigabelinks oder Dateieigenschaften.

SharePoint: Inhalt, Ziel und Eigenschaften getrennt abnehmen

Bei SharePoint beginnt der Auftrag mit der genauen Site-URL. Anschliessend wird festgelegt, ob eine einzelne Datei, ein Ordner, eine Bibliothek, eine Liste oder eine umfangreichere Struktur benötigt wird. Eine gleichnamige Bibliothek in einer anderen Site ist ein anderes Ziel.

Für den Pilot eignet sich eine freigegebene Testbibliothek mit einer kleinen Datei und einem vorab notierten Prüfwert. Sofern für den späteren Einsatz relevant, werden zusätzlich ein Metadatenfeld und die erwartete Berechtigungsgruppe dokumentiert. Der Snapshot muss genau diese Ausgangsdaten enthalten. Eine Versionshistorie, Listenstruktur oder individuelle Berechtigung wird nur dann als wiederhergestellt bestätigt, wenn sie zum ausgewählten Umfang gehört und gesondert geprüft wurde.

Vor dem letzten Schreibschritt werden Ziel-Site, Objektumfang und mögliche Kollisionen mit aktuellen Inhalten kontrolliert. Wird nur eine Datei benötigt, wird nicht vorsorglich eine ganze Site wiederhergestellt. Nach dem Job prüft die zuständige Person den Inhalt im richtigen Ziel, die vorgesehenen Eigenschaften und den Zugriff. Dass das Rubrik-Portal einen abgeschlossenen Job zeigt, beweist noch nicht, dass eine Fachanwendung mit der wiederhergestellten Struktur arbeiten kann.

Weicht die Site-Struktur zwischen Snapshot und Gegenwart ab, werden Quellpfad und Zielzuordnung ausdrücklich geprüft. Bei einem fehlenden Ziel oder ungeklärten Berechtigungen werden keine zusätzlichen Konten, Sites oder Rollen auf Verdacht angelegt. Zuerst muss der Auftrag den unterstützten Zielweg und die dafür benötigten Verantwortlichkeiten festlegen.

Teams: Dateien und Zusammenarbeit nicht gleichsetzen

Ein Auftrag «Teams wiederherstellen» ist zu ungenau. Er muss nennen, ob Nachrichten, ein Kanal, Dateien oder weitere Inhalte benötigt werden. Microsoft dokumentiert, dass Dateien der Standardkanäle in der SharePoint-Site des Teams liegen; private und geteilte Kanäle besitzen eigene Sites. Der Kanalname allein reicht deshalb nicht aus, um den passenden Dateisnapshot festzulegen.

Für einen begrenzten Pilot werden ein freigegebenes Testteam, der Kanaltyp und ein harmloser Testinhalt vereinbart. Geht es um eine Kanaldatei, werden die tatsächliche SharePoint-Site, Bibliothek und Datei erfasst und nach dem SharePoint-Abnahmeplan geprüft. Eine zurückgeholte Datei bestätigt weder die Wiederherstellung von Kanalnachrichten noch von Mitgliedschaften, Registerkarten oder der gesamten Teams-Konfiguration.

Werden Nachrichten oder Kanalstrukturen benötigt, wird vor dem Restore in Teams data recovery geklärt, welche Objekttypen und Ziele der konkrete Bereitstellungsstand unterstützt. Quellteam, Kanal, Snapshot und Ziel werden getrennt dokumentiert. Nach dem Auftrag prüft ein berechtigtes Testmitglied den benötigten Inhalt in Teams; eine zusätzliche Prüfung des tatsächlichen Speicherorts bleibt bei Dateien erforderlich. Ohne bestätigten Umfang und passenden Snapshot wird keine pauschale Teams-Komplettwiederherstellung zugesagt.

Ergebnis protokollieren und den Test beenden

Der Abnahmebericht hält Quellobjekt, Snapshot-Zeit mit Zeitzone, Ziel, gewählten Modus und nachvollziehbare Jobzuordnung fest. Dazu kommen Objektzahlen, Warnungen, Umbenennungen, stichprobenartig geprüfter Inhalt, Zugriff und gemessene Dauer. Erwartetes Ergebnis und tatsächlich beobachtetes Ergebnis bleiben getrennt.

Zeigt ein Auftrag einen Fehler oder einen unklaren Abschluss, wird nicht sofort derselbe Restore erneut ausgelöst. Zuerst im Portal und am Ziel klären, ob bereits Daten geschrieben wurden. Bereits ein Teilerfolg kann Objekte erzeugt oder geändert haben. Bei der Eskalation genaue Quelle, Zeitpunkt, Ziel und bereinigte Meldung angeben; keine Dateiinhalte, Zugangsdaten oder vollständigen Exportdateien in öffentliche Tickets kopieren.

Ein Restore hat keinen allgemeinen Rückgängig-Schalter. Zusätzliche Testkopien werden erst nach der Abnahme und ausschliesslich im vereinbarten Testumfang bereinigt. Produktive Dateien, wiederhergestellte Fachinhalte oder Backups sind kein pauschaler «Rollback». Solange ein benötigter Inhalt oder eine Berechtigung nicht bestätigt ist, bleibt der Auftrag offen, auch wenn die technische Jobanzeige erfolgreich wirkt.