Säkerhetskopiera SQL Server alltid i tillgänglighetsgrupper

Azure Backup erbjuder helhetsstöd för säkerhetskopiering av SQL Server Always On-tilgänglighetsgrupper (AG) om alla noder finns i samma region och prenumeration som återställningstjänstvalvet. Men om AG noderna är spridda över regioner, prenumerationer, lokalt och Azure, finns det flera viktiga aspekter att beakta.

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 endast fullständiga och transaktionsloggar beaktas inställningen för säkerhetskopiering av tillgänglighetsgruppen vid beslut om vilken nod som säkerhetskopieringen ska köras på.

Tillägget för säkerhetskopiering av arbetsbelastningar installeras på noden när du registrerar det 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 arbetet på dessa noder synkroniseras 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.

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 i valvet.

• Registrera den primära noden i valvet (annars kan fullständiga säkerhetskopieringar inte ske).
• Registrera minst en sekundär nod i valvet (annars kan logg-/kopieringsbefriade fullständiga säkerhetskopior inte ske) om säkerhetskopieringsinställningen endast är sekundär.

Det går inte att konfigurera säkerhetskopieringar för AG-databaser med felkoden FabricSvcBackupPreferenceCheckFailedUserError om ovanstående villkor inte uppfylls.

Låt oss betrakta följande tillgänglighetsgruppsimplementering som en referens.

Baserat på den angivna driftsättningen av tillgänglighetsgrupp, behöver följande aspekter övervägas:

• 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 det finns i en annan prenumeration.
• VM4 kan inte registreras i Valv 1 eftersom det 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).
• Medan VM3 kunde registreras i valv 2 i prenumeration 2, och tillgänglighetsgruppens databaser sedan skulle visas för skydd i valv 2, misslyckas konfigureringen av säkerhetskopior på grund av att den primära noden saknas i valv 2.
• Ä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 övergång

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.

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 kopieringsbara fullständiga säkerhetskopior kommer att ske från VM1 eller VM2 baserat på säkerhetskopieringspreferens.
• Övergång till VM3 (en annan abonnemang)
  • 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 i 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 i 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 failover till andra regioner eller abonnemang sker ofta och under längre perioder, kan det vara en bra idé att proaktivt konfigurera säkerhetskopieringar ä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 eller differentiella säkerhetskopior kan endast utföras i valvet som har den primära noden. Dessa säkerhetskopior i andra valv kommer fortsätta att misslyckas.

• Loggsäkerhetskopior fortsätter att fungera i föregående valv 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.

  Anmärkning

  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. Då kommer det valvet som har den primära noden även att ta 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. Flytta över tillgänglighetsgruppen till VM3 så att den primära noden ska finnas 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. Återväxla AG 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 avbrott i loggkedjan sker/15 dagar har passerat.

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

Begränsningarna för säkerhetskopiering gäller för närvarande för varje enskild dator. 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äkerhetskopieringen av AG-databasen fortsätta utan väntetider.

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 fler ä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äkerhetskopieringspreferens på Primär – sedan kan endast den primära noden göra säkerhetskopiorna, andra kommer inte att delta.

Fakturering av AG-säkerhetskopior

Samma som en fristående SQL-instans, betraktas en säkerhetskopierad AG-instans som en skyddad instans. Den totala gränssnittsstorleken för alla skyddade databaser i en instans debiteras. Överväg följande distribution:

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

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 AG ä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 förhindras genom att bibehålla data för att undvika att framtida säkerhetskopior utlöses och misslyckas vid dessa. När en skyddad AG-databas flyttas ut ur AG och blir en fristående databas, börjar säkerhetskopiorna misslyckas med felkoden UserErrorBackupFailedDatabaseMovedOutOfAG.

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 genom att bevara data för att undvika att framtida säkerhetskopior utlöses och misslyckas på den.

Tillägg/borttagning av en nod i 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, vid tillägg av en nod, upptäcker arbetsbelastningstilläggen ändringen av topologin i tillgänglighetsgruppen 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. För att avregistrera noden måste du först ta bort den från AG:n. När nodens avkonfigurationsarbetsflöde har slutförts och rensar noden kan du avregistrera den.

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

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.

  Försiktighet

  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

Relaterat innehåll

• Säkerhetskopiera SQL Server-databaser på virtuella Azure-datorer med Hjälp av Azure Backup via REST API.
• Återställa SQL Server-databaser på virtuella Azure-datorer med REST API.
• Hantera SQL Server-databaser på virtuella Azure-datorer med Azure-portalen, Azure CLI, REST API.