Een back-up maken van SQL Server Always On-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.

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.

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 schema's komen in werking op alle AG-knooppunten en de workloadback-upextensies op deze knooppunten synchroniseren zich onderling 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 afbreekt, dat wil zeggen, de taak wordt overgeslagen.

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 logboek- of alleen-kopiëren-back-ups 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 AG te beschermen.
• 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).
• VM3 kan worden geregistreerd bij kluis 2 in abonnement 2, en de AG-databases worden vervolgens zichtbaar voor beveiliging in kluis 2. Door de afwezigheid van het primaire knooppunt in kluis 2, zal het configureren van back-ups echter mislukken.
• 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 afhandelen

Nadat de AG is overgeschakeld naar één van de secundaire knooppunten:

• De volledige en differentiële back-ups zullen doorgaan vanaf 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.

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.
• Omschakelen naar VM3 (in een ander abonnement)
  • Aangezien back-ups niet zijn geconfigureerd in Kluis 2, worden er geen back-ups uitgevoerd.
  • 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 en back-upfouten. Meer informatie hierover vindt u in Back-ups configureren voor een beschikbaarheidsgroep met meerdere regio's.
• Failover naar VM4 (in een andere regio)
  • Omdat backups niet zijn geconfigureerd in Kluis 4, worden er geen backups 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 en back-upfouten. Meer informatie hierover vindt u in Back-ups configureren voor een beschikbaarheidsgroep met meerdere regio's.

Back-ups configureren voor een beschikbaarheidsgroep (AG) 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 aan herstelpuntketens. Herstel van deze herstelpunten kan alleen worden uitgevoerd op VM’s die in die recovery vault zijn geregistreerd.

• Volledige en differentiële back-ups worden met succes alleen uitgevoerd in de kluis met het primaire knooppunt. Deze back-ups in andere opslagplaatsen 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.

  Opmerking

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

• Volledige alleen-kopieerback-ups werken in alle opslagkluizen.

• 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. Stel back-ups in 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 in staat is om deze back-up uit te voeren.
   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. Terugplaatsing van de beschikbaarheidsgroep naar de 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 er een onderbreking van de logboekketen plaatsvindt of 15 dagen zijn verstreken.

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 lopende taken zijn voltooid, zullen de wachtrijtaken worden 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 ongebalanceerde AG-knooppunten leiden tot problemen met de back-up synchronisatie. Om dit te begrijpen, overweeg bijvoorbeeld een AG met 2 knooppunten.

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 zou kunnen aannemen dat Knooppunt 1 offline is, en daarom worden taken van daar niet 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 AG met 2 knooppunten de back-upvoorkeur in op Alleen Primair of Secundair – dan kan slechts één knooppunt de back-ups verzorgen, terwijl de andere altijd zal uitvallen.
• Voor een AG met meer dan 2 knooppunten stel je de back-upvoorkeur in op 'Primair' – dan kan alleen het primaire knooppunt de back-ups uitvoeren, en de anderen zullen stoppen.

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 instantie. Overweeg de volgende implementatie:

De beveiligde exemplaren worden als volgt berekend:

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 databank gaan mislukken met foutcode: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

De database moet worden geconfigureerd voor bescherming onder de AG. Dit wordt behandeld als een nieuwe gegevensbron met een afzonderlijke keten van herstelpunten. De oudere beveiliging van een zelfstandige database kan worden gestopt met behoud van gegevens om te voorkomen dat toekomstige back-ups worden geactiveerd en kunnen mislukken. 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.

Toevoegen of verwijderen van een knooppunt aan een AG

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 deelnemen 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, bij knooppunttoevoeging, detecteren de workloadextensies in dit geval de wijziging van de AG-topologie 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 uitschrijving 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

Hercreatie van beschikbaarheidsgroep (AG), dubbele AG's, en de back-upitems worden weergegeven als beschermbare items of beschermde 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 behouden die al aanwezig zijn in de oudere beschikbaarheidsgroep (AG), gebruik dan de optie Beveiliging stoppen en gegevens behouden om de back-up te stoppen voordat u op de nieuwe AG-items back-ups opnieuw maakt en plant.

  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.

  Waarschuwing

  Beveiliging stoppen en gegevens verwijderen is een destructieve bewerking.

• U kunt de beschikbaarheidsgroep opnieuw creëren nadat u een van de bovenstaande stopbeveiligingsprocessen 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

Verwante inhoud

• Maak een back-up van SQL Server-databases in Azure-VM's met behulp van Azure Backup via REST API.
• Herstel SQL Server-databases in Azure VM's via de REST API.
• SQL Server-databases beheren in Azure-VM's met Azure Portal, Azure CLI, REST API.