Microsoft 365 Backup und SaaS-Sicherung
Warum Microsoft 365, Entra ID, Jira, Confluence, Okta & Co. eine eigene Recovery-Strategie brauchen
Microsoft 365 läuft, Google Workspace und Salesforce sind erreichbar, und trotzdem können geschäftskritische Daten verloren sein: durch eine versehentliche Massenlöschung, ein kompromittiertes Administratorkonto oder Ransomware, die über synchronisierte Ordner in die Cloud gelangt. E-Mails, Dokumente, Projektinformationen, Wissensbestände, Identitäten, Berechtigungen und Verträge liegen heute in Plattformen wie Microsoft 365, Microsoft Entra ID, Jira, Confluence, Okta oder DocuSign. Für die Verfügbarkeit des Dienstes sorgt der Anbieter, für die Wiederherstellbarkeit der Daten das Unternehmen selbst. Mit Microsoft 365 Backup baut Microsoft seine native Datensicherung gerade aus. Dieser Beitrag zeigt, was ein SaaS-Backup leisten muss, wo die Bordmittel enden und welche Fragen Geschäftsführung, CIO und CISO beantworten sollten.
Im Überblick: SaaS verlagert den Betrieb einer Anwendung in die Cloud, nicht automatisch die Verantwortung für die eigenen Daten, Identitäten und Konfigurationen. Eine belastbare Cyber-Resilienz-Strategie muss deshalb festlegen, welche SaaS-Daten geschützt werden, welche Wiederherstellungspunkte benötigt werden und wie die Wiederherstellung nach Löschung, Fehlkonfiguration oder Cybervorfall erfolgt.
Die Cloud ist verfügbar. Sind Ihre Daten auch wiederherstellbar?
Für Geschäftsführung, CIO und CISO entsteht daraus eine andere Fragestellung als bei klassischer Infrastruktur: Nicht nur die Verfügbarkeit des SaaS-Dienstes zählt. Entscheidend ist, ob geschäftskritische Daten und Konfigurationen nach einem Datenverlust oder Sicherheitsvorfall in einen definierten, vertrauenswürdigen Zustand zurückgeführt werden können.
Was ist SaaS-Backup?
SaaS-Backup, etwa ein Microsoft 365 Backup, ist die Sicherung von Daten und, abhängig von Anwendung und Lösung, von unterstützten Konfigurations- und Identitätsobjekten aus cloudbasierten Softwarediensten, damit diese nach Löschung, Fehlkonfiguration oder anderen Datenverlustereignissen wiederhergestellt werden können. Als Cloud Backup liegt die Sicherung idealerweise in einer von der Quellplattform getrennten Umgebung.
Wichtig ist die Abgrenzung zu Hochverfügbarkeit und Disaster Recovery. Microsoft weist für Microsoft 365 ausdrücklich darauf hin, dass eine Disaster-Recovery-Kopie den aktuellen Zustand von Inhalten erhält, während ein Backup die Wiederherstellung früherer Zustände ermöglicht.
Microsoft 365 Backup: Was sich gerade ändert
Microsoft rollt für Microsoft 365 Backup derzeit die Funktion Full Workload Backup aus. Administratoren können damit einen kompletten Workload wie SharePoint, OneDrive oder Exchange mit einer einzigen Richtlinie schützen, neue Daten werden automatisch einbezogen. Die allgemeine Verfügbarkeit begann Mitte September, der Abschluss ist für Mitte Oktober 2026 geplant.
Wie sich die Risikolage zugleich verändert, zeigt ein Fall von Ende September. Zenity Labs hat unter dem Namen SalesBleed Schwachstellen in Salesforce Agentforce offengelegt, über die sich CRM-Daten ohne Zutun des Opfers abziehen ließen. Salesforce hat die Lücken im August geschlossen. Relevant bleibt der Fall als Beispiel für ein strukturelles Risiko: KI-Agenten und Integrationen greifen mit weitreichenden Rechten auf SaaS-Daten zu, und das betrifft nicht nur ein einzelnes Produkt.
Geteilte Verantwortung: Plattform ist nicht gleich Daten
SaaS-Anbieter arbeiten nach dem Shared Responsibility Model. Der Anbieter verantwortet Infrastruktur, Verfügbarkeit und die Redundanz seiner Rechenzentren. Der Kunde verantwortet Daten, Identitäten, Berechtigungen und Konfigurationen.
In der Praxis heißt das: Fällt bei Microsoft ein Rechenzentrum aus, greifen georedundante Kopien. Löscht dagegen ein Administrator eine SharePoint-Site oder überschreibt ein Skript Tausende Salesforce-Datensätze, ist das aus Sicht der Plattform eine gewollte Änderung. Sie wird zuverlässig in alle Kopien repliziert. Redundanz schützt vor dem Ausfall der Plattform, ein Backup vor Fehlern und Angriffen innerhalb der Plattform. Microsoft hält diese Aufteilung in seiner Dokumentation zur geteilten Verantwortung ausdrücklich fest: Daten, Konten und Identitäten bleiben bei jeder Cloud-Form in der Verantwortung des Kunden.
Das bedeutet nicht, dass SaaS-Anbieter keine Schutz- oder Wiederherstellungsfunktionen bereitstellen. Microsoft bietet beispielsweise Microsoft 365 Backup für Exchange, SharePoint und OneDrive an. Entscheidend ist deshalb eine sachliche Prüfung: Decken die nativen Funktionen der jeweiligen Plattform die eigenen Anforderungen an Aufbewahrung, Wiederherstellung, Unabhängigkeit und Recovery ab?
Shared Responsibility bei SaaS: Wer ist wofür zuständig?
| Bereich | Verantwortlich |
|---|---|
| Rechenzentren, Hardware, Netzwerk | SaaS-Anbieter |
| Verfügbarkeit der Anwendung | SaaS-Anbieter |
| Georedundanz bei Plattformausfall | SaaS-Anbieter |
| Daten und Inhalte | Kunde |
| Identitäten und Berechtigungen | Kunde |
| Konfigurationen und Richtlinien | Kunde |
| Wiederherstellung nach Löschung, Fehler oder Angriff | Kunde |
Warum SaaS-Backup ein Cyber-Resilienz-Thema ist
Cybersecurity zielt darauf, Angriffe zu verhindern oder frühzeitig zu erkennen. Cyber-Resilienz ergänzt diese Perspektive um die Fähigkeit, nach einem Vorfall weiterzuarbeiten und kritische Daten sowie Systeme wiederherzustellen. Backup ist dafür eine Recovery-Kontrolle, aber nur dann, wenn die benötigten Daten tatsächlich gesichert und wiederherstellbar sind.
- Schutz vor versehentlicher oder böswilliger Löschung: Ein unabhängiger Datenbestand kann eine zusätzliche Wiederherstellungsoption schaffen.
- Recovery nach Fehlkonfigurationen: Besonders bei Identitätsplattformen können Konfigurationen und Richtlinien geschäftskritisch sein.
- Historische Wiederherstellungspunkte: Sie ermöglichen die Rückkehr zu einem früheren Zustand, sofern die eingesetzte Lösung und der Workload dies unterstützen.
- Trennung von Produktion und Backup: Eine herstellerunabhängige Backup-Plattform kann Daten außerhalb der jeweiligen SaaS-Produktivumgebung speichern.
Welche SaaS-Anwendungen gehören in die Backup-Strategie?
Die Auswahl sollte sich an der Kritikalität der Geschäftsprozesse und den tatsächlich verfügbaren Wiederherstellungsfunktionen orientieren. Typische Bereiche sind:
| Bereich | Beispiele | Zu prüfende Recovery-Objekte |
|---|---|---|
| Collaboration | Microsoft 365, Google Workspace | E-Mail, Dateien, Sites, Benutzerinhalte |
| CRM | Salesforce | Datensätze, Anhänge, Metadaten |
| Identity & Access | Microsoft Entra ID, Okta | Benutzer, Gruppen, Rollen, Policies und weitere unterstützte Konfigurationen |
| Projekt & Wissen | Jira, Confluence | Projekte, Issues, Anhänge, Seiten, Spaces und weitere unterstützte Objekte |
| Verträge | DocuSign | Dokumente und weitere von der Backup-Lösung unterstützte Daten |
| Weitere SaaS-Dienste | z. B. weitere CRM- und DevOps-Plattformen | Workload-spezifisch prüfen |
Microsoft 365 (ehemals Office 365) sichern: Wo native Funktionen enden
Papierkörbe und Aufbewahrungsrichtlinien
Gelöschte Elemente in Exchange Online bleiben standardmäßig 14 Tage wiederherstellbar, SharePoint und OneDrive halten Gelöschtes bis zu 93 Tage vor. Aufbewahrungsrichtlinien und Litigation Hold verhindern zusätzlich, dass Daten endgültig verschwinden.
Diese Mechanismen sind für Compliance und eDiscovery gebaut. Sie erlauben es, Daten zu finden und zu exportieren. Ein Postfach, eine Teams-Umgebung oder eine SharePoint-Site lassen sich damit aber nicht samt Struktur und Berechtigungen auf einen bestimmten Zeitpunkt zurücksetzen.
Das native Microsoft 365 Backup
Microsoft 365 Backup schließt diese Lücke teilweise, weil es zeitpunktgenaue Wiederherstellungen auch für große Datenmengen ermöglicht. Der Dienst sichert allerdings nur Exchange Online, OneDrive und SharePoint Online. Eine vollständige Wiederherstellung von Teams-Umgebungen, Entra-ID-Objekten oder Conditional-Access-Richtlinien deckt er nicht ab.
Schwerer wiegt die fehlende Unabhängigkeit. Laut Microsoft sind die Sicherungen unveränderbar, solange ein Backup-Administrator sie nicht ausdrücklich im Rahmen des Offboardings löscht. Sie verlassen jedoch nie die Vertrauensgrenze von Microsoft 365 und werden über dieselbe Verwaltungsebene gesteuert. Ein kompromittiertes Konto mit Backup-Administratorrechten, eine Sperrung des Tenants oder eine Störung beim Anbieter können deshalb Produktivdaten und Sicherung zugleich betreffen.
Unternehmen sollten deshalb nicht pauschal behaupten, Microsoft biete kein Backup: Sicherungsrichtlinien lassen sich für OneDrive, SharePoint und Exchange einrichten. Die Managementfrage lautet vielmehr: Welche Workloads, Recovery-Zeiträume und Wiederherstellungsanforderungen gelten im eigenen Unternehmen, und reicht die gewählte native oder unabhängige Lösung dafür aus?
Weitere Plattformen: Google Workspace, Salesforce, Entra ID, Jira, Okta und DocuSign
Google Workspace und Salesforce
Google Workspace folgt demselben Prinzip mit anderen Fristen. Gelöschte Gmail-Nachrichten und Drive-Dateien bleiben 30 Tage im Papierkorb, danach können Administratoren sie über die Admin-Konsole noch 25 Tage lang wiederherstellen. Anschließend sind sie auch für Google nicht mehr verfügbar. Die Werkzeuge stellen gelöschte Daten wieder her, gegen überschriebene oder verschlüsselte Inhalte helfen sie nur eingeschränkt. Mehr dazu im Beitrag zur Sicherung von Google Workspace.
Bei Salesforce oder Atlassian ist die Lage ähnlich: Es gibt Papierkörbe, Exportfunktionen und teils kostenpflichtige Backup-Optionen, aber keine automatisch unabhängige Kopie. Bei Salesforce kommt hinzu, dass neben den Datensätzen auch Metadaten gesichert werden müssen, also Objekte, Felder, Workflows und Berechtigungen. Ohne die passende Struktur sind wiederhergestellte Datensätze kaum nutzbar.
Entra ID Backup: Identitäten und Konfigurationen in die Recovery einbeziehen
Bei Microsoft Entra ID geht es nicht nur um Dateien. Spezialisierte Backup-Lösungen sichern unter anderem Benutzer, Gruppen, administrative Einheiten, Rollen, Enterprise-Apps, App-Registrierungen und Conditional-Access-Richtlinien. Der konkrete Umfang kann von Edition, Lizenzierung und API-Unterstützung abhängen. Damit wird Identity Recovery zu einem eigenständigen Bestandteil der Business-Continuity-Planung.
Jira und Confluence Backup: Projekte und Wissen wiederherstellbar halten
In Jira und Confluence liegen Projektstände, Tickets und internes Wissen. Für beide Plattformen gibt es automatisierte Backups und eine granulare Wiederherstellung unterstützter Daten wie Projekte, Issues, Seiten, Spaces, Dateien und Anhänge, unveränderbar gespeichert außerhalb der Produktivumgebung. Welche Objekte im Detail gesichert werden, sollte vor der Einführung anhand der aktuellen Coverage-Dokumentation geprüft werden.
Okta Backup: Identity-Konfigurationen als kritische Betriebsdaten behandeln
Für Okta sind automatisierte, unveränderbare Backups und die Wiederherstellung kompromittierter Konfigurationen verfügbar. Für Unternehmen, deren Zugriff auf geschäftskritische Anwendungen von Okta abhängt, gehört daher auch die Wiederherstellbarkeit des Identity-Systems in die Resilienzplanung.
DocuSign: Vertragsdaten in die Recovery-Betrachtung aufnehmen
Auch für DocuSign gibt es eine automatisierte Sicherung und Wiederherstellung. Unternehmen sollten prüfen, welche Vertrags- und Signaturdaten für ihre rechtlichen und operativen Prozesse kritisch sind und wie diese nach einem Datenverlust wiederhergestellt werden können.
Typische Verlustszenarien
Fehlbedienung und Massenänderungen gehören zu den häufigsten Ursachen. Ein fehlerhafter Import, eine falsch konfigurierte Aufbewahrungsrichtlinie oder ein fehlerhaftes Skript verändert in Minuten große Datenbestände. Oft fällt das erst auf, wenn die Papierkorbfristen abgelaufen sind.
Ransomware über Synchronisation trifft Cloud-Daten indirekt. Verschlüsselt Schadsoftware lokale Dateien auf einem Gerät mit OneDrive- oder Google-Drive-Client, landen die verschlüsselten Versionen in der Cloud.
Kompromittierte Administratorkonten sind das gravierendste Szenario. Wer globale Adminrechte hat, kann Postfächer und Sites löschen, Richtlinien entfernen und native Sicherungen beeinflussen.
Offboarding führt regelmäßig zu unbemerktem Datenverlust. Nach dem Entzug einer Microsoft-Lizenz werden Postfach und OneDrive eines ausgeschiedenen Mitarbeiters nach Ablauf bestimmter Fristen gelöscht. Bei Google Workspace lassen sich Drive-Dateien eines gelöschten Kontos nur innerhalb von 20 Tagen wiederherstellen.
Integrationen und KI-Agenten sind eine wachsende Risikoquelle. Sie arbeiten mit weitreichenden Berechtigungen und verarbeiten zunehmend Inhalte aus unvertrauenswürdigen Quellen. Ein Agent, der Daten lesen darf, darf sie häufig auch ändern. Gegen Datenabfluss hilft kein Backup, gegen manipulierte oder gelöschte Daten ist es oft die einzige Rückfallebene.
Auswirkungen auf Recovery und Compliance
Viele Unternehmen haben Recovery-Ziele für ihr Rechenzentrum definiert, nicht aber für SaaS-Dienste, obwohl Kommunikation, Vertrieb und Dokumentenmanagement daran hängen. Hinzu kommt ein technischer Faktor: SaaS-Plattformen begrenzen über ihre Schnittstellen, wie viele Daten pro Zeiteinheit geschrieben werden können. Eine Massenwiederherstellung mehrerer Terabyte dauert deshalb deutlich länger, als Datenblätter vermuten lassen.
Regulatorisch ist die Lage eindeutig. Art. 32 DSGVO verlangt, dass personenbezogene Daten nach einem Zwischenfall rasch wieder verfügbar gemacht werden können. Die NIS2-Richtlinie nennt Backup-Management und Wiederherstellung ausdrücklich als Pflichtmaßnahmen. Beides gilt unabhängig davon, wo die Daten liegen.
Experteneinschätzung: Die unterschätzte Lücke
In der Praxis scheitert SaaS-Datensicherung selten an fehlender Technik, sondern an zwei Annahmen. Die erste: Das native Backup gilt als vollständige Lösung. Es ist eine sinnvolle erste Ebene für schnelle Wiederherstellungen. Als einzige Kopie bleibt es aber an denselben Anbieter, dieselben Administratoren und dieselbe Vertrauensgrenze gebunden. Die 3-2-1-1-0-Regel verlangt ausdrücklich eine Kopie außerhalb dieser gemeinsamen Grenze.
Die zweite: Das Backup-Konzept endet bei Microsoft 365. CRM, Ticketing, Projektmanagement und Wissensdatenbanken laufen oft in weiteren SaaS-Diensten, die Fachbereiche selbst eingeführt haben und die in keinem Sicherungskonzept auftauchen. Die Lücke wird meist erst sichtbar, wenn Daten fehlen.
Welche Eigenschaften sollte eine Multi-SaaS-Backup-Strategie prüfen?
Eine Entscheidung sollte nicht allein anhand der Zahl unterstützter Anwendungen getroffen werden. Für C-Level und IT-Leitung sind vor allem folgende Prüfpunkte relevant:
- Unabhängigkeit: Werden Backup-Daten getrennt von der jeweiligen SaaS-Produktivumgebung gespeichert?
- Unveränderlichkeit: Sind gesicherte Daten gegen nachträgliche Änderung oder Löschung geschützt?
- Recovery-Granularität: Welche einzelnen Objekte lassen sich suchen und wiederherstellen?
- Workload-Abdeckung: Welche Anwendungen und welche Datenobjekte innerhalb dieser Anwendungen werden tatsächlich unterstützt?
- Identity Recovery: Können neben Nutzdaten auch relevante Identitäts- und Konfigurationsobjekte gesichert werden?
- Datenresidenz und Governance: Wo liegen die Daten, wie werden Zugriffe kontrolliert und welche Nachweise stehen zur Verfügung?
- Retention und Recovery-Zeiträume: Entsprechen Aufbewahrung und verfügbare Wiederherstellungspunkte den internen Anforderungen?
- Betrieb: Wie werden Backup-Jobs überwacht, Fehler erkannt und Restore-Prozesse getestet?
Mit jeder zusätzlichen SaaS-Anwendung steigt die Zahl der Recovery-Prozesse. Eine gemeinsame Multi-SaaS-Plattform kann mehrere unterstützte Workloads in einer Verwaltungsumgebung zusammenführen und so Administration, Sichtbarkeit und standardisierte Recovery-Prozesse vereinfachen. Der konkrete Nutzen hängt jedoch von der tatsächlichen Workload-Abdeckung und den Anforderungen des Unternehmens ab. Weil sich die Funktionen je Workload unterscheiden, sollte die aktuelle Produkt- und Coverage-Dokumentation Bestandteil jeder Auswahlentscheidung sein.
SaaS-Backup richtig aufsetzen: sechs Schritte
1. Bestand erfassen
Alle genutzten SaaS-Anwendungen inventarisieren, auch die in Fachbereichen eingeführten, und geschäftskritische Daten identifizieren.
2. Recovery-Ziele festlegen
RTO und RPO für SaaS-Workloads definieren wie für On-Premises-Systeme.
3. Unabhängige Kopie schaffen
Mindestens eine Sicherung außerhalb der Quellplattform vorhalten, mit eigener Verwaltung, eigener MFA und unveränderbarer Speicherung. Native Funktionen bleiben als erste Ebene sinnvoll.
4. Vollständig sichern
Neben Postfächern und Dateien auch Teams, Gruppen, geteilte Ablagen in Google Drive, Konfigurationen und bei Salesforce die Metadaten einbeziehen, ebenso Identitäts- und Konfigurationsobjekte aus Entra ID und Okta, Projektdaten aus Jira und Confluence sowie Vertragsdaten aus DocuSign.
5. Speicherort und Betreiber bewusst wählen
Sicherungen in europäischen Rechenzentren vereinfachen die DSGVO-Dokumentation. Für den Schutz vor ausländischen Herausgabeverlangen, etwa nach dem US CLOUD Act, zählt aber nicht allein der Serverstandort, sondern auch, ob der Betreiber einer solchen Rechtsordnung unterliegt (mehr dazu im Beitrag zur europäischen Datenhoheit).
6. Wiederherstellung testen
Einzel- und Massenwiederherstellungen regelmäßig üben (siehe Recovery Testing und Wiederherstellungstest) und die tatsächliche Dauer dokumentieren. Offboarding-Prozesse zudem an eine vorherige Sicherung koppeln.
Sieben Fragen, die Geschäftsführung, CIO und CISO beantworten sollten
- Welche SaaS-Anwendungen sind für unsere Kernprozesse geschäftskritisch?
- Welche Daten, Identitäten und Konfigurationen liegen ausschließlich oder primär in diesen Plattformen?
- Welche nativen Backup-, Retention- und Restore-Funktionen bietet jeder SaaS-Anbieter heute tatsächlich?
- Welche Recovery-Zeitpunkte und Aufbewahrungszeiträume benötigt unser Unternehmen?
- Benötigen wir eine vom SaaS-Produktivsystem getrennte Backup-Kopie?
- Können wir einzelne Objekte gezielt wiederherstellen oder nur größere Datenbestände?
- Ist der Restore-Prozess dokumentiert und regelmäßig überprüft?
Fazit: Backup ist die Voraussetzung. Wiederherstellbarkeit ist das Ziel.
Mit dem Ausbau von Microsoft 365 Backup werden die Bordmittel besser, an der Grundregel ändert das nichts: Für die Wiederherstellbarkeit von SaaS-Daten bleibt das Unternehmen selbst verantwortlich. Cloud-Dienste reduzieren den Aufwand für den Betrieb eigener Infrastruktur, beseitigen aber nicht die Notwendigkeit, Recovery-Anforderungen für geschäftskritische Daten festzulegen. Gerade bei SaaS sollte klar dokumentiert sein, welche Daten und Konfigurationen geschützt werden, wie lange Wiederherstellungspunkte verfügbar sind und wie ein Restore im Ernstfall durchgeführt wird.
Ein belastbares SaaS-Backup ist unabhängig von der Quellplattform, deckt alle kritischen Datentypen ab und wird regelmäßig getestet. Für das C-Level ist SaaS-Backup deshalb keine isolierte Backup-Frage, sondern Teil von Business Continuity und Cyber-Resilienz: Kann das Unternehmen nach einem Datenverlust, einer Fehlkonfiguration oder einem Cybervorfall seine kritischen SaaS-Daten und Zugriffsstrukturen in einen definierten Zustand zurückführen?
SaaS-Recovery als Teil der gesamten Cyber-Resilienz betrachten
Cristie Data unterstützt Unternehmen bei Backup-, Recovery- und Cyber-Resilienz-Konzepten für lokale, hybride und cloudbasierte Umgebungen. Im ersten Schritt steht dabei nicht ein Produkt, sondern die Recovery-Anforderung im Mittelpunkt: Welche SaaS-Workloads sind kritisch, welche Wiederherstellung wird benötigt und welche Schutzlücken bestehen? Mit dem Multi-SaaS Backup von Cristie Data lassen sich Microsoft 365, Google Workspace, Salesforce und weitere SaaS-Anwendungen unabhängig von der Quellplattform in europäischen Rechenzentren sichern. Lassen Sie Ihre SaaS-Workloads und Recovery-Anforderungen strukturiert bewerten.
FAQ: Microsoft 365 Backup und SaaS-Datensicherung
MUSS MAN MICROSOFT 365 ÜBERHAUPT SICHERN?
Ja. Microsoft verantwortet die Verfügbarkeit der Plattform, nicht die Wiederherstellbarkeit der Kundendaten nach Fehlbedienung, Angriffen oder Löschungen. Microsoft stellt in seiner Dokumentation zur geteilten Verantwortung selbst klar, dass Daten und Identitäten immer in der Verantwortung des Kunden liegen.
IST OFFICE 365 BACKUP DASSELBE WIE MICROSOFT 365 BACKUP?
Ja, gemeint ist die Sicherung derselben Dienste wie Exchange Online, SharePoint, OneDrive und Teams. Office 365 ist die frühere Bezeichnung, die meisten Pakete vermarktet Microsoft heute als Microsoft 365. Zu beachten: „Microsoft 365 Backup“ ist zugleich der Name des nativen Microsoft-Dienstes.
REICHT DAS NATIVE MICROSOFT 365 BACKUP AUS?
Es ist eine sinnvolle erste Ebene für Exchange Online, OneDrive und SharePoint. Weil es innerhalb derselben Anbieterumgebung und Verwaltungsebene liegt, ersetzt es keine unabhängige Kopie. Andere Datentypen und SaaS-Dienste deckt es nicht ab.
WAS IST DER UNTERSCHIED ZWISCHEN AUFBEWAHRUNGSRICHTLINIE UND BACKUP?
Eine Aufbewahrungsrichtlinie verhindert, dass Daten endgültig gelöscht werden, und dient der Compliance. Ein Backup ermöglicht die Wiederherstellung von Daten, Strukturen und Berechtigungen auf einen bestimmten Zeitpunkt.
WAS IST DER UNTERSCHIED ZWISCHEN BACKUP UND DISASTER RECOVERY?
Eine Disaster-Recovery-Kopie hält den aktuellen Zustand der Daten bereit, um etwa den Ausfall eines Rechenzentrums zu überbrücken. Ein Backup ermöglicht dagegen die Wiederherstellung früherer Zustände, zum Beispiel vor einer Löschung, Fehlkonfiguration oder Verschlüsselung. Microsoft beschreibt diese Abgrenzung für Microsoft 365 ausdrücklich.
WAS IST EIN CLOUD-TO-CLOUD-BACKUP?
Eine Sicherung, bei der Daten aus einer SaaS-Anwendung direkt in eine separate Cloud-Umgebung gesichert werden, ohne Umweg über das eigene Rechenzentrum. Entscheidend ist, dass Zielumgebung und Verwaltung von der Quellplattform getrennt sind.
WELCHE DATEN MÜSSEN BEI SALESFORCE GESICHERT WERDEN?
Neben Datensätzen und Anhängen auch Metadaten wie Objektdefinitionen, Felder, Workflows und Berechtigungen. Ohne Metadaten ist eine vollständige Wiederherstellung kaum möglich.
MUSS MAN AUCH GOOGLE WORKSPACE SICHERN?
Ja. Gelöschte Gmail- und Drive-Daten sind nach 30 Tagen im Papierkorb und weiteren 25 Tagen über die Admin-Konsole endgültig verloren, auch für Google. Eine unabhängige Sicherung schützt darüber hinaus vor Angriffen, Fehlbedienung und dem Verlust von Konten. Mehr dazu im Beitrag zur Sicherung von Google Workspace.
SCHÜTZT EIN SAAS-BACKUP VOR DATENDIEBSTAHL?
Nein. Ein Backup stellt verlorene oder manipulierte Daten wieder her, verhindert aber nicht ihren Abfluss. Dafür sind Zugriffskontrolle, Berechtigungsmanagement und Monitoring zuständig.
MUSS MAN AUCH ENTRA ID ODER OKTA SICHERN?
Ja, wenn der Zugriff auf geschäftskritische Anwendungen von ihnen abhängt. Gelöschte oder manipulierte Benutzer, Rollen und Zugriffsrichtlinien können den Betrieb ebenso lahmlegen wie verlorene Dateien. Eine unabhängige Sicherung ermöglicht es, einzelne Konfigurationen gezielt auf einen früheren Stand zurückzusetzen.
Hinweis: Bei der Erstellung dieses Beitrags kamen KI-gestützte Werkzeuge unterstützend zum Einsatz. Recherche, redaktionelle Prüfung und inhaltliche Verantwortung liegen bei der Redaktion von Cristie Data.
