Odzyskiwanie po awarii

AccessPoint działa w całości w Twojej subskrypcji Azure. Planowanie odzyskiwania po awarii wykorzystuje wbudowane w Azure mechanizmy redundancji i odzyskiwania. Wydawca nie przechowuje żadnych danych klientów, więc odzyskiwanie jest w pełni pod Twoją kontrolą.

Cele odzyskiwania

Tworzenie kopii zapasowych i przywracanie

Baza danych

• Przywracanie do punktu w czasie (PITR): Automatyczne, do 35 dni. Nie wymaga ręcznej konfiguracji.
• Długoterminowe przechowywanie (LTR): Skonfiguruj tygodniowe, miesięczne lub roczne kopie zapasowe w celu zapewnienia zgodności z przepisami. Konfiguracja w Azure Portal > SQL Database > Backups > Retention policies.
• Geo-redundantna kopia zapasowa: Włączona domyślnie na warstwach Standard i Premium. Umożliwia przywracanie do sparowanego regionu Azure w przypadku awarii regionalnej.

Blob Storage

• Soft delete: Włącz soft delete dla blobów i kontenerów, aby odzyskać przypadkowo usunięte dokumenty. Zalecany okres przechowywania: 30 dni.
• Wersjonowanie: Włącz wersjonowanie blobów, aby zachować poprzednie wersje nadpisanych dokumentów.

Konfiguracja

Wyeksportuj lub udokumentuj swoje pakiety konfiguracyjne przed wprowadzeniem większych zmian. Jeśli zmiana konfiguracji wymaga cofnięcia, jedyną opcją jest przywrócenie z kopii zapasowej bazy danych.

Procedury wycofywania zmian

Wycofanie API

API jest wdrażane jako pakiet zip w Azure App Service. Aby przywrócić poprzednie wdrożenie:

1. Otwórz Azure Portal i przejdź do swojego App Service
2. Przejdź do Deployment Center > Deployment history
3. Zlokalizuj poprzednie udane wdrożenie
4. Wybierz je i kliknij Redeploy
5. Sprawdź, czy aplikacja działa prawidłowo

Jeśli używasz slotów wdrożeniowych, zamień z powrotem na poprzedni slot za pomocą Deployment slots > Swap.

Wycofanie bazy danych

Wdrożenia DacPac są domyślnie addytywne — nowe kolumny i tabele są dodawane, ale istniejące obiekty nie są usuwane. Zapewnia to siatkę bezpieczeństwa dla większości zmian schematu.

W przypadku problemów z danymi (uszkodzone lub nieprawidłowe dane), użyj przywracania do punktu w czasie Azure SQL:

1. Przywróć bazę danych do momentu przed wystąpieniem problemu
2. Zweryfikuj zawartość przywróconej bazy danych
3. Zaktualizuj ciąg połączenia App Service, aby wskazywał na przywróconą bazę danych, lub zmień nazwy baz danych, aby je zamienić

Wycofanie SPFx

Aby przywrócić web part SPFx do poprzedniej wersji:

1. Pobierz pakiet .sppkg poprzedniej wersji z portalu Realizer
2. Otwórz SharePoint App Catalog
3. Prześlij poprzedni pakiet, zastępując bieżącą wersję
4. Kliknij Deploy

Wycofanie konfiguracji

Pakiety konfiguracyjne są addytywne — importowanie pakietu dodaje lub aktualizuje elementy, ale nie usuwa istniejących. Aby cofnąć zmiany konfiguracji, przywróć bazę danych z kopii zapasowej do punktu w czasie wykonanej przed zmianą.

Scenariusze odzyskiwania po awarii

Scenariusz 1: Przypadkowe usunięcie danych

1. Dokumenty usunięte z Blob Storage: Jeśli soft delete jest włączony, odzyskaj bloby w skonfigurowanym oknie przechowywania
2. Usunięte rekordy bazy danych: Użyj przywracania do punktu w czasie Azure SQL do momentu przed usunięciem. Skopiuj potrzebne rekordy z przywróconej bazy danych do produkcji.

Scenariusz 2: Awaria regionu Azure

Jeśli region Azure hostujący Twoje wdrożenie stanie się niedostępny:

1. Azure SQL: Przywróć z geo-redundantnych kopii zapasowych do nowego SQL Server w innym regionie
2. Blob Storage: Jeśli używasz magazynu geo-redundantnego (GRS lub RA-GRS), zainicjuj przełączenie konta. Jeśli używasz magazynu lokalnie redundantnego (LRS), dane muszą zostać przywrócone z zewnętrznej kopii zapasowej.
3. App Service: Wdróż ponownie za pomocą szablonu Bicep w regionie odzyskiwania
4. DNS i adres URL API: Zaktualizuj storage entity adresu URL API AccessPoint w SharePoint, aby wskazywał na nowy adres URL App Service

Scenariusz 3: Pełna odbudowa środowiska

Całe środowisko AccessPoint może zostać odbudowane od podstaw przy użyciu opublikowanych artefaktów wdrożeniowych:

1. Uruchom szablon Bicep, aby udostępnić wszystkie zasoby Azure
2. Wdróż zip API w App Service (dołączony do wdrożenia ARM)
3. Schemat bazy danych jest automatycznie wdrażany przy pierwszym uruchomieniu API
4. Prześlij SPFx .sppkg do SharePoint App Catalog
5. Uruchom Deploy-AccessPoint.ps1, aby skonfigurować uwierzytelnianie SQL Entra-only i uprawnienia Graph
6. Przywróć bazę danych z najnowszej kopii zapasowej w celu odzyskania danych
7. Przywróć dokumenty Blob Storage z geo-redundantnych kopii zapasowych

Infrastruktura jako kod (szablony Bicep) i skrypt wdrożeniowy zapewniają pełną powtarzalność środowiska.

Zalecenia dotyczące planowania

• Włącz magazyn geo-redundantny (GRS) na koncie Blob Storage w celu zapewnienia redundancji dokumentów między regionami
• Włącz długoterminowe przechowywanie (LTR) w Azure SQL dla tygodniowych, miesięcznych i rocznych kopii zapasowych wykraczających poza domyślne okno PITR
• Włącz soft delete w Blob Storage z 30-dniowym okresem przechowywania
• Włącz wersjonowanie blobów w celu odzyskiwania nadpisanych dokumentów
• Udokumentuj parametry wdrożenia — przechowuj zapis nazwy dzierżawcy, grupy zasobów, adresu e-mail do alertów i wszelkich niestandardowych ustawień App Service, abyś mógł szybko ponownie wdrożyć
• Testuj odzyskiwanie corocznie — przywróć bazę danych i Blob Storage do środowiska testowego, aby sprawdzić, czy kopie zapasowe działają
• Rozważ Azure Front Door lub Traffic Manager, jeśli Twoja organizacja wymaga automatycznego przełączania awaryjnego z minimalnym przestojem

Monitorowanie stanu zdrowia

AccessPoint udostępnia dwa endpointy kontroli stanu zdrowia:

Kluczowe metryki do monitorowania

Skalowanie

Skalowanie pionowe (Scale Up)

Zmień warstwę App Service Plan w Azure Portal > App Service > Scale up (App Service plan). Nie wymaga ponownego wdrożenia.

Skalowanie poziome (Scale Out)

API AccessPoint jest bezstanowe i obsługuje wiele instancji. Skonfiguruj skalowanie ręczne lub automatyczne w Azure Portal > App Service > Scale out (App Service plan).

Skalowanie SQL

Dostosuj warstwę bazy danych na podstawie obciążenia. Typowe cele usługi: Basic, S0, S1, S2, S3, P1, P2.

Rotacja certyfikatów i sekretów