Saaspective

Software Briefing

SaaS-Backups: Wann Papierkorb und Versionierung nicht reichen

Papierkorb und Versionierung lösen kleine, früh bemerkte Fehler. Dieser Guide zeigt anhand von Microsoft- und Google-Grenzen, RPO/RTO und einem Wiederherstellungstest, wann zusätzliche SaaS-Backups sinnvoll werden.

Cloud & HostingVon Saaspective Redaktion

Aktualisierung: Stand 14. September 2026: Microsoft-RPO-Fenster präzisiert, Drive und Vault klar getrennt, CISA/NIST-Perspektive ergänzt und Wiederholungen gestrafft.

Illustration zum Artikel: Brauchen Unternehmen trotz Microsoft 365, Google Workspace und SaaS-Clouds noch Backups? Was Verfügbarkeit, Papierkorb und echtes Restore wirklich unterscheidenDieses Bild wurde mit KI erstellt.

Kurz gesagt

Papierkorb und Versionierung lösen kleine, früh bemerkte Fehler. Dieser Guide zeigt anhand von Microsoft- und Google-Grenzen, RPO/RTO und einem Wiederherstellungstest, wann zusätzliche SaaS-Backups sinnvoll werden.

Ein Drittanbieter-Backup ist deshalb kein pauschales Muss. Native Funktionen können genügen, wenn Datenumfang, Wiederherstellungspunkte, Rollen und Restore-Dauer zum Geschäftsrisiko passen und mit Testdaten geprüft wurden. Zusätzliche Sicherung wird relevant, wenn Schäden spät auffallen, viele Objekte oder Konten betroffen sind, der normale Admin-Zugang ausfällt oder produktive und gesicherte Daten nicht im selben Fehlerbereich liegen dürfen.

Dieser Guide stützt sich auf aktuelle Herstellerdokumentation sowie die Backup-Empfehlungen von CISA und NIST. Es wurden keine Produkte praktisch getestet.

Fünf Begriffe, die nicht dasselbe bedeuten

  • Papierkorb: stellt kürzlich gelöschte Objekte innerhalb eines begrenzten Fensters wieder her.
  • Versionierung: hält frühere Zustände einzelner Objekte; alte Versionen können auslaufen oder entfernt werden.
  • Retention/Hold: bewahrt Daten nach Regeln für Aufbewahrung, Prüfung oder Rechtspflichten.
  • Export: kopiert Daten heraus; Struktur, Rechte und ein vollständiger Re-Import hängen von Dienst und Lizenz ab.
  • Backup: hält definierte Wiederherstellungspunkte und einen dokumentierten Restore-Weg vor.

Synchronisation ist kein sechster Schutzmechanismus: Sie verteilt Änderungen und kann deshalb auch Löschung oder Verschlüsselung weitertragen.

Entscheidung nach Schadensfall
SchadensfallNative Funktion oft ausreichend?Entscheidender TestWann zusätzlicher Schutz sinnvoll wird
Eine Datei wurde heute gelöschtMeist jaObjekt, Version und Rechte vollständig zurückholenWenn das Zeitfenster oder die Granularität nicht reicht
Viele Dateien wurden unbemerkt verändertVielleichtPunkt-in-Zeit-Restore mit realistischer Datenmenge messenWenn manuelle Einzelrestores das RTO verfehlen
Ein Benutzerkonto wurde gelöschtUnsicherDaten, Eigentum, Freigaben und Identität zusammen prüfenWenn Offboarding-Frist oder Kontorestore Lücken hat
Ransomware oder Admin-KompromittierungOft nicht alleinRestore trotz gesperrtem normalem Admin-Zugang testenWenn dieselbe Rolle Produktion und Sicherungen kontrolliert
Datenverlust fällt Monate später aufSeltenBenötigten Stand mit tatsächlicher Aufbewahrung abgleichenWenn Papierkorb oder enge Versionen abgelaufen sind
Anbieterwechsel oder Kontozugriff fällt ausNur mit geprüftem ExportExportformat, Anhänge, Rechte und Re-Import testenWenn keine unabhängige, nutzbare Kopie existiert

Microsoft 365: Zeitfenster sauber trennen

Microsoft beschreibt für SharePoint einen 93-tägigen Papierkorb über beide Stufen. Davon getrennt kann „Files Restore“ bei SharePoint und OneDrive Änderungen innerhalb der letzten 30 Tage auf einen früheren Zeitpunkt zurücksetzen. Diese beiden Grenzen dürfen nicht zu einem gemeinsamen Restore-Versprechen vermischt werden. Auch Versionierung ist kein unbegrenztes Archiv: Microsoft weist darauf hin, dass abgelaufene oder durch Limits entfernte Versionen dauerhaft nicht mehr verfügbar sein können.

Bei Microsoft 365 Backup hängt die Dichte der Wiederherstellungspunkte vom Datentyp und Zeitraum ab. Die aktuelle Restore-Dokumentation nennt für vollständige OneDrive-Konten und SharePoint-Sites ungefähr zehnminütige Punkte für die ersten 14 Tage und danach wöchentliche Punkte bis zu 365 Tagen. Bei granularen Datei-Restores sind die jüngeren Punkte ungefähr täglich und die älteren wöchentlich; für Exchange werden ungefähr zehnminütige Punkte beschrieben. Je nach Workload kann in den ursprünglichen oder einen neuen Zielort wiederhergestellt werden. 365 Tage Aufbewahrung bedeuten daher nicht, dass für das ganze Jahr jeder beliebige Zeitpunkt auswählbar ist.

Google Workspace: Drive und Vault nicht vermischen

Für Google Drive dokumentiert Google nach dem Leeren des Papierkorbs ein Admin-Zeitfenster von 25 Tagen. Der Admin wählt einen Datumsbereich; dieser Weg stellt die darin gelöschten Drive-Daten wieder her und ist keine freie Auswahl einzelner Dateien. Rechte und Freigaben müssen nach dem Restore geprüft werden.

Google Vault verfolgt einen anderen Zweck. Retention regelt Aufbewahrung und Löschung, Holds schützen einen definierten Umfang, Suche und Export unterstützen Prüf- und eDiscovery-Prozesse. Google erklärt ausdrücklich, dass Vault keine getrennte Archivkopie bildet. Erhaltene Daten können je nach Dienst gesucht und exportiert werden, aber ein Export ist nicht automatisch ein operativer Restore in den ursprünglichen Workspace. Deshalb sind Drive-Wiederherstellung und Vault-Aufbewahrung zwei getrennte Kontrollen.

Die Kontrollfrage: Kann das Team genau den erwarteten Schaden innerhalb des festgelegten RTO und RPO beheben – auch dann, wenn der normale Admin-Zugang nicht verfügbar ist?

RPO beschreibt, wie viel neue Arbeit im schlimmsten Fall fehlen darf. RTO beschreibt, wie lange der betroffene Prozess stillstehen darf. Aus „Wir haben Versionierung“ wird erst dann eine belastbare Aussage, wenn beide Ziele mit einem realistischen Restore-Test erreicht wurden.

Wann native Funktionen genügen können

Native Wiederherstellung kann ausreichen, wenn alle wichtigen Datenarten dokumentiert abgedeckt sind, Fehler sicher innerhalb des Zeitfensters auffallen, einzelne und größere Restores geprobt wurden, ein Notfallzugang existiert und die gemessene Restore-Dauer zum Geschäft passt. Ein getesteter Export kann bei einfachen, selten veränderten Daten eine zusätzliche Route sein; seine Eignung hängt aber von Dienst, Lizenz, Anhängen, Metadaten, Rechten und einem dokumentierten Re-Import ab.

Wann zusätzliche Sicherung sinnvoll wird

Zusätzlicher Schutz ist besonders plausibel, wenn der Schaden erst spät bemerkt werden kann, zusammenhängende Objekte oder ganze Konten zurückmüssen, ein kompromittierter Admin Teil des Risikos ist, längere Wiederherstellungspunkte gefordert sind oder mehrere SaaS-Dienste in einem gemeinsamen Notfallplan liegen. Das muss nicht zwingend ein Drittanbieter sein: Entscheidend sind Trennung, Abdeckung und ein nachweislich funktionierender Restore.

CISA empfiehlt für kritische Daten offline beziehungsweise anderweitig getrennte, verschlüsselte Sicherungen und regelmäßige Prüfungen von Verfügbarkeit und Integrität. NIST betont Planung, Pflege und Tests von Backups als Teil der Vorbereitung auf Datenverlust und Ransomware. Diese Empfehlungen begründen einen risikobasierten Test; sie sind kein pauschales Kaufgebot für ein bestimmtes Produkt.

Ein kleiner Wiederherstellungstest

  1. Lege RPO und RTO für einen konkreten Geschäftsprozess fest.
  2. Erzeuge nur mit unkritischen Testdaten eine Datei mit mehreren Versionen, einen Ordner, eine E-Mail mit Anhang und ein Testkonto.
  3. Simuliere drei Fälle: ein gelöschtes Objekt, mehrere überschriebene Dateien und ein gelöschtes Testkonto.
  4. Prüfe Inhalt, gewünschte Version, Ordnerstruktur, Besitzer, Freigaben, Metadaten, Anhänge und Suchbarkeit.
  5. Dokumentiere Dauer, benötigte Rollen, fehlende Elemente und den nächsten Wiederholungstermin.

Bei einem Anbieterausfall hilft ergänzend der Guide zu SaaS-Statusseiten. Für Kündigung oder Migration gibt es die Checkliste vor dem Tool-Wechsel. Wer ein Produkt erst auswählt, sollte Restore und Export in den Praxistest vor dem Softwarekauf aufnehmen.

Fazit

Papierkorb und Versionierung sind wertvoll, aber nur für klar begrenzte Schäden. Zusätzliche Sicherung ist dann sinnvoll, wenn die native Wiederherstellung das konkrete RPO, RTO, den benötigten Umfang oder die erforderliche administrative Trennung im Test verfehlt. Kaufe deshalb nicht vorsorglich „mehr Backup“, sondern belege Wiederherstellbarkeit für die Prozesse, die wirklich weiterlaufen müssen.

Quellen

Weitere Artikel aus Cloud & Hosting