Säkerhetskopiera SQL Server alltid i tillgänglighetsgrupper

Azure Backup har stöd från slutpunkt till slutpunkt för säkerhetskopiering av SQL Server alltid på tillgänglighetsgrupper (AG) om alla noder finns i samma region och prenumeration som Recovery Services-valvet. Men om tillgänglighetsgruppens noder är spridda över regioner/prenumerationer/lokalt och Azure finns det några saker att tänka på.

Kommentar

• Säkerhetskopiering av databaser för grundläggande tillgänglighetsgrupp stöds inte av Azure Backup.
• Mer information om konfigurationer och scenarier som stöds finns i stödmatrisen för SQL-säkerhetskopiering.

Säkerhetskopieringsinställningen som används av Azure Backup SQL AG stöder endast fullständiga och differentiella säkerhetskopieringar från den primära repliken. De här säkerhetskopieringsjobben körs därför alltid på den primära noden oavsett säkerhetskopieringsinställningen. För säkerhetskopior av fullständiga och transaktionsloggar beaktas inställningen för säkerhetskopiering av tillgänglighetsgruppen när du bestämmer vilken nod som säkerhetskopieringen ska köras på.

Inställningar för tillgänglighetssäkerhetskopiering	Fullständiga säkerhetskopieringar och Diff-säkerhetskopieringar körs på	Kopierings- och loggsäkerhetskopior hämtas från
Primär	Primär replik	Primär replik
Endast sekundär	Primär replik	Någon av de sekundära replikerna
Föredrar sekundär	Primär replik	Sekundära repliker är att föredra, men säkerhetskopieringar kan också köras på den primära repliken.
Ingen/alla	Primär replik	Valfri replik

Tillägget för säkerhetskopiering av arbetsbelastning installeras på noden när det registreras med Azure Backup-tjänsten. När en tillgänglighetsgruppsdatabas har konfigurerats för säkerhetskopiering skickas scheman för säkerhetskopiering till alla registrerade noder i tillgänglighetsgruppen. Scheman utlöses på alla AG-noder och tilläggen för säkerhetskopiering av arbetsbelastningar på dessa noder synkroniseras mellan dem för att avgöra vilken nod som ska utföra säkerhetskopieringen. Valet av nod beror på säkerhetskopieringstypen och säkerhetskopieringsinställningen enligt beskrivningen i avsnitt 1.

Den valda noden fortsätter med säkerhetskopieringsjobbet, medan jobbet som utlöses på de andra noderna hoppar över jobbet.

Kommentar

Azure Backup överväger inte säkerhetskopieringsprioriteringar eller repliker när du bestämmer dig för de sekundära replikerna.

Registrera AG-noder i Recovery Services-valvet

Ett Recovery Services-valv stöder endast säkerhetskopiering av databaser från virtuella datorer i samma region och prenumeration som valvets.

• Du måste registrera den primära noden i valvet (annars kan fullständiga säkerhetskopieringar inte ske).
• Om säkerhetskopieringsinställningen endast är sekundär måste du registrera minst en sekundär nod i valvet (annars kan inte fullständiga säkerhetskopieringar endast logga/kopieras).

Konfigurationen av säkerhetskopior för AG-databaser misslyckas med felkoden FabricSvcBackupPreferenceCheckFailedUserError om ovanstående villkor inte uppfylls.

Nu ska vi betrakta följande tillgänglighetsgruppsdistribution som en referens.

Baserat på ovanstående exempel på ag-distribution är följande olika överväganden:

• Eftersom den primära noden finns i region 1 och prenumeration 1 måste Recovery Services-valvet (Valv 1) finnas i region 1 och prenumeration 1 för att skydda den här tillgänglighetsgruppen.
• VM3 kan inte registreras i Valv 1 eftersom den finns i en annan prenumeration.
• VM4 kan inte registreras i Valv 1 eftersom den finns i en annan region.
• Om säkerhetskopieringsinställningen endast är sekundär måste VM1 (primär) och VM2 (sekundär) registreras i Valv 1 (eftersom fullständiga säkerhetskopior kräver den primära noden och loggarna kräver en sekundär nod). För andra säkerhetskopieringsinställningar måste VM1 (primär) registreras till Valv 1, VM2 är valfritt (eftersom alla säkerhetskopior kan köras på den primära noden).
• Även om VM3 kunde registreras i valv 2 i prenumeration 2 och tillgänglighetsgruppens databaser sedan skulle visas för skydd i valv 2, men på grund av avsaknad av den primära noden i valv 2 misslyckas konfigurationen av säkerhetskopior.
• Även om VM4 kan registreras i valv 4 i region 2 skulle konfigurationen av säkerhetskopior misslyckas eftersom den primära noden inte är registrerad i valv 4.

Hantera redundans

När tillgänglighetsgruppen har växlat över till en av de sekundära noderna:

• De fullständiga och differentiella säkerhetskopiorna fortsätter från den nya primära noden om den är registrerad i valvet.
• Logg- och kopieringssäkerhetskopiorna fortsätter från den primära/sekundära noden baserat på säkerhetskopieringsinställningen.

Kommentar

Loggkedjebrytningar sker inte vid redundansväxling om redundansväxlingen inte sammanfaller med en säkerhetskopia.

Baserat på ovanstående exempel på ag-distribution är följande de olika redundansmöjligheterna:

• Redundansväxling till VM2
  • Fullständiga och differentiella säkerhetskopieringar sker från VM2.
  • Logg- och kopieringssäkerhetskopior sker från VM1 eller VM2 baserat på säkerhetskopieringsinställningar.
• Redundansväxling till VM3 (en annan prenumeration)
  • Eftersom säkerhetskopior inte konfigureras i Valv 2 sker inga säkerhetskopior.
  • Om säkerhetskopieringsinställningen inte är sekundär kan säkerhetskopieringar nu konfigureras i Valv 2, eftersom den primära noden är registrerad i det här valvet. Men detta kan leda till konflikter/säkerhetskopieringsfel. Mer information om detta finns i Konfigurera säkerhetskopior för en tillgänglighetsgrupp för flera regioner.
• Redundansväxling till VM4 (en annan region)
  • Eftersom säkerhetskopior inte har konfigurerats i Valv 4 sker inga säkerhetskopior.
  • Om säkerhetskopieringsinställningen inte är sekundär kan säkerhetskopieringar nu konfigureras i Valv 4, eftersom den primära noden är registrerad i det här valvet. Men detta kan leda till konflikter/säkerhetskopieringsfel. Mer information om detta finns i Konfigurera säkerhetskopior för en tillgänglighetsgrupp för flera regioner.

Konfigurera säkerhetskopior för en tillgänglighetsgrupp för flera regioner

Recovery Services-valv stöder inte säkerhetskopieringar mellan prenumerationer eller regioner. I det här avsnittet sammanfattas hur du aktiverar säkerhetskopieringar för AG:er som omfattar prenumerationer eller Azure-regioner och tillhörande överväganden.

• Utvärdera om du verkligen behöver aktivera säkerhetskopieringar från alla noder. Om en region/prenumeration har de flesta ag-noder och redundansväxling till andra noder sker mycket sällan, kan det räcka med att konfigurera säkerhetskopieringen i den första regionen. Om redundansväxlingarna till annan region/prenumeration sker ofta och under en längre tid kanske du vill konfigurera säkerhetskopieringar proaktivt även i den andra regionen.

• Varje valv där säkerhetskopieringen aktiveras har en egen uppsättning återställningspunktskedjor. Återställningar från dessa återställningspunkter kan endast göras till virtuella datorer som är registrerade i valvet.

• Fullständiga/differentiella säkerhetskopieringar sker endast i valvet som har den primära noden. Dessa säkerhetskopior i andra valv misslyckas.

• Loggsäkerhetskopior fortsätter att fungera i det tidigare valvet tills en loggsäkerhetskopia körs i det nya valvet (dvs. i valvet där den nya primära noden finns) och bryter loggkedjan för det gamla valvet.

  Kommentar

  Det finns en hård gräns på 15 dagar efter vilken loggsäkerhetskopieringar börjar misslyckas.

• Fullständiga säkerhetskopior med endast kopiering fungerar i alla valv.

• Skyddet i varje valv behandlas som en distinkt datakälla och faktureras separat.

För att undvika loggsäkerhetskopieringskonflikter mellan de två valven rekommenderar vi att du ställer in säkerhetskopieringsinställningen på Primär. Beroende på vilket valv som har den primära noden tar du även loggsäkerhetskopiorna.

Här är stegen för att aktivera säkerhetskopiering från alla noder baserat på ovanstående exempel på ag-distribution. Antagandet är att säkerhetskopieringsinställningen uppfylls i alla steg.

Steg 1: Aktivera säkerhetskopior i region 1, prenumeration 1 (valv 1)

Eftersom den primära noden finns i region och prenumeration fungerar de vanliga stegen för att aktivera säkerhetskopieringar.

Steg 2: Aktivera säkerhetskopieringar i region 1, prenumeration 2 (valv 2)

1. Redundansväxlar tillgänglighetsgruppen till VM3 så att den primära noden finns i Valv 2.
2. Konfigurera säkerhetskopior för tillgänglighetsgruppens databaser i Valv 2.
3. I det här läget:
   1. De fullständiga/differentiella säkerhetskopiorna misslyckas i Valv 1 eftersom ingen av de registrerade noderna kan ta den här säkerhetskopian.
   2. Loggsäkerhetskopiorna lyckas i Valv 1 tills en loggsäkerhetskopia körs i Valv 2 och bryter loggkedjan för Vault 1.
4. Återställ tillgänglighetsgruppen till VM1.

Steg 3: Aktivera säkerhetskopior i region 2, prenumeration 1 (valv 4)

Samma som steg 2.

Säkerhetskopiera en tillgänglighetsgrupp som sträcker sig över Azure och lokalt

Azure Backup för SQL Server kan inte köras lokalt. Om den primära noden finns i Azure och säkerhetskopieringsinställningen uppfylls av noderna i Azure kan du följa ovanstående riktlinjer för tillgänglighetsgruppen för flera regioner för att aktivera säkerhetskopieringar för replikerna i Azure. Om en redundansväxling till en lokal nod sker börjar de fullständiga och differentiella säkerhetskopiorna i Azure att misslyckas. Loggsäkerhetskopior kan fortsätta tills loggkedjebrytningen sker/15 dagar går.

Begränsning för säkerhetskopieringsjobb i en tillgänglighetsgruppsdatabas

Begränsningarna för säkerhetskopiering gäller för närvarande på en enskild datornivå. Standardgränsen är 20 – om fler än 20 säkerhetskopior utlöses samtidigt körs de första 20 och de andra placeras i kö. När jobben som körs är klara börjar de köade jobben att köras.

Du kan ändra det här värdet till ett mindre värde om de samtidiga säkerhetskopiorna orsakar minnes-/I/O-/CPU-belastning på noden. Eftersom begränsningen är på nodnivå kan obalanserade AG-noder leda till problem med säkerhetskopieringssynkronisering. För att förstå detta bör du till exempel överväga en tillgänglighetsgrupp på 2 noder.

Den första noden har till exempel 50 fristående databaser skyddade och båda noderna har 5 AG-databaser skyddade. I själva verket har Nod 1 55 databassäkerhetskopieringsjobb schemalagda medan Nod 2 bara har 5. Dessutom är alla dessa säkerhetskopior konfigurerade att köras samtidigt, varje timme. Vid ett tillfälle utlöses alla 55 säkerhetskopior på nod 1 och 35 av dessa placeras i kö. Några av dessa skulle vara säkerhetskopior av tillgänglighetsgruppens databas. Men på nod 2 skulle säkerhetskopiorna av tillgänglighetsgruppens databas fortsätta utan köer.

Eftersom ag-databasjobben placeras i kö på en nod och körs på en annan fungerar inte synkroniseringen av säkerhetskopian (som nämns i avsnitt 6) korrekt. Nod 2 kan anta att Nod 1 är nere och därför kommer inte jobb därifrån för synkronisering. Detta kan leda till loggkedjebrytningar eller extra säkerhetskopior eftersom båda noderna kan göra säkerhetskopior separat.

Liknande problem kan inträffa om antalet ag-databaser som skyddas är mer än begränsningsgränsen. I sådana fall kan säkerhetskopiering för till exempel DB1 placeras i kö på nod 1 medan den körs på nod 2.

Vi rekommenderar att du använder följande säkerhetskopieringsinställningar för att undvika dessa synkroniseringsproblem:

• För en tillgänglighetsgrupp på 2 noder ställer du in säkerhetskopieringsinställningen på Endast primär eller Sekundär – sedan kan bara en nod göra säkerhetskopiorna, den andra löser alltid ut.
• För en tillgänglighetsgrupp med fler än 2 noder ställer du in säkerhetskopieringsinställningen på Primär – sedan kan endast den primära noden göra säkerhetskopiorna, andra löser ut.

Fakturering för säkerhetskopior av tillgänglighetsgruppen

Samma som en fristående SQL-instans betraktas en säkerhetskopierad tillgänglighetsgruppsinstans som en skyddad instans. Total klientdelsstorlek för alla skyddade databaser i en instans debiteras. Överväg följande distribution:

De skyddade instanserna beräknas på följande sätt:

Skyddad instans/faktureringsinstans	Databaser som övervägs för beräkning av klientdelsstorlek
AG1	DB1, DB2
TILLGÄNGLIGHETSGRUPP 2	DB4
VM2	DB3
VM3	DB6
VM4	DB5

Flytta en skyddad databas till eller från en tillgänglighetsgrupp

Azure Backup betraktar SQL-instansen eller tillgänglighetsgruppens namn\Databasnamn som databasens unika namn. När den fristående databasen skyddades var dess unika namn StandAloneInstanceName\DBName. När den flyttas under en tillgänglighetsgrupp ändras det unika namnet till AGName\DBName. Säkerhetskopiorna för den fristående databasen börjar misslyckas med felkoden: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Databasen måste konfigureras för skydd från under tillgänglighetsgruppen. Detta behandlas som en ny datakälla med en separat återställningspunktkedja. Det äldre skyddet av fristående databas kan stoppas med kvarhållningsdata för att undvika att framtida säkerhetskopior utlöses och misslyckas på den. På samma sätt börjar säkerhetskopiorna misslyckas med felkoden UserErrorBackupFailedDatabaseMovedOutOfAG när en skyddad ag-databas flyttas från tillgänglighetsgruppen och blir fristående databas.

Databasen måste konfigureras för skydd från under den fristående instansen. Detta behandlas som en ny datakälla med en separat återställningspunktkedja. Det äldre skyddet av AG-databasen kan stoppas med kvarhållningsdata för att undvika att framtida säkerhetskopior utlöses och misslyckas på den.

Tillägg/borttagning av en nod till en tillgänglighetsgrupp

När en ny nod läggs till i en tillgänglighetsgrupp som har konfigurerats för säkerhetskopior identifierar tilläggen för säkerhetskopiering av arbetsbelastningar som körs på de redan registrerade tillgänglighetsgruppen ändringen av tillgänglighetsgruppens topologi och informerar Azure Backup-tjänsten under nästa schemalagda databasidentifieringsjobb. När den nya noden registreras för säkerhetskopior till samma Recovery Services-valv som de andra befintliga noderna utlöser Azure Backup-tjänsten ett arbetsflöde som konfigurerar den nya noden med nödvändiga metadata för att utföra ag-säkerhetskopieringar.

Därefter synkroniserar den nya noden schemainformationen för tillgänglighetsgruppens säkerhetskopiering från Azure Backup-tjänsten och börjar delta i den synkroniserade säkerhetskopieringsprocessen. Om den nya noden inte kan synkronisera säkerhetskopieringsscheman och delta i säkerhetskopieringar, tvingar utlösande av en omregistrering på noden omkonfiguration av noden även för tillgänglighetsgruppens säkerhetskopior. På samma sätt identifierar arbetsbelastningstilläggen ändring av tillgänglighetsgruppens topologi i det här fallet och informerar Azure Backup-tjänsten. Tjänsten startar ett nod-avkonfigurationsarbetsflöde i den borttagna noden för att rensa säkerhetskopieringsscheman för AG-databaser och ta bort ag-relaterade metadata.

Avregistrera en tillgänglighetsgruppsnod från Azure Backup

Om en nod är en del av en tillgänglighetsgrupp som har en eller flera databaser konfigurerade för säkerhetskopiering tillåter Inte Azure Backup avregistrering av noden. Detta för att förhindra framtida säkerhetskopieringsfel om säkerhetskopieringsinställningen inte kan uppfyllas utan den här noden. Om du vill avregistrera noden måste du först ta bort den från tillgänglighetsgruppen. När nodens avkonfigurationsarbetsflöde har slutförts och rensar noden kan du avregistrera den.

Återställning av en databas från Azure Backup till tillgänglighetsgrupper för tillgänglighetsgrupper för tillgänglighetsgrupper i tillgänglighetsgruppen stöder inte direkt återställning av en databas till tillgänglighetsgruppen. Databasen måste återställas till en fristående SQL-instans och måste sedan anslutas till en tillgänglighetsgrupp.

Scenarier för återskapande av tillgänglighetsgrupp för SQL-databasservern

Återskapande av tillgänglighetsgrupp (AG), duplicerade AG:er och säkerhetskopieringsobjekt visas som skyddsbara objekt eller skyddade objekt i följande scenarier:

• Återskapande av AG:er som redan är skyddade visas som duplicerade AG:er på sidan Konfigurera säkerhetskopiering och i listan Skyddade objekt . Om du vill behålla de säkerhetskopierade data som redan finns i den äldre tillgänglighetsgruppen stoppar du säkerhetskopieringen med hjälp av alternativet Stoppa skydd och behåller data innan du återskapar och schemalägger säkerhetskopieringar på de nya tillgänglighetsgruppens objekt.

  Azure Backup listar avsiktligt de duplicerade objekten i listan Skyddade objekt och sidan Konfigurera säkerhetskopiering eller Listan över skyddsbara objekt och visar dessa objekt tills du vill behålla säkerhetskopieringsdata.

• Om du inte vill ha säkerhetskopierade data från den äldre tillgänglighetsgruppen stoppar du säkerhetskopieringsåtgärden med hjälp av alternativet Stoppa skydd och ta bort data för det äldre objektet innan du skapar och schemalägger säkerhetskopieringar på den nya tillgänglighetsgruppen igen.

  Varning

  Att stoppa skyddet och ta bort data är en destruktiv åtgärd.

• Du kan återskapa tillgänglighetsgruppen efter att ha utfört någon av ovanstående stoppskyddsprocess för att undvika säkerhetskopieringsfel.

Nästa steg

Lär dig att:

• Återställa säkerhetskopierade SQL Server-databaser
• Hantera säkerhetskopierade SQL Server-databaser