Översikt över affärskontinuitet med Azure SQL Managed Instance

Artikel
2025-04-06

gäller för:Azure SQL Managed Instance

Den här artikeln innehåller en översikt över funktionerna för affärskontinuitet och haveriberedskap i Azure SQL Managed Instance och beskriver alternativen och rekommendationerna för återställning från störande händelser som kan leda till dataförlust eller leda till att din instans och ditt program blir otillgängligt. Lär dig vad du ska göra när ett användar- eller programfel påverkar dataintegriteten, en Azure-tillgänglighetszon eller en region har ett avbrott eller om ditt program kräver underhåll.

Överblick

Affärskontinuitet i Azure SQL Managed Instance refererar till de mekanismer, principer och procedurer som gör att ditt företag kan fortsätta att arbeta med avbrott genom att tillhandahålla tillgänglighet, hög tillgänglighet och haveriberedskap.

I de flesta fall hanterar SQL Managed Instance störande händelser som kan inträffa i en molnmiljö och håller dina program och affärsprocesser igång. Det finns dock några störande händelser där åtgärder kan ta lite tid, till exempel:

Användaren tar av misstag bort eller uppdaterar en rad i en tabell.
En skadlig angripare lyckas radera data eller släppa en databas.
Katastrofala naturkatastrofer drabbar ett datacenter, en tillgänglighetszon eller en region.
Sällsynta datacenter, tillgänglighetszoner eller regionomfattande avbrott som orsakas av en konfigurationsändring, programvarufel eller maskinvarukomponentfel.

För förebyggande rekommendationer för att maximera tillgängligheten och uppnå högre affärskontinuitet, se:

Hög tillgänglighet

Azure SQL Managed Instance levereras med ett kärnåterhämtnings- och tillförlitlighetslöfte som skyddar den mot programvaru- eller maskinvarufel. Databassäkerhetskopior automatiseras för att skydda dina data från skador eller oavsiktlig borttagning. Som en PaaS (Platform-as-a-service) tillhandahåller tjänsten Azure SQL Managed Instance tillgänglighet som en inbyggd funktion med ett branschledande SLA för tillgänglighet på 99,99%.

Aktivera zonredundans för att uppnå hög tillgänglighet i Azure-molnmiljön. Med zonredundans använder instansen tillgänglighetszoner för att säkerställa motståndskraft mot zonfel.

Många Azure-regioner tillhandahåller tillgänglighetszoner, som är avgränsade grupper av datacenter i en region som har oberoende infrastruktur för ström, kylning och nätverk.
Tillgänglighetszoner är utformade för att tillhandahålla regionala tjänster, kapacitet och hög tillgänglighet i de återstående zonerna om en zon drabbas av ett avbrott.

Genom att aktivera zonredundans är instansen motståndskraftig mot zonindelade maskinvaru- och programvarufel och återställningen är transparent för program. När hög tillgänglighet är aktiverad kan Tjänsten Azure SQL Managed Instance tillhandahålla ett serviceavtal med högre tillgänglighet på 99,99%.

Katastrofåterställning

För att uppnå högre tillgänglighet och redundans mellan regioner kan du aktivera katastrofåterställningsfunktioner för att snabbt återställa systemet från ett katastrofalt regionalt fel. Alternativ för haveriberedskap med Azure SQL Managed Instance är:

Failover-grupper aktiverar kontinuerlig synkronisering mellan en primär och sekundär instans. Failover-grupper tillhandahåller skrivbara och skrivskyddade lyssnarslutpunkter som förblir oförändrade, så det är inte nödvändigt att uppdatera programanslutningssträngarna efter överväxling.
Geo-restore gör att du kan återställa från ett regionalt avbrott genom att återställa från geo-replikerats säkerhetskopior när du inte kan komma åt databasen i den primära regionen genom att skapa en ny databas på en befintlig instans i valfri Azure-region.

RTO och RPO

När du utvecklar din affärskontinuitetsplan ska du förstå den maximala godkända tiden innan programmet återställs helt efter den störande händelsen. Två vanliga sätt att kvantifiera affärskrav kring haveriberedskap är:

Mål för återställningstid (RTO): Den tid som krävs för att ett program ska återställas helt efter en oplanerad störande händelse.
Mål för återställningspunkt (RPO): Den tidsperiod för dataförlust som kan tolereras från en oplanerad störande händelse.

I följande tabell jämförs RPO och RTO för varje alternativ för affärskontinuitet:

alternativ för affärskontinuitet	RTO (stilleståndstid)	RPO (dataförlust)
Hög tillgänglighet (med zonredundans)	Vanligtvis mindre än 30 sekunder	0
Haveriberedskap (använda redundansgrupper med kundhanterad redundansprincip)	Vanligtvis mindre än 60 sekunder	Lika med eller större än 0 (beror på dataändringar före den störande händelsen som inte har replikerats)
Katastrofåterställning (med geo-återställning)	12 timmar	1 timme

Funktioner som ger affärskontinuitet

Det finns till exempel fyra stora potentiella avbrottsscenarier. I följande tabell visas funktioner för affärskontinuitet i SQL Managed Instance som du kan använda för att minimera ett potentiellt scenario med affärsstörningar:

Scenario för avbrott i verksamheten	Funktion för affärskontinuitet
Lokala maskinvaru- eller programvarufel som påverkar databasnoden.	För att undvika lokala maskinvaru- och programvarufel innehåller SQL Managed Instance en tillgänglighetsarkitektur, som garanterar automatisk återställning från dessa fel med upp till 99,99% tillgänglighets-SLA.
Skadade eller borttagna data orsakas vanligtvis av ett programfel eller ett mänskligt fel. Sådana fel är programspecifika och kan vanligtvis inte identifieras av tjänsten.	För att skydda ditt företag mot dataförlust skapar SQL Managed Instance automatiskt fullständiga databassäkerhetskopior varje vecka, differentiella databassäkerhetskopieringar var 12:e eller 24:e timme och säkerhetskopieringar av transaktionsloggar var 5–10:e minut. Som standardinställning lagras säkerhetskopior i geo-redundant lagring i sju dagar och stöder en konfigurerbar kvarhållningsperiod för återställning till en viss tidpunkt på upp till 35 dagar. Du kan återställa en borttagen databas till den punkt då den togs bort om instansen inte har tagits bort eller om du har konfigurerat långsiktig kvarhållning.
Sällsynt avbrott i datacenter eller tillgänglighetszoner, möjligen orsakat av en naturkatastrofhändelse, konfigurationsändring, programvarufel eller maskinvarukomponentfel.	För att minska risken för avbrott på datacenternivå eller tillgänglighetszon, aktivera zonredundans för SQL Managed Instance. Detta gör att du kan använda Azure-tillgänglighetszoner och tillhandahålla redundans över flera fysiska zoner inom en Azure-region. Aktivering av zonredundans säkerställer att den hanterade instansen är motståndskraftig mot zonfel med upp till 99,99% serviceavtal med hög tillgänglighet.
Ovanligt regionavbrott som påverkar alla tillgänglighetszoner och de datacenter som ingår i den, möjligen orsakat av en katastrofal naturkatastrof.	Om du vill minimera ett regionomfattande avbrott aktiverar du haveriberedskap med något av alternativen: – Kontinuerlig datasynkronisering med failovergrupper till repliker i en sekundär region som används för failover. – Ställa in redundans för geo-redundant säkerhetskopieringslagring för att använda geo-återställning.

Återställa en databas inom samma Azure-region

Du kan använda automatiska databassäkerhetskopior för att återställa en databas till en tidpunkt tidigare. På så sätt kan du återställa från skadade data som orsakas av mänskliga fel. Med återställning till tidpunkt (PITR) kan du skapa en ny databas på samma instans, eller en annan instans, som representerar tillståndet för data innan den korrumperande händelsen. Återställningsåtgärden är en åtgärd som beror på datamängden och påverkas också av målinstansens aktuella arbetsbelastning. Det kan ta längre tid att återställa en mycket stor eller mycket aktiv databas. Mer information om återställningstid finns i databasåterställningstid.

Om den maximala kvarhållningsperioden för säkerhetskopiering som stöds för återställning till en specifik tidpunkt (PITR) inte är tillräcklig för din applikation, kan du utöka den genom att konfigurera en policy för långsiktig kvarhållning (LTR) för databaserna. Mer information finns i Långsiktig kvarhållning.

Återställa en databas till en befintlig instans

Även om det är ovanligt kan ett Azure-datacenter ha ett avbrott. När ett avbrott inträffar orsakar det ett avbrott i verksamheten som kanske bara varar några minuter eller kan pågå i timmar.

Ett alternativ är att vänta tills instansen är online igen när datacentrets avbrott är över. Detta fungerar för program som har råd att ha sin databas offline. Till exempel ett utvecklingsprojekt eller en kostnadsfri utvärderingsversion som du inte behöver arbeta med hela tiden. När ett datacenter har ett avbrott vet du inte hur länge avbrottet kan pågå, så det här alternativet fungerar bara om du inte behöver databasen på ett tag.
Om du använder geo-redundant (GRS) eller geo-zonredundant lagring (GZRS), är ett annat alternativ att återställa en databas till en valfri SQL-hanterad instans i någon Azure-region med hjälp av geo-redundanta databassäkerhetskopior (geo-återställning). Geo-återställning använder en geo-redundant säkerhetskopia som källa och kan användas för att återställa en databas till den senaste tillgängliga tidpunkten, även om databasen eller datacentret är otillgängligt på grund av ett avbrott. Den tillgängliga säkerhetskopian finns i den associerade regionen.
Slutligen kan du snabbt återställa från ett avbrott om du har konfigurerat en geo-sekundär med hjälp av en redundansgrupp för din instans med hjälp av antingen kund (rekommenderas) eller Microsoft-hanterad redundans. Även om själva failoverprocessen bara tar några sekunder, tar det minst 1 timme att aktivera en Microsoft-hanterad geo-failover för tjänsten, om den är konfigurerad. Detta är nödvändigt för att säkerställa att redundansväxlingen motiveras av driftstoppets omfattning. Redundansväxlingen kan också leda till förlust av nyligen ändrade data på grund av typen av asynkron replikering mellan de kopplade regionerna.

När du utvecklar din affärskontinuitetsplan måste du förstå den maximala godkända tiden innan programmet återställs helt efter störande händelsen. Den tid som krävs för att programmet ska återställas helt kallas för mål för återställningstid (RTO). Du måste också förstå den maximala perioden för de senaste datauppdateringarna (tidsintervall) som programmet kan tolerera att förlora när det återställs från en oplanerad störande händelse. Den potentiella dataförlusten kallas mål för återställningspunkt (RPO).

Olika återställningsmetoder erbjuder olika nivåer av RPO och RTO. Du kan välja en specifik återställningsmetod eller använda en kombination av metoder för att uppnå fullständig programåterställning.

Använd redundansgrupper om ditt program uppfyller något av följande kriterier:

Är verksamhetskritisk.
Har ett serviceavtal (SLA) som inte tillåter 12 timmar eller mer stilleståndstid.
Stilleståndstid kan leda till ekonomisk skuld.
Har en hög dataändringshastighet och 1 timmes dataförlust är inte acceptabelt.
Den extra kostnaden för aktiv geo-replikering är lägre än den potentiella ekonomiska skulden och tillhörande förlust av verksamhet.

Du kan välja att använda en kombination av databassäkerhetskopior och redundansgrupper beroende på dina programkrav.

Följande avsnitt innehåller en översikt över stegen för att återställa med hjälp av antingen databassäkerhetskopior eller redundansgrupper.

Förbereda för ett avbrott

Oavsett vilken funktion för affärskontinuitet du använder måste du:

Identifiera och förbereda målinstansen, inklusive nätverks-IP-brandväggsregler, inloggningar och master behörigheter på databasnivå.
Fastställ hur du omdirigerar klienter och klientprogram till den nya instansen
Dokumentera andra beroenden, till exempel granskningsinställningar och aviseringar

Om du inte förbereder dig korrekt tar det längre tid att ansluta dina program efter en redundansväxling eller databasåterställning, och kräver förmodligen även felsökning i en tid av stress – en dålig kombination.

Växla över till en geo-replikerad sekundär instans

Om du använder failover-grupper som återställningsmekanism kan du konfigurera en automatisk failover-policy. När redundansväxlingen har initierats blir den sekundära instansen den nya primära, redo att registrera nya transaktioner och svara på frågor – med minimal dataförlust för data som ännu inte replikerats.

Not

När datacentret åter kommer online återansluter den tidigare primära enheten automatiskt till den nya primära för att bli den sekundära instansen. Om du behöver flytta tillbaka den primära till den ursprungliga regionen kan du initiera en planerad övergång manuellt (återgång).

Utföra en geoåterställning

Om du använder automatiserade säkerhetskopior med geo-redundant lagring (standardlagringsalternativet när du skapar din instans) kan du återställa databasen med hjälp av geo-återställning. Återställning sker vanligtvis inom 12 timmar – med dataförlust på upp till en timme som bestäms av när den senaste loggkopian togs och replikerades. Förrän återställningen har slutförts kan databasen inte registrera några transaktioner eller svara på några frågor. Observera att geo-återställning endast återställer databasen till den senaste tillgängliga tidpunkten.

Obs!

Om datacentret är online igen innan du växlar över ditt program till den återställda databasen kan du avbryta återställningen.

Utföra uppgifter efter failöver/återställning

Efter återställning från någon av återställningsmekanismerna måste du utföra följande ytterligare uppgifter innan dina användare och program säkerhetskopieras och körs:

Omdirigera klienter och klientprogram till den nya instansen och återställd databas.
Se till att det finns lämpliga ip-brandväggsregler för nätverket för användare att ansluta.
Se till att lämpliga inloggningar och master behörigheter på databasnivå finns på plats (eller använd inneslutna användare).
Konfigurera granskning efter behov.
Konfigurera aviseringar efter behov.

Notera

Om du använder en redundansgrupp och ansluter till instansen med läs-och-skriv-lyssnaren sker omdirigeringen efter redundansväxlingen automatiskt och transparent till programmet.

Licensfria Disaster Recovery-kopior

Du kan spara på licenskostnader genom att konfigurera en sekundär Azure SQL Managed Instance enbart för katastrofåterställning (DR). Den här fördelen är tillgänglig om du använder en redundansgrupp mellan två SQL-hanterade instanser eller om du har konfigurerat en hybridlänk mellan SQL Server och Azure SQL Managed Instance. Så länge den sekundära instansen inte har några läs- eller skrivarbetsbelastningar på den och endast är ett passivt DR-vänteläge debiteras du inte för de licensieringskostnader för virtuella kärnor som används av den sekundära instansen.

När du utser en sekundär instans endast för haveriberedskap och inga läs- eller skrivarbetsbelastningar körs på instansen, ger Microsoft dig det antal virtuella kärnor som är licensierade till den primära instansen utan extra kostnad på grund av failover-rättighetsförmånen. Du debiteras fortfarande för den beräkning och lagring som den sekundära instansen använder. Exakta villkor för hybrid redundansrättsförmånen finns i SQL Server-licensvillkoren online i avsnittet "SQL Server – Redundansrättigheter" .

Namnet på förmånen beror på ditt scenario:

Hybrid failover-rättigheter för en passiv replik: När du konfigurerar en länk mellan SQL Server och Azure SQL Managed Instance kan du använda Hybrid failover-rättigheterna för att spara på vCore-licenseringskostnader för den passiva sekundära repliken.
Växlingrättigheter för en sekundär replik i vänteläge: När du konfigurerar en växlingsgrupp mellan två hanterade instanser, kan du använda växlingrättigheter för att spara på licensieringskostnaderna för virtuella kärnor för den sekundära repliken i vänteläge.

Följande diagram visar fördelarna för varje scenario:

Nästa steg

Hög tillgänglighet och checklista för katastrofåterställning

Dela via