Een back-up maken van SQL Server alwayson-beschikbaarheidsgroepen

Azure Backup biedt een end-to-end-ondersteuning voor het maken van back-ups van SQL Server alwayson-beschikbaarheidsgroepen (AG) als alle knooppunten zich in dezelfde regio en hetzelfde abonnement bevinden als de Recovery Services-kluis. Als de AG-knooppunten echter zijn verdeeld over regio's/abonnementen/on-premises en Azure, zijn er enkele overwegingen waarmee u rekening moet houden.

Notitie

• Back-up van databases van basic-beschikbaarheidsgroepen wordt niet ondersteund door Azure Backup.
• Zie de ondersteuningsmatrix voor SQL-back-ups voor meer informatie over de ondersteunde configuraties en scenario's.

De back-upvoorkeur die wordt gebruikt door Azure Backup SQL AG ondersteunt alleen volledige en differentiële back-ups van de primaire replica. Deze back-uptaken worden dus altijd uitgevoerd op het primaire knooppunt, ongeacht de back-upvoorkeur. Voor back-ups van volledige kopie- en transactielogboeken wordt de voorkeur voor ag-back-ups overwogen bij het bepalen van het knooppunt waarop de back-up wordt uitgevoerd.

Voorkeur voor AG-back-up	Volledige en diff-back-ups worden uitgevoerd op	Alleen kopiëren en logboekback-ups worden gemaakt van
Primair	Primaire replica	Primaire replica
Alleen secundair	Primaire replica	Een van de secundaire replica's
Voorkeur voor secundair	Primaire replica	Secundaire replica's hebben de voorkeur, maar back-ups kunnen ook worden uitgevoerd op primaire replica.
Geen/geen	Primaire replica	Elke replica

De workloadback-upextensie wordt op het knooppunt geïnstalleerd wanneer u deze registreert bij de Azure Backup-service. Wanneer een AG-database is geconfigureerd voor back-up, worden de back-upschema's gepusht naar alle geregistreerde knooppunten van de AG. De planningen worden geactiveerd op alle AG-knooppunten en de workloadback-upextensies op deze knooppunten worden gesynchroniseerd om te bepalen welk knooppunt de back-up kan uitvoeren. De knooppuntselectie is afhankelijk van het back-uptype en de back-upvoorkeur, zoals wordt uitgelegd in sectie 1.

Het geselecteerde knooppunt gaat verder met de back-uptaak, terwijl de taak die op de andere knooppunten wordt geactiveerd, wordt de taak overgeslagen.

Notitie

Azure Backup beschouwt geen back-upprioriteiten of replica's tijdens het kiezen tussen de secundaire replica's.

AG-knooppunten registreren bij de Recovery Services-kluis

Een Recovery Services-kluis ondersteunt alleen back-ups van databases van VM's in dezelfde regio en hetzelfde abonnement als van de kluis.

• Registreer het primaire knooppunt bij de kluis (anders kunnen volledige back-ups niet worden uitgevoerd).
• Registreer ten minste één secundair knooppunt bij de kluis (anders kunnen volledige back-ups voor logboeken/alleen-kopiëren niet worden uitgevoerd) als de back-upvoorkeur alleen secundair is.

Het configureren van back-ups voor AG-databases mislukt met de foutcode FabricSvcBackupPreferenceCheckFailedUserError als niet aan de bovenstaande voorwaarden wordt voldaan.

Laten we eens kijken naar de volgende AG-implementatie als referentie.

Op basis van de opgegeven voorbeeld-AG-implementatie zijn er verschillende overwegingen:

• Omdat het primaire knooppunt zich in regio 1 en abonnement 1 bevindt, moet de Recovery Services-kluis (Kluis 1) zich in regio 1 en abonnement 1 bevinden om deze beschikbaarheidsgroep te beveiligen.
• VM3 kan niet worden geregistreerd bij Kluis 1 omdat deze zich in een ander abonnement bevindt.
• VM4 kan niet worden geregistreerd bij Kluis 1 omdat deze zich in een andere regio bevindt.
• Als de back-upvoorkeur alleen secundair is, moeten VM1 (primair) en VM2 (secundair) worden geregistreerd bij kluis 1 (omdat voor volledige back-ups het primaire knooppunt en logboeken een secundair knooppunt vereist zijn). Voor andere back-upvoorkeuren moet VM1 (primair) worden geregistreerd bij Kluis 1, is VM2 optioneel (omdat alle back-ups op het primaire knooppunt kunnen worden uitgevoerd).
• Hoewel VM3 kan worden geregistreerd bij kluis 2 in abonnement 2 en de AG-databases vervolgens worden weergegeven voor beveiliging in kluis 2, maar vanwege afwezigheid van het primaire knooppunt in kluis 2, mislukt het configureren van back-ups.
• Op dezelfde manier kan VM4 worden geregistreerd bij kluis 4 in regio 2, waardoor het configureren van back-ups mislukt omdat het primaire knooppunt niet is geregistreerd in kluis 4.

Failover verwerken

Nadat de beschikbaarheidsgroep een failover heeft uitgevoerd naar een van de secundaire knooppunten:

• De volledige en differentiële back-ups blijven van het nieuwe primaire knooppunt als het is geregistreerd bij de kluis.
• De volledige back-ups voor logboeken en alleen-kopiëren worden voortgezet vanaf het primaire/secundaire knooppunt op basis van de back-upvoorkeur.

Notitie

Logboekketeneinden treden niet op bij failover als de failover niet samenvalt met een back-up.

Op basis van de bovenstaande voorbeeld-AG-implementatie zijn de volgende verschillende failovermogelijkheden:

• Failover naar VM2
  • Volledige en differentiële back-ups worden uitgevoerd vanaf VM2.
  • Volledige back-ups van logboeken en alleen-kopiëren vindt plaats van VM1 of VM2 op basis van de back-upvoorkeur.
• Failover naar VM3 (ander abonnement)
  • Omdat back-ups niet zijn geconfigureerd in Kluis 2, worden er geen back-ups gemaakt.
  • Als de voorkeur voor back-ups niet secundair is, kunnen back-ups nu worden geconfigureerd in Kluis 2, omdat het primaire knooppunt is geregistreerd in deze kluis. Dit kan echter leiden tot conflicten/back-upfouten. Meer informatie hierover vindt u in Back-ups configureren voor een beschikbaarheidsgroep met meerdere regio's.
• Failover naar VM4 (een andere regio)
  • Omdat back-ups niet zijn geconfigureerd in Kluis 4, worden er geen back-ups gemaakt.
  • Als de voorkeur voor back-ups niet secundair is, kunnen back-ups nu worden geconfigureerd in Kluis 4, omdat het primaire knooppunt is geregistreerd in deze kluis. Dit kan echter leiden tot conflicten/back-upfouten. Meer informatie hierover vindt u in Back-ups configureren voor een beschikbaarheidsgroep met meerdere regio's.

Back-ups configureren voor een beschikbaarheidsgroep met meerdere regio's

Recovery Services-kluis biedt geen ondersteuning voor back-ups tussen abonnementen of regio's. In deze sectie wordt beschreven hoe u back-ups kunt inschakelen voor AG's die betrekking hebben op abonnementen of Azure-regio's en de bijbehorende overwegingen.

• Evalueer of u back-ups van alle knooppunten echt moet inschakelen. Als één regio/abonnement de meeste AG-knooppunten heeft en failover naar andere knooppunten zelden plaatsvindt, kan het instellen van de back-up in die eerste regio voldoende zijn. Als de failovers naar andere regio's/abonnementen vaak en voor langere duur plaatsvinden, kunt u ook proactief back-ups instellen in de andere regio.

• Elke kluis waarvoor de back-up wordt ingeschakeld, heeft een eigen set herstelpuntketens. Herstelbewerkingen van deze herstelpunten kunnen alleen worden uitgevoerd op VM's die in die kluis zijn geregistreerd.

• Volledige/differentiële back-ups worden alleen uitgevoerd in de kluis met het primaire knooppunt. Deze back-ups in andere kluizen blijven mislukken.

• Logboekback-ups blijven in de vorige kluis werken totdat een logboekback-up wordt uitgevoerd in de nieuwe kluis (dat wil gezegd, in de kluis waar het nieuwe primaire knooppunt aanwezig is) en de logboekketen voor de oude kluis wordt verbroken.

  Notitie

  Er is een vaste limiet van 15 dagen na welke logboekback-ups mislukken.

• Volledige back-ups met alleen kopiëren werken in alle kluizen.

• Beveiliging in elke kluis wordt behandeld als een afzonderlijke gegevensbron en wordt afzonderlijk gefactureerd.

Als u back-upconflicten tussen de twee kluizen wilt voorkomen, wordt u aangeraden de back-upvoorkeur in te stellen op Primair. Als de kluis het primaire knooppunt heeft, worden ook de logboekback-ups gemaakt.

Op basis van de bovenstaande voorbeeld-AG-implementatie zijn dit de stappen voor het inschakelen van back-ups vanaf alle knooppunten. De veronderstelling is dat aan de back-upvoorkeur wordt voldaan in alle stappen.

Stap 1: Back-ups inschakelen in regio 1, abonnement 1 (kluis 1)

Omdat het primaire knooppunt zich in de regio en het abonnement bevindt, werken de gebruikelijke stappen om back-ups in te schakelen.

Stap 2: Back-ups inschakelen in regio 1, abonnement 2 (kluis 2)

1. Failover van de beschikbaarheidsgroep naar VM3, zodat het primaire knooppunt aanwezig is in Kluis 2.
2. Configureer back-ups voor de AG-databases in Kluis 2.
3. Op dit punt:
   1. De volledige/differentiële back-ups mislukken in Kluis 1 omdat geen van de geregistreerde knooppunten deze back-up kan maken.
   2. De logboekback-ups slagen in Kluis 1 totdat een logboekback-up wordt uitgevoerd in Kluis 2 en de logboekketen voor Kluis 1 wordt verbroken .
4. Failback van de beschikbaarheidsgroep naar VM1.

Stap 3: Back-ups inschakelen in regio 2, abonnement 1 (kluis 4)

Hetzelfde als stap 2.

Een back-up maken van een beschikbaarheidsgroep die Azure en on-premises omvat

Azure Backup voor SQL Server kan niet on-premises worden uitgevoerd. Als het primaire knooppunt zich in Azure bevindt en aan de back-upvoorkeur wordt voldaan door de knooppunten in Azure, kunt u de bovenstaande richtlijnen voor ag voor meerdere regio's volgen om back-ups voor de replica's in Azure in te schakelen. Als er een failover naar een on-premises knooppunt plaatsvindt, mislukken de volledige en differentiële back-ups in Azure. Logboekback-ups kunnen doorgaan totdat het logboekketenonderbreking plaatsvindt/15 dagen.

Beperking voor back-uptaken in een AG-database

Op dit moment zijn de beperkingslimieten voor back-ups van toepassing op het niveau van een afzonderlijke machine. De standaardlimiet is 20: als meer dan 20 back-ups gelijktijdig worden geactiveerd, wordt de eerste 20 uitgevoerd en worden de andere in de wachtrij geplaatst. Wanneer de actieve taken zijn voltooid, worden de in de wachtrij geplaatste taken uitgevoerd.

U kunt deze waarde wijzigen in een kleinere waarde als de gelijktijdige back-ups geheugen-/IO-/CPU-belasting op het knooppunt veroorzaken. Omdat de beperking zich op knooppuntniveau bevindt, kunnen niet-verdeelde AG-knooppunten leiden tot problemen met back-upsynchronisatie. Als u dit wilt begrijpen, kunt u bijvoorbeeld een beschikbaarheidsgroep van 2 knooppunten overwegen.

Het eerste knooppunt heeft bijvoorbeeld 50 zelfstandige databases beveiligd en beide knooppunten hebben 5 AG-databases beveiligd. In feite heeft Node 1 55 databaseback-uptaken gepland, terwijl Node 2 slechts 5 heeft. Bovendien zijn al deze back-ups geconfigureerd om elk uur tegelijkertijd te worden uitgevoerd. Op een punt worden alle 55 back-ups geactiveerd op Node 1 en 35 van deze worden in de wachtrij geplaatst. Sommige hiervan zijn de back-ups van de AG-database. Maar op Node 2 zouden de back-ups van de AG-database zonder wachtrijen verdergaan.

Omdat de AG-databasetaken in de wachtrij worden geplaatst op het ene knooppunt en worden uitgevoerd op een ander knooppunt, werkt de back-upsynchronisatie (vermeld in sectie 6) niet goed. Knooppunt 2 kan ervan uitgaan dat Node 1 niet beschikbaar is en daarom zijn er geen taken beschikbaar voor synchronisatie. Dit kan leiden tot onderbrekingen van logboekketens of extra back-ups, omdat beide knooppunten onafhankelijk back-ups kunnen maken.

Er kan een vergelijkbaar probleem optreden als het aantal beveiligde AG-databases groter is dan de beperkingslimiet. In dat geval kan een back-up voor bijvoorbeeld DB1 in de wachtrij worden geplaatst op knooppunt 1, terwijl deze wordt uitgevoerd op Node 2.

U wordt aangeraden de volgende back-upvoorkeuren te gebruiken om deze synchronisatieproblemen te voorkomen:

• Stel voor een beschikbaarheidsgroep van 2 knooppunten de back-upvoorkeur in op Alleen primaire of secundaire. Vervolgens kan slechts één knooppunt de back-ups uitvoeren, de andere zal altijd worden gered.
• Stel voor een AG met meer dan 2 knooppunten de back-upvoorkeur in op Primair. Vervolgens kan alleen het primaire knooppunt de back-ups uitvoeren.

Facturering voor AG-back-ups

Hetzelfde als een zelfstandig SQL-exemplaar, wordt één back-up van het AG-exemplaar beschouwd als één beveiligd exemplaar. Er worden kosten in rekening gebracht voor de totale front-endgrootte van alle beveiligde databases in een exemplaar. Overweeg de volgende implementatie:

De beveiligde exemplaren worden als volgt berekend:

Beveiligd exemplaar/factureringsexemplaren	Databases die worden overwogen voor het berekenen van de front-endgrootte
AG1	DB1, DB2
AG2	DB4
VM2	DB3
VM3	DB6
VM4	DB5

Een beveiligde database verplaatsen in of uit een beschikbaarheidsgroep

Azure Backup beschouwt sql-exemplaar of AG-naam\Databasenaam als de unieke naam van de database. Toen de zelfstandige database werd beveiligd, was de unieke naam StandAloneInstanceName\DBName. Wanneer deze onder een AG wordt verplaatst, verandert de unieke naam in AGName\DBName. De back-ups voor de zelfstandige database mislukken met foutcode: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

De database moet worden geconfigureerd voor beveiliging vanuit de beschikbaarheidsgroep. Dit wordt behandeld als een nieuwe gegevensbron met een afzonderlijke keten van herstelpunten. De oudere beveiliging van een zelfstandige database kan worden gestopt met behoudgegevens om te voorkomen dat toekomstige back-ups worden geactiveerd en mislukt. Als een beveiligde AG-database uit AG wordt verplaatst en een zelfstandige database wordt, mislukken de back-ups met foutcode: UserErrorBackupFailedDatabaseMovedOutOfAG.

De database moet worden geconfigureerd voor beveiliging vanaf het zelfstandige exemplaar. Dit wordt behandeld als een nieuwe gegevensbron met een afzonderlijke keten van herstelpunten. De oudere beveiliging van de AG-database kan worden gestopt met behoud van gegevens om te voorkomen dat toekomstige back-ups worden geactiveerd en mislukt.

Een knooppunt aan een ag toevoegen/verwijderen

Wanneer een nieuw knooppunt wordt toegevoegd aan een AG die is geconfigureerd voor back-ups, detecteren de back-upextensies van de workload die worden uitgevoerd op de reeds geregistreerde AG-knooppunten de wijziging van de AG-topologie en informeren de Azure Backup-service tijdens de volgende geplande databasedetectietaak. Wanneer dit nieuwe knooppunt wordt geregistreerd voor back-ups naar dezelfde Recovery Services-kluis als de andere bestaande knooppunten, activeert de Azure Backup-service een werkstroom waarmee dit nieuwe knooppunt wordt geconfigureerd met de benodigde metagegevens voor het uitvoeren van AG-back-ups.

Hierna synchroniseert het nieuwe knooppunt de informatie over het back-upschema van de AG van de Azure Backup-service en begint het deelnemen aan het gesynchroniseerde back-upproces. Als het nieuwe knooppunt de back-upschema's niet kan synchroniseren en deelneemt aan back-ups, dwingt het activeren van een herregistratie op het knooppunt ook de herconfiguratie van het knooppunt voor AG-back-ups af. Op dezelfde manier detecteren de workloadextensies de wijziging van de AG-topologie in dit geval en informeren ze de Azure Backup-service. De service start een werkstroom voor het ongedaan maken van de configuratie van knooppunten in het verwijderde knooppunt om de back-upschema's voor AG-databases te wissen en de gerelateerde metagegevens van de AG te verwijderen.

Het registreren van een AG-knooppunt bij Azure Backup ongedaan maken

Als een knooppunt deel uitmaakt van een beschikbaarheidsgroep met een of meer databases die zijn geconfigureerd voor back-up, staat Azure Backup de registratie van dat knooppunt niet toe. Dit is om toekomstige back-upfouten te voorkomen als niet kan worden voldaan aan de back-upvoorkeur zonder dit knooppunt. Als u de registratie van het knooppunt ongedaan wilt maken, moet u het eerst verwijderen uit de beschikbaarheidsgroep. Wanneer de werkstroom voor het opheffen van de configuratie van het knooppunt is voltooid, kunt u de registratie ervan ongedaan maken.

Het herstellen van een database vanuit Azure Backup naar een AG SQL-beschikbaarheidsgroepen biedt geen ondersteuning voor het rechtstreeks herstellen van een database in AG. De database moet worden hersteld naar een zelfstandig SQL-exemplaar en moet vervolgens worden gekoppeld aan een beschikbaarheidsgroep.

Scenario's voor het opnieuw maken van beschikbaarheidsgroepen voor de SQL-databaseserver

Opnieuw maken van beschikbaarheidsgroep (AG), dubbele AG's en de back-upitems worden weergegeven als beveiligbare items of beveiligde items in de volgende scenario's:

• Het opnieuw maken van AG's die al zijn beveiligd, worden weergegeven als dubbele AG's op de pagina Back-up configureren en in de lijst beveiligde items . Als u de back-upgegevens wilt bewaren die al aanwezig zijn in de oudere beschikbaarheidsgroep, stopt u de back-up met behulp van de optie Beveiliging stoppen en gegevens behouden voordat u back-ups opnieuw maakt en plant op de nieuwe AG-items.

  Azure Backup vermeldt standaard de dubbele items in de lijst met beveiligde items en de pagina Back-up configureren of de lijst met beveiligbare items en geeft deze items weer totdat u de back-upgegevens wilt behouden.

• Als u de back-upgegevens van de oudere beschikbaarheidsgroep niet wilt, stopt u de back-upbewerking met behulp van de optie Beveiliging stoppen en gegevens verwijderen voor het oudere item voordat u back-ups opnieuw maakt en plant op de nieuwe beschikbaarheidsgroep.

  Let op

  Beveiliging stoppen en gegevens verwijderen is een destructieve bewerking.

• U kunt de beschikbaarheidsgroep opnieuw maken nadat u een van de bovenstaande stopbeveiligingsprocesen hebt uitgevoerd om back-upfouten te voorkomen.

Volgende stappen

Leer hoe u het volgende doet:

• Back-up van SQL Server-databases herstellen
• Back-up van SQL Server-databases beheren