Notfallwiederherstellung

AccessPoint wird vollständig in Ihrem Azure-Abonnement ausgeführt. Die Planung der Notfallwiederherstellung nutzt die integrierten Redundanz- und Wiederherstellungsfunktionen von Azure. Der Herausgeber speichert keine Kundendaten, sodass die Wiederherstellung vollständig in Ihrer Kontrolle liegt.

Wiederherstellungsziele

Sicherung und Wiederherstellung

Datenbank

• Zeitpunktwiederherstellung (PITR): Automatisch, bis zu 35 Tage. Keine manuelle Konfiguration erforderlich.
• Langzeitaufbewahrung (LTR): Konfigurieren Sie wöchentliche, monatliche oder jährliche Sicherungen für die Compliance. Einrichtung über Azure-Portal > SQL Database > Sicherungen > Aufbewahrungsrichtlinien.
• Georedundante Sicherung: Standardmäßig auf Standard- und Premium-Stufen aktiviert. Ermöglicht die Wiederherstellung in einer gekoppelten Azure-Region im Falle eines regionalen Ausfalls.

Blob Storage

• Vorläufiges Löschen: Aktivieren Sie das vorläufige Löschen für Blobs und Container, um versehentlich gelöschte Dokumente wiederherzustellen. Empfohlene Aufbewahrung: 30 Tage.
• Versionierung: Aktivieren Sie die Blob-Versionierung, um frühere Versionen überschriebener Dokumente beizubehalten.

Konfiguration

Exportieren oder dokumentieren Sie Ihre Konfigurationspakete, bevor Sie größere Änderungen vornehmen. Wenn eine Konfigurationsänderung rückgängig gemacht werden muss, besteht die einzige Option darin, aus einer Datenbanksicherung wiederherzustellen.

Rollback-Verfahren

API-Rollback

Die API wird als Zip-Paket im Azure App Service bereitgestellt. Um zu einer früheren Bereitstellung zurückzukehren:

1. Öffnen Sie das Azure-Portal und navigieren Sie zu Ihrem App Service
2. Navigieren Sie zu Bereitstellungscenter > Bereitstellungsverlauf
3. Suchen Sie die vorherige erfolgreiche Bereitstellung
4. Wählen Sie sie aus und klicken Sie auf Erneut bereitstellen
5. Überprüfen Sie, ob die Anwendung ordnungsgemäß funktioniert

Wenn Sie Bereitstellungsslots verwenden, wechseln Sie über Bereitstellungsslots > Tauschen zum vorherigen Slot zurück.

Datenbank-Rollback

DacPac-Bereitstellungen sind standardmäßig additiv — neue Spalten und Tabellen werden hinzugefügt, aber vorhandene Objekte werden nicht entfernt. Dies bietet ein Sicherheitsnetz für die meisten Schemaänderungen.

Bei Datenproblemen (beschädigte oder fehlerhafte Daten) verwenden Sie die Azure SQL-Zeitpunktwiederherstellung:

1. Stellen Sie die Datenbank auf einen Zeitpunkt vor dem Problem wieder her
2. Überprüfen Sie den Inhalt der wiederhergestellten Datenbank
3. Aktualisieren Sie die App Service-Verbindungszeichenfolge, um auf die wiederhergestellte Datenbank zu verweisen, oder benennen Sie die Datenbanken um, um sie zu tauschen

SPFx-Rollback

Um das SPFx Web Part auf eine frühere Version zurückzusetzen:

1. Laden Sie das .sppkg-Paket der vorherigen Version vom Realizer-Portal herunter
2. Öffnen Sie den SharePoint-App-Katalog
3. Laden Sie das vorherige Paket hoch und ersetzen Sie die aktuelle Version
4. Klicken Sie auf Bereitstellen

Konfigurations-Rollback

Konfigurationspakete sind additiv — das Importieren eines Pakets fügt Elemente hinzu oder aktualisiert sie, entfernt jedoch keine vorhandenen. Um Konfigurationsänderungen rückgängig zu machen, stellen Sie die Datenbank aus einer Zeitpunktsicherung wieder her, die vor der Änderung erstellt wurde.

Szenarien für die Notfallwiederherstellung

Szenario 1: Versehentliche Datenlöschung

1. Aus Blob Storage gelöschte Dokumente: Wenn das vorläufige Löschen aktiviert ist, stellen Sie Blobs innerhalb des konfigurierten Aufbewahrungszeitraums wieder her
2. Gelöschte Datenbankeinträge: Verwenden Sie die Azure SQL-Zeitpunktwiederherstellung auf den Zeitpunkt vor der Löschung. Kopieren Sie die benötigten Einträge aus der wiederhergestellten Datenbank in die Produktionsumgebung.

Szenario 2: Ausfall einer Azure-Region

Wenn die Azure-Region, in der Ihre Bereitstellung gehostet wird, nicht verfügbar ist:

1. Azure SQL: Stellen Sie aus georedundanten Sicherungen auf einem neuen SQL Server in einer anderen Region wieder her
2. Blob Storage: Bei Verwendung von georedundantem Speicher (GRS oder RA-GRS) initiieren Sie ein Kontofailover. Bei Verwendung von lokal redundantem Speicher (LRS) müssen die Daten aus einer externen Sicherung wiederhergestellt werden.
3. App Service: Stellen Sie mithilfe der Bicep-Vorlage in der Wiederherstellungsregion erneut bereit
4. DNS und API-URL: Aktualisieren Sie die AccessPoint-API-URL-Speicherentität in SharePoint, um auf die neue App Service-URL zu verweisen

Szenario 3: Vollständiger Umgebungsneuaufbau

Die gesamte AccessPoint-Umgebung kann mithilfe der veröffentlichten Bereitstellungsartefakte von Grund auf neu aufgebaut werden:

1. Führen Sie die Bicep-Vorlage aus, um alle Azure-Ressourcen bereitzustellen
2. Stellen Sie die API-Zip-Datei im App Service bereit (in der ARM-Bereitstellung enthalten)
3. Das Datenbankschema wird beim ersten API-Start automatisch bereitgestellt
4. Laden Sie die SPFx-.sppkg in den SharePoint-App-Katalog hoch
5. Führen Sie Deploy-AccessPoint.ps1 aus, um die reine Entra-SQL-Authentifizierung und Graph-Berechtigungen zu konfigurieren
6. Stellen Sie die Datenbank aus der aktuellsten Sicherung wieder her, um Daten wiederherzustellen
7. Stellen Sie Blob Storage-Dokumente aus georedundanten Sicherungen wieder her

Infrastructure as Code (Bicep-Vorlagen) und das Bereitstellungsskript stellen sicher, dass die Umgebung vollständig reproduzierbar ist.

Planungsempfehlungen

• Aktivieren Sie georedundanten Speicher (GRS) im Blob Storage-Konto für regionenübergreifende Dokumentenredundanz
• Aktivieren Sie Langzeitaufbewahrung (LTR) für Azure SQL für wöchentliche, monatliche und jährliche Sicherungen über das Standard-PITR-Fenster hinaus
• Aktivieren Sie vorläufiges Löschen im Blob Storage mit einer Aufbewahrungsfrist von 30 Tagen
• Aktivieren Sie Blob-Versionierung, um überschriebene Dokumente wiederherzustellen
• Dokumentieren Sie Ihre Bereitstellungsparameter — führen Sie eine Aufzeichnung Ihres Mandantennamens, Ihrer Ressourcengruppe, Benachrichtigungs-E-Mail-Adresse und aller benutzerdefinierten App Service-Einstellungen, damit Sie schnell erneut bereitstellen können
• Testen Sie die Wiederherstellung jährlich — stellen Sie die Datenbank und den Blob Storage in einer Testumgebung wieder her, um die Funktionsfähigkeit Ihrer Sicherungen zu überprüfen
• Ziehen Sie Azure Front Door oder Traffic Manager in Betracht, wenn Ihre Organisation ein automatisches Failover mit minimaler Ausfallzeit benötigt

Gesundheitsüberwachung

AccessPoint stellt zwei Health-Check-Endpunkte bereit:

Wichtige Metriken zur Überwachung

Skalierung

Vertikale Skalierung (Hochskalieren)

Ändern Sie die App Service-Plan-Stufe unter Azure-Portal > App Service > Hochskalieren (App Service-Plan). Keine erneute Bereitstellung erforderlich.

Horizontale Skalierung (Aufskalieren)

Die AccessPoint-API ist zustandslos und unterstützt mehrere Instanzen. Konfigurieren Sie die manuelle oder automatische Skalierung unter Azure-Portal > App Service > Aufskalieren (App Service-Plan).

SQL-Skalierung

Passen Sie die Datenbankstufe an die Arbeitslast an. Gängige Dienstziele: Basic, S0, S1, S2, S3, P1, P2.

Zertifikats- und Geheimnisrotation