Microsoft 365: Warum der Papierkorb kein Backup ist

Der Papierkorb ist kein Microsoft-365-Backup

Ein Bauprojekt läuft, mehrere Personen bearbeiten Kalkulationen, Pläne und E-Mails in Microsoft 365. Dann löscht jemand versehentlich einen Projektordner. Der erste Gedanke: „Das liegt doch im Papierkorb.“ Häufig stimmt das sogar. Schwieriger wird es aber, wenn Änderungen erst spät auffallen, ein automatisierter Ablauf viele Dateien überschreibt oder niemand weiß, welches Postfach und welche Projektablage überhaupt geschützt sind. Dann ist der M365 Papierkorb eben kein verlässlicher Wiederanlaufplan.

Microsoft 365 bringt tatsächlich mehrere nützliche Sicherheitsnetze für die Arbeit an Daten mit.
Der Fehler liegt aber darin, diese unter dem Wort „Backup“ zusammenzufassen.
Ein belastbares Backup ist ein bewusst eingerichteter Schutz mit definiertem Umfang, Verantwortlichen und einem getesteten Weg zurück zu brauchbaren Daten. Gerade im Mittelstand zählt am Ende nicht, ob irgendwo eine unbekannte Kopie existiert, sondern ob das Büro seine Angebotsordner, Bauakten und Korrespondenz rechtzeitig wieder nutzen kann, bevor es zu merklichen Auftragsverzögerungen oder gar -Ausfällen kommt.

Was der M365 Papierkorb tatsächlich leistet

Wenn eine Datei in SharePoint oder OneDrive gelöscht wird, landet sie normalerweise zunächst im Papierkorb der Website, auf den berechtigte Administratoren zugreifen. Microsoft nennt für diesen Ablauf grundsätzlich 93 Tage für Geschäftskonten (30 bei Privatkonten) ab der ursprünglichen Löschung. Inhalte können unter bestimmten Umständen auch vorher schon endgültig gelöscht werden.

Das ist hervorragend für den alltäglichen Fehlgriff: Eine Zeichnung wurde gelöscht, das Team bemerkt es zeitnah und jemand mit den nötigen Rechten stellt sie wieder her. Der Papierkorb beantwortet aber nur eine begrenzte Frage: Kann ich dieses gelöschte Objekt im vorgesehenen Fenster finden und zurückholen? Er liefert keinen frei wählbaren, vollständigen Zustand sämtlicher Projektinformationen. Er sagt auch nichts darüber aus, ob ein wichtiges Postfach, eine andere Website oder die Daten eines ausgeschiedenen Mitarbeiters in einem gesonderten Sicherungsplan enthalten sind.

Zudem ist eine wiederhergestellte Datei nicht automatisch ein wieder arbeitsfähiger Prozess. Fehlen zwischenzeitliche Änderungen, Berechtigungen oder die passende E-Mail zur Freigabe, muss das Team den Sachverhalt erst rekonstruieren. Genau diese Abhängigkeiten machen aus Datensicherung eine betriebliche Aufgabe.

Versionsverlauf und Aufbewahrung haben andere Aufgaben

Eine Datei wurde nicht gelöscht, sondern durch eine falsche Fassung ersetzt? Dann kann der Versionsverlauf helfen. Für bestimmte großflächige Änderungen bieten OneDrive und SharePoint zudem Funktionen zur Wiederherstellung eines früheren Zustands. Diese Werkzeuge sind wertvoll, solange der passende Stand verfügbar ist und die betroffenen Inhalte und Voraussetzungen passen. Ein Versionsverlauf ist aber kein Beleg dafür, dass alle geschäftskritischen Daten regelmäßig gesichert, überwacht und im Ernstfall gemeinsam wiederherstellbar sind.

Ähnlich leicht wird Purview-Aufbewahrung missverstanden. Aufbewahrungsregeln können Inhalte trotz Änderung oder Löschung nach den konfigurierten Vorgaben erhalten. Ihr Zweck ist die Steuerung des Informationslebenszyklus und gegebenenfalls die Erfüllung von Aufbewahrungspflichten. Wer damit einen operativen Restore plant, muss im konkreten Mandanten erst klären, für welche Inhalte die Regeln gelten, wie eine Wiederherstellung abläuft und wie lange sie dauert. „Wir haben eine Aufbewahrungsrichtlinie“ ist keine Antwort auf „Bis wann können wir morgen früh wieder Angebote schreiben?“

Ein Beispiel: Der falsch laufende Projekt-Flow

Stellen Sie sich einen typischen Ablauf vor: Ein Flow sortiert Dokumente aus eingehenden E-Mails in eine SharePoint-Bauakte. Eine Regeländerung sorgt dafür, dass Dateien falsch zugeordnet oder bestehende Fassungen überschrieben werden. Der Fehler wird erst bemerkt, als ein Bauleiter eine ältere, freigegebene Zeichnung braucht.

Jetzt helfen konkrete Fragen mehr als der Satz „Wir nutzen OneDrive“: Welche Bibliothek ist betroffen? Seit wann läuft die Regel falsch? Gibt es einen brauchbaren Zustand vor der Änderung? Wer kann ihn finden, ohne bereits korrigierte Dateien erneut zu überschreiben? Muss auch die zugehörige E-Mail wiederhergestellt werden? Ein guter Restore stellt nicht einfach möglichst viel zurück. Er bringt die richtigen Daten in den richtigen Arbeitskontext, ohne neue Schäden zu verursachen.

Dasselbe Prinzip gilt bei einer Massenlöschung, etwa nach dem Ende eines Projektzugangs. Vielleicht liegen Dateien noch im Papierkorb. Vielleicht ist die Löschung nur ein Teil des Problems. Die entscheidende Reaktion ist dann geordnet: Änderungen stoppen, Umfang feststellen, verfügbare Stände sichern, Wiederherstellungsweg auswählen und das Ergebnis fachlich prüfen.

Was in Betrieben oft schiefgeht

„Alles liegt in Teams.“ Teams ist für viele Betriebe die sichtbare Oberfläche. Die Dateien können in SharePoint und OneDrive liegen; Mails in Exchange. Eine pauschale Aussage über „Teams-Backup“ verschleiert, welche Objekte und Inhalte im gewählten Paket wirklich geschützt sind. Lassen Sie die Schutzliste konkret aufschreiben.

„Nur der Jobstatus wird kontrolliert.“ Eine grüne Sicherungsmeldung beantwortet nicht, ob die richtige Projektakte in einer verwendbaren Fassung zurückkommt. Zu einem belastbaren Test gehört die fachliche Prüfung, ob eine repräsentative Wiederherstellung tatsächlich nutzbar ist.

„Neue Ablagen werden vergessen.“ Projektteams und Websites entstehen im Alltag schnell. Wenn die Aufnahme in den Schutzprozess manuell geschieht, braucht sie einen Eigentümer und eine regelmäßige Kontrolle. Sonst ist ausgerechnet das neue, aktive Projekt nicht in der Sicherung enthalten.

„Der einzige Administrator ist nicht erreichbar.“ Wiederherstellung braucht geeignete Rechte, Anmeldemöglichkeiten und klare Entscheidungen. Dokumentieren Sie, wer im Ausfall den Restore beauftragt, wer ihn ausführt und wer das Ergebnis abnimmt. Diese Informationen gehören auch in eine praktisch nutzbare IT-Notfallvorsorge.

„Aufbewahrung und Wiederanlauf werden vermischt.“ Eine Datei für vorgeschriebene Zeit zu erhalten und den Betrieb morgen wieder arbeitsfähig zu machen, sind unterschiedliche Ziele. Beides verdient eigene Regeln und einen konkreten Test.

Woran Sie einen verlässlichen Restore-Test erkennen

Ein aussagekräftiger Test orientiert sich an einer typischen Aufgabe Ihres Betriebs: etwa einer Bauakte mit Plänen, mehreren Fassungen und zugehöriger Korrespondenz. Das Ziel ist nicht bloß, eine Datei irgendwo wiederzufinden. Der benötigte Stand muss vollständig, fachlich richtig und für die zuständigen Personen nutzbar sein – ohne aktuelle Projektarbeit zu beschädigen.

Eine professionelle Wiederherstellungsprobe muss deshalb mehr belegen als einen grünen Sicherungsstatus: Sind die richtigen Objekte überhaupt geschützt? Kann ein berechtigtes Team den geeigneten Wiederherstellungspunkt bestimmen? Sind Dateien lesbar, Fassungen und Zusammenhänge korrekt und die nötigen Rechte geklärt? Wie lange dauert es bis zur arbeitsfähigen Akte? Fachlich Verantwortliche sollten das Ergebnis abnehmen; die IT hält Abweichungen und Verbesserungen fest.

Dabei zählen auch Zuständigkeiten und Prioritäten. Wer löst im Ernstfall die Wiederherstellung aus, wer führt sie aus und wer entscheidet, ob der Betrieb weiterarbeiten kann? Angebotsordner, laufende Bauakten und zentrale Postfächer werden selten gleich dringend benötigt. Diese Reihenfolge und die erwartete Wiederanlaufzeit müssen zum tatsächlichen Geschäft passen. Ein Test macht sichtbar, wo Schutzumfang, Ablauf oder Verantwortung noch eine Lücke haben.