Microsoft 365 Backup-Strategie: Die 3-2-1-Regel in der Cloud

Der teuerste Irrtum im Schweizer KMU-IT-Alltag

“Wir sind doch in der Cloud, das sichert Microsoft automatisch.” Dieser Satz kostet jedes Jahr Firmen echte Daten – nicht weil Microsoft schlampt, sondern weil er auf einem Missverständnis beruht. Microsoft 365 ist auf Verfügbarkeit optimiert (99.9 % SLA, redundante Rechenzentren, automatische Replikation), nicht auf Wiederherstellbarkeit einzelner Datenpunkte über Jahre. Das ist ein fundamentaler Unterschied, den du als IT-Verantwortlicher in einem KMU verstehen und gegenüber der Geschäftsleitung vertreten musst – am besten bevor der Ernstfall eintritt, nicht danach.

Dieser Artikel zeigt dir, wo native M365-Mechanismen enden, wo echtes Backup anfängt, und wie du eine 3-2-1-taugliche Strategie für Exchange Online, SharePoint, OneDrive und Teams aufbaust.

Das Shared-Responsibility-Modell verstehen

Microsoft 365 folgt – wie jeder SaaS-Dienst – einem geteilten Verantwortungsmodell. Die Trennlinie verläuft anders, als viele annehmen:

Kurz: Microsoft garantiert, dass die Plattform läuft. Was mit deinen Daten auf der Plattform passiert – versehentliches Löschen, böswilliger interner Täter, Ransomware-Verschlüsselung via synchronisiertem OneDrive-Client, ein fehlerhaftes PowerShell-Skript, eine Migration, die schiefgeht – das liegt in deiner Verantwortung. Genau dasselbe Prinzip gilt übrigens auch bei IaaS/PaaS in Azure, siehe IaaS, PaaS und SaaS richtig einordnen.

Native Aufbewahrung vs. echtes Backup – der Kernunterschied

Das ist der Punkt, an dem die meisten Missverständnisse entstehen. Microsoft 365 bietet eine ganze Reihe eingebauter Mechanismen, die sich wie ein Backup anfühlen, aber keins sind:

Der entscheidende technische Grund: All diese Mechanismen sind Teil derselben Datenbank/desselben Mandanten. Wird der Mandant kompromittiert (gestohlene Admin-Zugangsdaten, Ransomware mit Global-Admin-Rechten), kann ein Angreifer Aufbewahrungsfristen verkürzen, Litigation Holds aufheben oder den Papierkorb aktiv leeren. Ein echtes Backup dagegen liegt ausserhalb des Mandanten, mit eigener Authentifizierung, oft sogar bei einem anderen Cloud-Anbieter.

Retention Policies vs. Backup – der Unterschied, den jeder Admin kennen muss

Diese Verwechslung ist so verbreitet, dass sie einen eigenen Abschnitt verdient. Beide “bewahren Daten auf”, aber mit komplett unterschiedlichem Zweck:

Retention Policy (Microsoft Purview):

• Zweck: Compliance, rechtliche Aufbewahrungspflichten, Records Management
• Wirkung: Verhindert endgültiges Löschen/Ändern von Inhalten für einen definierten Zeitraum, oder erzwingt Löschung nach Ablauf
• Speichert keine separate Kopie – die Daten bleiben am Originalort, nur “eingefroren”
• Ist ein korrupter oder ransomware-verschlüsselter Inhalt in der Retention, bleibt er korrupt/verschlüsselt in der Retention
• Zugriff über eDiscovery, nicht über einen einfachen “Wiederherstellen”-Klick für Endanwender
• Granularität: Policy-Ebene (z. B. “alle SharePoint-Sites”, “diese Postfächer”), nicht Point-in-Time

Backup (Drittanbieter oder Microsoft 365 Backup):

• Zweck: Wiederherstellung nach Datenverlust, Fehlbedienung, Ransomware, Migrationsfehlern
• Wirkung: Erstellt unabhängige, meist unveränderliche Kopien der Daten zu bestimmten Zeitpunkten
• Point-in-Time-Restore: “Stelle diese SharePoint-Site so wieder her, wie sie am 3. Juni um 06:00 Uhr war”
• Granular: einzelne E-Mail, einzelne Datei, einzelnes Teams-Channel wiederherstellbar, ohne den Rest zu berühren
• Funktioniert unabhängig davon, ob der Mandant selbst noch intakt ist

// Beispiel: Suche in Exchange Online nach gelöschten Mails via eDiscovery
// (Retention-Kontext, KEIN Backup-Restore)
Get-ComplianceSearch -Identity "Postfach-Pruefung-2026" | Get-ComplianceSearchAction

Die 3-2-1-Regel auf Microsoft 365 übertragen

Die klassische 3-2-1-Regel (3 Kopien, 2 verschiedene Medien, 1 Kopie extern) lässt sich 1:1 auf SaaS-Daten übersetzen – siehe auch die Grundlagen in Backup-Strategie: die 3-2-1-Regel. Für M365 heisst das konkret:

Native Microsoft 365 Backup – was das neue Produkt kann (und was nicht)

Microsoft hat mit Microsoft 365 Backup (allgemein verfügbar seit 2024, weiterentwickelt) ein natives, kostenpflichtiges Add-on eingeführt, das über die reine Aufbewahrung hinausgeht:

• Deckt Exchange Online, SharePoint Online und OneDrive ab (Teams-Chatinhalte indirekt über Exchange)
• Bietet echte Point-in-Time-Restores für ganze Postfächer/Sites/Bibliotheken oder granular
• Abrechnung nach Verbrauch: ca. USD 0.15 pro GB gesicherter Daten pro Monat, Wiederherstellung selbst ist kostenlos
• Backup-Daten bleiben aber weiterhin innerhalb der Microsoft-Cloud-Infrastruktur desselben Mandanten

Das letzte Detail ist der Knackpunkt: Microsoft 365 Backup ist ein deutlicher Fortschritt gegenüber reinen Retention-Mechanismen, erfüllt aber die “1” der 3-2-1-Regel (externe, unabhängige Kopie ausserhalb der Plattform) nicht vollständig, weil die Daten im selben Ökosystem bleiben. Für viele KMU ist es trotzdem ein sinnvoller Baustein – z. B. als schnelle “erste Verteidigungslinie” für einfache Fehlbedienungen, kombiniert mit einem Drittanbieter-Backup als echter Offsite-Kopie.

# Microsoft 365 Backup aktivieren (PowerShell-Beispiel, Kurzübersicht)
Connect-MgGraph -Scopes "BackupRestore-Configuration.ReadWrite.All"

# Backup-Richtlinie für SharePoint aktivieren (vereinfachtes Beispiel)
New-MgSolutionBackupRestoreServiceApp -DisplayName "M365-Backup-SharePoint"

Drittanbieter-Backup-Tools im Vergleich

Für echte Mandanten-Unabhängigkeit brauchst du einen externen Anbieter. Die drei bekanntesten im KMU-Umfeld:

Praxisbeispiel Veeam-Konfiguration (Immutable Repository auf S3-kompatiblem Speicher):

# Object-Storage-Repository mit Immutability in Veeam Backup for Microsoft 365 anlegen
Add-VBOAmazonS3ObjectStorageRepository `
  -Account $s3Account `
  -Bucket "vbo365-backup-kmu-ch" `
  -Folder "Tenant-Contoso" `
  -EnableImmutability `
  -ImmutabilityPeriod 30

Ransomware-Recovery – der eigentliche Ernstfall

Der häufigste Grund, warum Firmen erst nach einem Vorfall in echtes Backup investieren, ist Ransomware. Das Angriffsmuster bei M365 sieht typischerweise so aus:

1. Initial Access: Phishing-Mail mit gestohlenen Zugangsdaten oder Session-Token (Adversary-in-the-Middle)
2. Persistenz: Angreifer legt eigene OAuth-App-Registrierung an oder fügt eine Mail-Weiterleitungsregel ein
3. Lateral Movement über Sync-Clients: Ist ein Endgerät mit OneDrive-Sync kompromittiert, verschlüsselt lokale Ransomware die Dateien, der Sync-Client lädt die verschlüsselten Versionen automatisch in SharePoint/OneDrive hoch
4. Erpressung: Angreifer droht mit Datenveröffentlichung, verlangt Lösegeld für Entschlüsselung

Der Recovery-Ablauf mit einem sauberen Drittanbieter-Backup:

graph TD
    A[Ransomware-Vorfall erkannt] --> B[Betroffene Konten sofort sperren / Entra ID Conditional Access verschaerfen]
    B --> C[Kompromittierungsumfang klaeren: welche Postfaecher, Sites, OneDrive-Konten]
    C --> D[Sync-Clients auf betroffenen Endgeraeten stoppen]
    D --> E[Letzten sauberen Restore-Punkt VOR Infektionszeitpunkt identifizieren]
    E --> F[Restore in isolierten Bereich oder direkt an Originalort]
    F --> G[Verifizieren: Stichproben pruefen, Malware-Scan der wiederhergestellten Dateien]
    G --> H[Nutzer informieren, Passwoerter/Tokens rotieren]

Wichtige technische Voraussetzung, die oft übersehen wird: Der Zugang zur Backup-Lösung selbst darf nicht über dieselben Entra-ID-Credentials laufen wie die Produktivumgebung, sonst hebelt ein kompromittierter Global-Admin auch den Backup-Schutz aus. Separate Multi-Faktor-Authentifizierung, idealerweise separater Identitätsprovider oder zumindest eigene, stark geschützte Break-Glass-Accounts für die Backup-Konsole.

Ergänzend gehört ein dokumentierter Ablaufplan dazu, siehe IT-Notfallplanung & Disaster Recovery und Incident-Response-Plan fürs KMU.

Entscheidungsbaum: Brauche ich Drittanbieter-Backup?

graph TD
    A[Nutzt du Microsoft 365 fuer Exchange, SharePoint, OneDrive oder Teams?] -->|Nein| Z[Kein Thema]
    A -->|Ja| B{Hast du je einen Fall gehabt, in dem Daten aelter als 30-93 Tage wiederhergestellt werden mussten?}
    B -->|Ja| C[Drittanbieter-Backup oder M365 Backup zwingend noetig]
    B -->|Noch nicht| D{Unterliegt ihr Compliance-Vorgaben, Kundenvertraegen oder Cyberversicherung mit Backup-Pflicht?}
    D -->|Ja| C
    D -->|Nein| E{Wie kritisch waeren 1-4 Wochen Datenverlust fuer den Geschaeftsbetrieb?}
    E -->|Sehr kritisch| C
    E -->|Ueberschaubar| F[Native Aufbewahrung + Retention Policies als Minimalschutz, Risiko bewusst dokumentieren]

Praxis-Checkliste für die Umsetzung im KMU

1. Bestandsaufnahme: Welche Workloads (Exchange, SharePoint, OneDrive, Teams, Entra ID) sind geschäftskritisch?
2. RPO/RTO festlegen: Wie viel Datenverlust (Recovery Point Objective) und wie lange Ausfallzeit (Recovery Time Objective) sind akzeptabel? Ein Tages-Backup reicht selten für Finanzdaten.
3. Tool auswählen: Native M365 Backup als Basis, Drittanbieter (Veeam/Datto/Afi) für echte Offsite-Kopie und Immutability.
4. Immutability aktivieren: Compliance-Modus, nicht Governance-Modus, wenn maximaler Ransomware-Schutz gewünscht ist.
5. Separate Identität für Backup-Zugriff: Eigene MFA, eigenes Break-Glass-Konto, keine Vermischung mit Produktiv-Adminrechten.
6. Restore-Tests einplanen: Mindestens vierteljährlich einen echten Restore-Test durchführen und dokumentieren – ein ungetestetes Backup ist kein Backup.
7. Retention Policies zusätzlich konfigurieren: Für Compliance-Zwecke parallel zum Backup, siehe Microsoft Purview & Compliance.
8. Dokumentation: Recovery-Ablauf, Kontakte, Zugangsdaten zur Backup-Konsole im Notfallhandbuch hinterlegen (IT-Dokumentation & Inventar).

# Beispielhafte Backup-Policy-Definition (konzeptionell, Veeam-nah)
backupPolicy:
  name: "M365-Prod-Daily"
  scope:
    - ExchangeOnline
    - SharePointOnline
    - OneDriveForBusiness
    - TeamsChats
  schedule:
    frequency: daily
    retentionDays: 2555   # 7 Jahre fuer Finanzdaten, Schweizer Aufbewahrungspflicht OR Art. 958f
  repository:
    type: ObjectStorage
    immutability: compliance
    immutabilityDays: 30
  offsite: true
  identityIsolation: true

Fazit

Microsoft 365 ist hochverfügbar, aber das ist nicht dasselbe wie “gesichert”. Native Mechanismen wie Papierkorb, Versionsverlauf und Retention Policies lösen unterschiedliche Probleme – Compliance und kurzfristige Fehlerkorrektur – aber keinen echten Datenverlust über Wochen, Monate oder durch Ransomware. Eine belastbare Strategie kombiniert das native Microsoft 365 Backup (oder mindestens saubere Retention Policies) mit einem unabhängigen Drittanbieter-Backup, das ausserhalb des Produktions-Tenants liegt, immutable gespeichert wird und regelmässig auf Restore-Fähigkeit getestet wird. Wer das einmal sauber aufsetzt, spart sich im Ernstfall nicht nur Daten, sondern auch die unangenehme Erklärung gegenüber der Geschäftsleitung, warum “die Cloud” eben doch kein Backup war.

Weiterlernen

• Übersicht über Microsoft 365-Backup – Microsoft Learn
• Retention policies and retention labels – Microsoft Learn
• Pricing model for Microsoft 365 Backup – Microsoft Learn
• Veeam Backup for Microsoft 365 – Immutability Guide
• Datto SaaS Protection für Microsoft 365
• Microsoft Service Agreement (Backup-Empfehlung)

Videos

YouTube