SharePoint- und OneDrive-Datenresilienz in Microsoft 365

In Microsoft 365 basiert OneDrive auf der SharePoint-Dateiplattform. In diesem Artikel wird nur SharePoint verwendet, um auf beide Produkte zu verweisen. Dieser Artikel gilt auch für alle anderen Produkte, die Daten in SharePoint speichern, z. B. Cloudanlagen, in Teams freigegebene Dateien, Teams-Besprechungsaufzeichnungen und -transkripte, Schleifenkomponenten und Whiteboards.

Es gibt zwei primäre Ressourcen, die den Kerninhaltsspeicher von SharePoint bilden:

• Blob storage: Benutzerinhalte, die in SharePoint hochgeladen werden, werden in Azure Storage gespeichert. SharePoint hat einen benutzerdefinierten Resilienzplan auf Basis von Azure Storage erstellt, um eine Duplizierung von Benutzerinhalten nahezu in Echtzeit und ein wirklich aktives/aktives System sicherzustellen.
• Metadaten: Metadaten zu jeder Datei werden in Azure SQL-Datenbank gespeichert. Azure SQL bietet eine vollständige Geschichte der Geschäftskontinuität, die SharePoint verwendet, und details werden weiter unten in diesem Artikel behandelt.

Der vollständige Satz von Steuerelementen zum Sicherstellen der Datenresilienz wird in weiteren Abschnitten erläutert.

Resilienz für Blobspeicher

SharePoint verfügt über eine benutzerdefinierte Lösung zum Speichern von Kundendaten in Azure Storage. Jede Datei wird gleichzeitig in eine primäre und eine sekundäre Rechenzentrumsregion geschrieben. Wenn die Schreibvorgänge in eine der Azure-Regionen fehlschlagen, tritt beim Speichern der Datei ein Fehler auf. Nachdem die Inhalte in Azure Storage geschrieben wurden, werden Prüfsummen separat mit Metadaten gespeichert und verwendet, um sicherzustellen, dass der committete Schreibvorgang bei allen zukünftigen Lesevorgängen mit der ursprünglichen Datei identisch ist. Dieselbe Technik wird in allen Workflows verwendet, um die Weitergabe von Beschädigungen zu verhindern, die auftreten sollten. In jeder Region bietet Lokal redundanter Azure-Speicher (LRS) ein hohes Maß an Zuverlässigkeit.

SharePoint verwendet Append-Only Speicher, was bedeutet, dass Microsoft nur neue Blobs hinzufügen und alte Blobs nie ändern kann, bis sie endgültig gelöscht werden. Dieser Prozess stellt sicher, dass Dateien nach dem ersten Speichern nicht geändert oder beschädigt werden können, was vor Angreifern schützt, die versuchen, alte Versionen zu beschädigen. Da der Schutz der Versionsintegrität in die Architektur von SharePoint integriert ist, können frühere Versionen des Dateiinhalts abhängig von den einzelnen Administratoreinstellungen abgerufen werden.

SharePoint-Umgebungen in beiden Rechenzentren können in beiden Azure-Regionen auf Speichercontainer zugreifen. Aus Leistungsgründen wird der Speichercontainer im selben lokalen Rechenzentrum immer bevorzugt. Leseanforderungen, die keine Ergebnisse innerhalb eines gewünschten Schwellenwerts sehen, weisen jedoch den gleichen Inhalt auf, der vom Remoterechenzentrum angefordert wurde, um sicherzustellen, dass die Daten immer verfügbar sind.

Metadatenresilienz

SharePoint-Metadaten sind auch wichtig für den Zugriff auf Benutzerinhalte, da sie den Speicherort von und Zugriffsschlüssel für die in Azure Storage gespeicherten Inhalte speichern. Diese Datenbanken werden in Azure SQL gespeichert, das über einen umfassenden Geschäftskontinuitätsplan verfügt.

SharePoint verwendet das von Azure SQL bereitgestellte Replikationsmodell und hat eine proprietäre Automatisierungstechnologie erstellt, um festzustellen, ob ein Failover erforderlich ist und den Vorgang ggf. initiieren kann. Daher fällt es aus Azure SQL-Sicht in die Kategorie "Manuelles Datenbankfailover". Die neuesten Metriken für die Wiederherstellbarkeit von Azure SQL-Datenbanken finden Sie hier.

SharePoint verwendet das Sicherungssystem von Azure SQL, um Point-in-Time-Wiederherstellungen (Point-in-Time Restores, PITR) für bis zu 14 Tage zu aktivieren.

Automatisiertes Failover

SharePoint verwendet ein benutzerdefiniertes automatisiertes Failover, um die Auswirkungen auf die Kundenerfahrung zu minimieren, wenn ein standortspezifisches Ereignis auftritt. Die überwachungsgesteuerte Automatisierung, die einen Fehler mit einer oder mehreren Komponenten erkennt, der bestimmte Schwellenwerte überschreitet, führt zu einer automatisierten Umleitung aller Benutzeraktivitäten aus der problematischen Umgebung zu einer warmen sekundären Umgebung. Ein Failover führt dazu, dass Metadaten- und Computespeicher vollständig aus dem neuen Rechenzentrum bereitgestellt werden. Da Blob Storage immer vollständig aktiv/aktiv ausgeführt wird, ist für ein Failover keine Änderung erforderlich. Die Computeebene bevorzugt den nächstgelegenen Blobcontainer, verwendet jedoch jederzeit sowohl lokale als auch Remote-Blobspeicherorte, um die Verfügbarkeit sicherzustellen.

SharePoint verwendet den Azure Front Door-Dienst, um internes Routing im Microsoft-Netzwerk bereitzustellen. Diese Konfiguration ermöglicht die Failoverumleitung unabhängig von DNS und verringert die Auswirkungen des Zwischenspeicherns auf lokalen Computern. Die meisten Failovervorgänge sind für Endbenutzer transparent. Bei einem Failover müssen Kunden keine Änderungen vornehmen, um den Zugriff auf den Dienst aufrechtzuerhalten.

Versionsverwaltung und Dateiwiederherstellung

Für neu erstellte Dokumentbibliotheken ist SharePoint standardmäßig auf 500 Versionen für jede Datei festgelegt und kann so konfiguriert werden, dass bei Bedarf weitere Versionen beibehalten werden. Die Benutzeroberfläche lässt nicht zu, dass ein Wert unter 100 Versionen festgelegt wird, aber es ist möglich, das System so festzulegen, dass weniger Versionen mithilfe öffentlicher APIs gespeichert werden. Aus Gründen der Zuverlässigkeit wird ein Wert unter 100 nicht empfohlen und kann dazu führen, dass Benutzeraktivitäten unbeabsichtigten Datenverlust verursachen.

Weitere Informationen zur Versionsverwaltung finden Sie unter Versionsverwaltung in SharePoint.

Die Dateiwiederherstellung ist die Möglichkeit, in jeder Dokumentbibliothek in SharePoint auf eine Sekunde in den letzten 30 Tagen "zurück in die Zeit" zu wechseln. Dieser Prozess kann verwendet werden, um sich von Ransomware, Massenlöschungen, Beschädigungen oder anderen Ereignissen zu erholen. Dieses Feature verwendet Dateiversionen, sodass die Reduzierung von Standardversionen die Effektivität dieser Wiederherstellung verringern kann.

Das Feature "Dateien wiederherstellen" ist sowohl für OneDrive als auch für SharePoint dokumentiert.

Löschen, Sichern und Zeitpunktwiederherstellung

Aus SharePoint gelöschte Benutzerinhalte durchlaufen den folgenden Löschflow.

Gelöschte Elemente werden für einen bestimmten Zeitraum in Papierkorben aufbewahrt. Für SharePoint beträgt die Aufbewahrungsdauer 93 Tage. Sie beginnt, wenn Sie das Element an seinem ursprünglichen Speicherort löschen. Wenn Sie das Element aus dem Papierkorb der Website löschen, wird es in den Papierkorb der Websitesammlung verschoben. Sie bleibt dort für die restlichen 93 Tage und wird dann endgültig gelöscht. Weitere Informationen zur Verwendung des Papierkorbs finden Sie unter diesen Links:

• Wiederherstellen von Elementen im Papierkorb
• Wiederherstellen gelöschter Elemente aus dem Papierkorb der Websitesammlung.

Dieser Prozess ist der Standardlöschvorgang und berücksichtigt keine Aufbewahrungsrichtlinien oder Bezeichnungen. Weitere Informationen finden Sie unter Informationen zur Aufbewahrung für SharePoint und OneDrive.

Nachdem die 93-Tage-Wiederverwendungspipeline abgeschlossen ist, erfolgt der Löschvorgang unabhängig von Metadaten und für Blob Storage. Metadaten werden sofort aus der Datenbank entfernt, sodass der Inhalt nicht lesbar ist, es sei denn, die Metadaten werden aus der Sicherung wiederhergestellt. SharePoint verwaltet Sicherungen von Metadaten im Wert von 14 Tagen. Diese Sicherungen werden lokal nahezu in Echtzeit erstellt und dann in den Speicher in redundanten Azure Storage-Containern mithilfe eines 5-10-minütigen Zeitplans gepusht, wie aus der Dokumentation zum Zeitpunkt dieser Veröffentlichung zu entnehmen ist.

Darüber hinaus haben Kunden auch die Möglichkeit, Microsoft 365 Backup für die Datenwiederherstellung zu verwenden. Microsoft 365 Backup bietet eine längere Schutzzeit und bietet eine einzigartig schnelle Wiederherstellung nach gängigen Szenarien für Geschäftskontinuität und Notfallwiederherstellung (BCDR) wie Ransomware oder versehentliches/böswilliges Überschreiben/Löschen von Mitarbeiterinhalten. Zusätzliche BCDR-Szenarioschutze sind auch direkt in den Dienst integriert und bieten ein erweitertes Datenschutzniveau.

Wenn Blob Storage-Inhalte gelöscht werden, verwendet SharePoint das Feature für vorläufiges Löschen für Azure Blob Storage, um vor versehentlichem oder böswilligem Löschen zu schützen. Mit diesem Feature gibt es insgesamt 14 Tage, in denen Inhalte wiederhergestellt werden, bevor sie endgültig gelöscht werden. Da Blobs unveränderlich sind, kann Microsoft den Status einer Datei auch für einen Zeitraum von 14 Tagen wiederherstellen.

Hinweis

Während Microsoft-Anwendungen Inhalte für den Standardprozess an den Papierkorb senden, stellt SharePoint APIs bereit, die es ermöglichen, den Papierkorb zu überspringen und ein sofortiges Löschen zu erzwingen. Überprüfen Sie Ihre Anwendungen, um sicherzustellen, dass dies nur erfolgt, wenn dies aus Compliancegründen erforderlich ist.

Integritätsüberprüfungen

SharePoint verwendet verschiedene Methoden, um die Integrität von Blobs und Metadaten in allen Phasen des Datenlebenszyklus sicherzustellen:

• In Metadaten gespeicherter Dateihash: Der Hash der gesamten Datei wird mit Dateimetadaten gespeichert, um sicherzustellen, dass die Datenintegrität auf Dokumentebene während aller Vorgänge aufrechterhalten wird.
• In Metadaten gespeicherter Blobhash: Jedes Blobelement speichert einen Hash des verschlüsselten Inhalts, um im zugrunde liegenden Azure-Speicher vor Beschädigungen zu schützen.
• Datenintegritätsauftrag: Alle 14 Tage wird jeder Standort auf Integrität überprüft, indem Elemente in der Datenbank aufgelistet und diese mit aufgelisteten Blobs in Azure Storage abgegleicht werden. Der Auftrag meldet alle Blobverweise, die storage-blobs fehlen, und kann diese Blobs bei Bedarf über das Feature für vorläufiges Löschen von Azure Storage abrufen.