Översikt över affärskontinui med Azure SQL Database & Azure SQL Managed Instance

GÄLLER FÖR: Azure SQL Database Azure SQL Managed Instance

Affärskontinui i Azure SQL Database och SQL Managed Instance syftar på de mekanismer, principer och procedurer som gör det möjligt för ditt företag att fortsätta att fungera vid avbrott, särskilt i infrastrukturen för databehandling. I de flesta fall hanterar SQL Database och SQL Managed Instance de avbrottshändelser som kan inträffa i molnmiljön och ser till att dina program och affärsprocesser körs. Det finns dock vissa störande händelser som inte kan hanteras av SQL Database automatiskt, till exempel:

• Användaren har tagit bort eller uppdaterat en rad i en tabell av misstag.
• Angriparen lyckades ta bort data eller ta bort en databas.
• Jordbävningen orsakade ett strömavbrott och tillfälligt inaktiverat datacenter.

Den här översikten beskriver de funktioner som SQL Database och SQL Managed Instance tillhandahåller för affärskontinuier och haveriberedskap. Lär dig mer om alternativ, rekommendationer och självstudier för att återställa från störande händelser som kan orsaka dataförlust eller göra databasen och programmet otillgängliga. Lär dig vad du kan göra när ett användar- eller programfel påverkar dataintegriteten, en Azure-region har ett avbrott eller om ditt program kräver underhåll.

SQL Database-funktioner som du kan använda för att upprätthålla affärskontinuitet

Ur ett databasperspektiv finns det fyra huvudsakliga potentiella avbrottsscenarier:

• Lokala maskinvaru- eller programvarufel som påverkar databasnoden, till exempel ett diskenhetsfel.
• Skadade data eller borttagningar orsakas vanligtvis av ett programfel eller ett mänskligt fel. Sådana fel är programspecifika och kan vanligtvis inte identifieras av databastjänsten.
• Datacenteravbrott, som eventuellt orsakas av en naturkatastrofer. Det här scenariot kräver en viss nivå av geo-redundans med programredundans till ett alternativt datacenter.
• Uppgraderings- eller underhållsfel, oväntade problem som inträffar under planerat infrastrukturunderhåll eller uppgraderingar kan kräva snabb återställning till ett tidigare databastillstånd.

För att minimera de lokala maskinvaru- och programvarufelen SQL Database en arkitektur med hög tillgänglighet somgaranterar automatisk återställning från dessa fel med upp till 99,995 % serviceavtal för tillgänglighet.

För att skydda ditt företag mot dataförlust skapar SQL Database och SQL Managed Instance automatiskt fullständiga databassäkerhetskopior varje vecka, differentiella databassäkerhetskopior var 12:e timme och säkerhetskopieringar av transaktionsloggar var 5:e till var 10:e minut. Säkerhetskopiorna lagras i RA-GRS-lagring i minst sju dagar för alla tjänstnivåer. Alla tjänstnivåer utom de Basic Support kvarhållningsperioden för säkerhetskopiering som kan konfigureras för återställning till en viss tidpunkt, upp till 35 dagar.

SQL Database och SQL Managed Instance tillhandahåller också flera funktioner för affärskontinuhet som du kan använda för att minimera olika oplanerade scenarier.

• Med temporära tabeller kan du återställa radversioner från valfri tidpunkt.
• Med inbyggda automatiserade säkerhetskopieringar och återställning till tidpunkt kan du återställa hela databasen till en viss tidpunkt inom den konfigurerade kvarhållningsperioden på upp till 35 dagar.
• Du kan återställa en borttagna databas till den punkt då den togs bort om servern inte har tagits bort.
• Med långsiktig kvarhållning av säkerhetskopior kan du behålla säkerhetskopiorna i upp till 10 år. Det här är en begränsad offentlig förhandsversion för SQL Managed Instance.
• Med aktiv geo-replikering kan du skapa läsbara repliker och manuellt redundans till valfri replik i händelse av ett datacenteravbrott eller en programuppgradering.
• Med automatisk redundansgrupp kan programmet återställas automatiskt vid ett datacenteravbrott.

Återställa en databas inom samma Azure-region

Du kan använda automatiska databassäkerhetskopior för att återställa en databas till en tidigare tidpunkt. På så sätt kan du återställa från skadade data som orsakas av mänskliga fel. Med återställning till tidpunkt kan du skapa en ny databas på samma server som representerar tillståndet för data före den skadade händelsen. För de flesta databaser tar återställningsåtgärder mindre än 12 timmar. Det kan ta längre tid att återställa en mycket stor eller mycket aktiv databas. Mer information om återställningstid finns i Återställningstid för databasen.

Om den högsta kvarhållningsperioden för säkerhetskopior för återställning till tidpunkt (PITR) inte är tillräcklig för ditt program kan du utöka den genom att konfigurera en princip för långsiktig kvarhållning (LTR) för databaserna. Mer information finns i Långsiktig kvarhållning av säkerhetskopior.

Jämföra geo-replikering med redundansgrupper

Automatiska redundansgrupper förenklar distributionen och användningen av geo-replikering och lägger till ytterligare funktioner enligt beskrivningen i följande tabell:

Återställa en databas till den befintliga servern

Även om det är ovanligt kan ett Azure-datacenter ha ett avbrott. När ett avbrott uppstår orsakar det ett verksamhetsavbrott som kan vara några få minuter eller flera timmar.

• Ett alternativ är att vänta tills databasen är online igen när avbrottet i datacentret är över. Det här fungerar för program som har råd att ha databasen 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 vara, så det här alternativet fungerar bara om du inte behöver databasen på ett tag.
• Ett annat alternativ är att återställa en databas på valfri server i valfri 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 även om databasen eller datacentret inte är tillgänglig på grund av ett avbrott.
• Slutligen kan du snabbt återställa efter ett avbrott om du har konfigurerat antingen geo-sekundär med aktiv geo-replikering eller en automatisk redundansgrupp för din databas eller dina databaser. Beroende på vilken teknik du väljer kan du använda antingen manuell eller automatisk redundans. Själva redundansen tar bara några sekunder, men det tar minst en timme för tjänsten att aktivera den. Detta är nödvändigt för att säkerställa att redundansen motiveras av avbrottsskalan. Redundansen kan också leda till liten dataförlust på grund av den asynkrona replikeringen.

När du utvecklar din affärskontinuitetsplan är det viktigt att du känner till den längsta godkända tiden innan programmet är helt återställt efter en avbrottshändelse. Den tid som krävs för att programmet ska återställas helt kallas mål för återställningstid (RTO). Du måste också förstå den maximala perioden för de senaste datauppdateringarna (tidsintervallet) som programmet kan tolerera att förlora vid återställning från en oplanerad avbrottshä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. I följande tabell jämförs RPO och RTO för varje återställningsalternativ. Automatiska redundansgrupper förenklar distributionen och användningen av geo-replikering och lägger till ytterligare funktioner enligt beskrivningen i följande tabell:

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

• Är verksamhetskritiskt.
• Har ett serviceavtal (SLA) som inte tillåter 12 timmar eller mer stilleståndstid.
• Stilleståndstid kan leda till ekonomiska ansvarsansvar.
• Har en hög dataändringstakt och en timmes dataförlust är inte acceptabelt.
• Den extra kostnaden för aktiv geo-replikering är lägre än de potentiella ekonomiska skyldigheterna och den associerade affärsförlusten.

Du kan välja att använda en kombination av databassäkerhetskopior och aktiv geo-replikering beroende på dina programkrav. En diskussion om designöverväganden för fristående databaser och för elastiska pooler som använder dessa funktioner för affärskontinuisering finns i Utforma ett program för haveriberedskap i molnet och Haveriberedskapsstrategier för elastisk pool.

Följande avsnitt innehåller en översikt över stegen för att återställa med hjälp av databassäkerhetskopior eller aktiv geo-replikering. Detaljerade steg, inklusive planeringskrav, steg efter återställning och information om hur du simulerar ett avbrott för att utföra ett haveriberedskapsgranskning finns i Återställa en databas i SQL Databasefrån ett avbrott .

Förbereda för ett avbrott

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

• Identifiera och förbered målservern, inklusive IP-brandväggsregler på servernivå, inloggningar och master behörigheter på databasnivå.
• Bestämma hur du ska omdirigera klienter och klientprogram till den nya servern.
• Dokumentera andra beroenden, till exempel granskningsinställningar och aviseringar.

Om du inte förbereder dig på rätt sätt tar det längre tid att ta dina program online efter en redundans eller en databasåterställning, vilket troligen också kräver felsökning vid stress – en dålig kombination.

Redundans till en geo-replikerad sekundär databas

Om du använder aktiv geo-replikering eller automatiska redundansgrupper som återställningsmekanism kan du konfigurera en princip för automatisk redundans eller använda manuell oplanerad redundans. När den har initierats gör redundansen att den sekundära blir den nya primära och redo att registrera nya transaktioner och svara på frågor – med minimal dataförlust för data som ännu inte har replikerats. Information om hur du utformar redundansprocessen finns i Utforma ett program för haveriberedskap i molnet.

Utföra en geo-återställning

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

Utföra åtgärder efter en redundansväxling eller återställning

Efter återställningen från endera återställningsmetod måste du utföra följande ytterligare uppgifter innan dina användare och program kan komma igång igen:

• Omdirigera klienter och klientprogram till den nya servern och den återställda databasen.
• Se till att lämpliga IP-brandväggsregler på servernivå är på plats så att användarna kan ansluta till eller använda brandväggar på databasnivå för att aktivera lämpliga regler.
• Se till att rätt inloggningar och behörigheter på huvuddatabasnivå finns på plats (eller använd inneslutna användare).
• Konfigurera granskning efter behov.
• Konfigurera aviseringar efter behov.

Uppgradera ett program med minimal avbrottstid

Ibland måste ett program tas offline på grund av planerat underhåll, till exempel en programuppgradering. Hantera programuppgraderingar beskriver hur du använder aktiv geo-replikering för att aktivera löpande uppgraderingar av molnprogrammet för att minimera driftstopp under uppgraderingar och tillhandahålla en återställningsväg om något går fel.

Nästa steg

En diskussion om designöverväganden för enskilda databaser och för elastiska pooler finns i Utforma ett program för haveriberedskap i molnet och Strategier för haveriberedskap för elastiska pooler.