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.
Aktualisierung: Stand 14. September 2026: Microsoft-RPO-Fenster präzisiert, Drive und Vault klar getrennt, CISA/NIST-Perspektive ergänzt und Wiederholungen gestrafft.
Dieses 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.
| Schadensfall | Native Funktion oft ausreichend? | Entscheidender Test | Wann zusätzlicher Schutz sinnvoll wird |
|---|---|---|---|
| Eine Datei wurde heute gelöscht | Meist ja | Objekt, Version und Rechte vollständig zurückholen | Wenn das Zeitfenster oder die Granularität nicht reicht |
| Viele Dateien wurden unbemerkt verändert | Vielleicht | Punkt-in-Zeit-Restore mit realistischer Datenmenge messen | Wenn manuelle Einzelrestores das RTO verfehlen |
| Ein Benutzerkonto wurde gelöscht | Unsicher | Daten, Eigentum, Freigaben und Identität zusammen prüfen | Wenn Offboarding-Frist oder Kontorestore Lücken hat |
| Ransomware oder Admin-Kompromittierung | Oft nicht allein | Restore trotz gesperrtem normalem Admin-Zugang testen | Wenn dieselbe Rolle Produktion und Sicherungen kontrolliert |
| Datenverlust fällt Monate später auf | Selten | Benötigten Stand mit tatsächlicher Aufbewahrung abgleichen | Wenn Papierkorb oder enge Versionen abgelaufen sind |
| Anbieterwechsel oder Kontozugriff fällt aus | Nur mit geprüftem Export | Exportformat, Anhänge, Rechte und Re-Import testen | Wenn 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
- Lege RPO und RTO für einen konkreten Geschäftsprozess fest.
- Erzeuge nur mit unkritischen Testdaten eine Datei mit mehreren Versionen, einen Ordner, eine E-Mail mit Anhang und ein Testkonto.
- Simuliere drei Fälle: ein gelöschtes Objekt, mehrere überschriebene Dateien und ein gelöschtes Testkonto.
- Prüfe Inhalt, gewünschte Version, Ordnerstruktur, Besitzer, Freigaben, Metadaten, Anhänge und Suchbarkeit.
- 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
- https://learn.microsoft.com/en-us/compliance/assurance/assurance-sharepoint-onedrive-data-resiliency?view=o365-worldwide
- https://learn.microsoft.com/en-us/sharepoint/faqs-for-versions
- https://learn.microsoft.com/en-us/microsoft-365/backup/backup-restore-data?view=o365-worldwide
- https://knowledge.workspace.google.com/admin/drive/recover-deleted-files-and-folders-for-drive-users
- https://support.google.com/vault/answer/2990828?hl=en
- https://support.google.com/vault/answer/2539616?hl=en
- https://www.cisa.gov/stopransomware/ransomware-guide
- https://csrc.nist.gov/pubs/other/2020/04/24/protecting-data-from-ransomware-and-other-data-los/final
Weitere Artikel aus Cloud & Hosting
SaaS-Statusseiten richtig lesen: Was ein Incident wirklich bedeutet
Ein Incident ist ein Zwischenstand, keine vollständige Diagnose. Dieser Guide zeigt, wie kleine Teams Statusmeldungen mit eigenen Signalen abgleichen, sicher reagieren und nach „Resolved“ offene Vorgänge prüfen.

DNS einfach erklärt: Wenn Website oder E-Mail haken
Dieser Guide zeigt, wie du DNS-, Hosting-, HTTPS- und E-Mail-Probleme auseinanderhältst, den richtigen Record prüfst und riskante Änderungen auf Verdacht vermeidest.

Braucht deine Website HTTPS? Ja – und zwar überall
Ja, jede öffentliche Website braucht HTTPS. Dieser Guide erklärt Nutzen und Grenzen, zeigt die sichere Umstellung und liefert eine kurze Abnahme-Checkliste.
