Katastrofåterställning

AccessPoint körs helt i din Azure-prenumeration. Planering av katastrofåterställning utnyttjar Azures inbyggda redundans- och återställningsfunktioner. Utgivaren innehar inga kunddata, så återställning ligger helt under din kontroll.

Återställningsmål

Säkerhetskopiering och återställning

Databas

• Tidpunktsåterställning (PITR): Automatisk, upp till 35 dagar. Ingen manuell konfiguration krävs.
• Långtidslagring (LTR): Konfigurera veckovisa, månatliga eller årliga säkerhetskopior för regelefterlevnad. Ställ in via Azure Portal > SQL Database > Backups > Retention policies.
• Geo-redundant säkerhetskopiering: Aktiverad som standard på Standard- och Premium-nivåer. Tillåter återställning till en parad Azure-region vid regionalt avbrott.

Blob Storage

• Soft delete: Aktivera soft delete för blobbar och containrar för att återställa oavsiktligt raderade dokument. Rekommenderad kvarhållning: 30 dagar.
• Versionshantering: Aktivera blobversionshantering för att behålla tidigare versioner av överskrivna dokument.

Konfiguration

Exportera eller dokumentera dina konfigurationspaket innan du gör stora ändringar. Om en konfigurationsändring behöver återställas är det enda alternativet att återställa från en databassäkerhetskopia.

Återrullningsprocedurer

API-återrullning

API:et distribueras som ett zip-paket till Azure App Service. För att återgå till en tidigare distribution:

1. Öppna Azure Portal och navigera till din App Service
2. Gå till Deployment Center > Deployment history
3. Lokalisera den tidigare lyckade distributionen
4. Välj den och klicka på Redeploy
5. Verifiera att applikationen fungerar korrekt

Om du använder distributionsplatser, byt tillbaka till den tidigare platsen via Deployment slots > Swap.

Databasåterrullning

DacPac-distributioner är additiva som standard — nya kolumner och tabeller läggs till men befintliga objekt tas inte bort. Detta ger ett skyddsnät för de flesta schemaändringar.

Vid dataproblem (korrupt eller felaktig data), använd Azure SQL tidpunktsåterställning:

1. Återställ databasen till en tidpunkt innan problemet uppstod
2. Verifiera den återställda databasens innehåll
3. Uppdatera App Service-anslutningssträngen till att peka på den återställda databasen, eller döp om databaserna för att byta dem

SPFx-återrullning

För att återställa SPFx-webbdelen till en tidigare version:

1. Ladda ner den tidigare versionens .sppkg-paket från Realizer-portalen
2. Öppna SharePoint App Catalog
3. Ladda upp det tidigare paketet och ersätt den aktuella versionen
4. Klicka på Deploy

Konfigurationsåterrullning

Konfigurationspaket är additiva — import av ett paket lägger till eller uppdaterar poster men tar inte bort befintliga. För att återställa konfigurationsändringar, återställ databasen från en tidpunktssäkerhetskopia tagen innan ändringen.

Scenarier för katastrofåterställning

Scenario 1: Oavsiktlig radering av data

1. Dokument raderade från Blob Storage: Om soft delete är aktiverat, återställ blobbar inom det konfigurerade kvarhållningsfönstret
2. Databasposter raderade: Använd Azure SQL tidpunktsåterställning till tidpunkten innan raderingen. Kopiera de nödvändiga posterna från den återställda databasen till produktion.

Scenario 2: Azure-regionavbrott

Om Azure-regionen som är värd för din distribution blir otillgänglig:

1. Azure SQL: Återställ från geo-redundanta säkerhetskopior till en ny SQL Server i en annan region
2. Blob Storage: Om geo-redundant lagring (GRS eller RA-GRS) används, initiera en kontoväxling. Om lokalt redundant lagring (LRS) används måste data återställas från en extern säkerhetskopia.
3. App Service: Omdistribuera med Bicep-mallen i återställningsregionen
4. DNS och API-URL: Uppdatera AccessPoint API-URL storage entity i SharePoint till att peka på den nya App Service-URL:en

Scenario 3: Fullständig miljöåteruppbyggnad

Hela AccessPoint-miljön kan återuppbyggas från grunden med de publicerade distributionsartefakterna:

1. Kör Bicep-mallen för att etablera alla Azure-resurser
2. Distribuera API-zip:en till App Service (inkluderad i ARM-distributionen)
3. Databasschemat distribueras automatiskt vid första API-starten
4. Ladda upp SPFx .sppkg till SharePoint App Catalog
5. Kör Deploy-AccessPoint.ps1 för att konfigurera Entra-only SQL-autentisering och Graph-behörigheter
6. Återställ databasen från den senaste säkerhetskopian för att återhämta data
7. Återställ Blob Storage-dokument från geo-redundanta säkerhetskopior

Infrastructure as Code (Bicep-mallar) och distributionsskriptet säkerställer att miljön är fullt reproducerbar.

Planeringsrekommendationer

• Aktivera geo-redundant lagring (GRS) på Blob Storage-kontot för dokumentredundans mellan regioner
• Aktivera långtidslagring (LTR) på Azure SQL för veckovisa, månatliga och årliga säkerhetskopior utöver standard PITR-fönstret
• Aktivera soft delete på Blob Storage med 30 dagars kvarhållningsperiod
• Aktivera blobversionshantering för att återställa överskrivna dokument
• Dokumentera dina distributionsparametrar — spara en förteckning över klientorganisationsnamn, resursgrupp, larm-e-post och eventuella anpassade App Service-inställningar så att du snabbt kan omdistribuera
• Testa återställning årligen — återställ databasen och Blob Storage till en testmiljö för att verifiera att dina säkerhetskopior fungerar
• Överväg Azure Front Door eller Traffic Manager om din organisation kräver automatisk redundansväxling med minimal driftstopp

Hälsoövervakning

AccessPoint exponerar två hälsokontrollendpoints:

Nyckeltal att övervaka

Skalning

Vertikal skalning (Scale Up)

Ändra App Service Plan-nivån i Azure Portal > App Service > Scale up (App Service plan). Ingen omdistribution krävs.

Horisontell skalning (Scale Out)

AccessPoint API:et är tillståndslöst och stöder flera instanser. Konfigurera manuell eller automatisk skalning i Azure Portal > App Service > Scale out (App Service plan).

SQL-skalning

Justera databasnivån baserat på arbetsbelastning. Vanliga servicenivåer: Basic, S0, S1, S2, S3, P1, P2.

Certifikat- och hemlighetsrotation