Betrouwbaarheid in Azure Backup

Azure Backup is een ingebouwde Azure-service die cloud- en on-premises workloads veilig beveiligt. Azure Backup kan de beveiliging naadloos schalen voor meerdere workloads en biedt systeemeigen integratie met Azure workloads, waaronder virtuele machines (VM's), SAP HANA in Azure VM, SQL in Azure VM's, Azure Files, Azure Blob, Azure Data Lake, schijven, elastische SAN-volumes, AKS en meer. U hoeft geen automatisering of infrastructuur te beheren. U hoeft geen scripts te schrijven of opslag in te richten.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe Azure Backup veerkrachtig kan zijn tegen verschillende mogelijke storingen en problemen, zoals tijdelijke fouten, uitval van beschikbaarheidszones en uitval van regio's. Ook wordt enkel belangrijke informatie over de SLA (Service Level Agreement) van Azure Backup belicht.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Voor de back-up van uw productieworkloads raden we u aan om uw kluis als volgt te configureren:

In de resterende secties van dit artikel vindt u meer informatie over deze configuraties.

Zie Backup van cloud- en on-premises workloads naar cloud voor een lijst met andere aanbevelingen voor Azure Backup, waaronder aanbevelingen op basis van betrouwbaarheid.

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

Azure Backup kunt een back-up maken van verschillende datasources. U configureert back-ups anders, afhankelijk van de gegevensbron waarmee u werkt. Algemene gegevensbronnen zijn onder andere:

• Azure virtuele machines (VM's)
• Verschillende databases
• Azure Blob-accounts
• AKS-clusters
• On-premises servers door middel van de MARS-agent (Microsoft Azure Recovery Services)

Azure Backup slaat uw back-upgegevens op in vaults. Een kluis is een onlineopslagentiteit in Azure die wordt gebruikt voor het opslaan van gegevens, zoals back-upkopieën, herstelpunten en back-upbeleid. Er zijn twee typen kluizen: Recovery Services-kluizen en Backup-kluizen. U kunt een of beide typen kluis gebruiken, afhankelijk van wat u wilt beschermen. Zie Welke verschillende kluizen worden ondersteund voor back-up en herstel? om een lijst van de gegevensbronnen te bekijken die elk type kluis ondersteunt.

Taken vertegenwoordigen de activiteit van het maken van back-ups of het herstellen van uw gegevens. Back-uptaken omvatten geplande of *on-demand* bewerkingen voor het kopiëren van uw gegevens van de bron naar de kluis. Hersteltaken omvatten bewerkingen waarmee uw gegevens worden hersteld van back-upopslag naar een doellocatie. Elke taak heeft een unieke id en statustracering, zodat u de voortgang kunt bewaken en eventuele problemen kunt oplossen die zich voordoen tijdens back-up- en herstelbewerkingen. U maakt ook back-up beleidsregels die zijn gekoppeld aan werktaken. Beleidsregels geven configuratie op, zoals het back-upschema en hoe lang u gegevens wilt bewaren.

Vaults slaan uw back-upbeleid en configuratie op, en ze slaan ook metagegevens op over taken, wat het bijhouden en oplossen van problemen mogelijk maakt.

Fysieke architectuur

De kerninfrastructuur Azure Backup service wordt beheerd door Microsoft. Deze infrastructuur is verantwoordelijk voor het beheer en de werking van de service, waaronder het activeren en bewaken van taken.

De Azure Backup-service bewaart back-ups in de kluis. Kluizen zijn gebouwd op Azure Storage. Kluizen repliceren automatisch uw back-upgegevens en de duurzaamheid en tolerantie van de back-up zijn afhankelijk van de opslagredundantie van de kluis:

• Lokaal redundante opslag (LRS) repliceert de gegevens in uw opslagruimte naar een of meer Azure Availability Zones die zich in de primaire regio van uw keuze bevinden. Hoewel er geen optie is om de gewenste beschikbaarheidszone te kiezen, kan Azure LRS-accounts verplaatsen of uitbreiden tussen zones om de taakverdeling te verbeteren. Er is geen garantie dat uw gegevens worden verspreid over zones. Zie Wat zijn Beschikbaarheidszones? voor meer informatie over availability zones.

• Zone-redundante opslag (ZRS) en geografisch redundante opslag (GRS) bieden extra beveiliging. In dit artikel worden deze opties uitgebreid beschreven.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Wanneer u Azure Backup gebruikt, zijn zowel back-up- als herstelwerkstromen bestand tegen onregelmatige fouten. De service probeert automatisch opnieuw wanneer er tijdelijke netwerkfouten of tijdelijke serviceonderbrekingen optreden. U configureert geen logica voor opnieuw proberen. Als u herhaalde fouten ondervindt, raadpleegt u de documentatie voor probleemoplossing.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen een Azure regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure Backup beheert de configuratie van de beschikbaarheidszone van de service en voor uw gegevens afzonderlijk.

• Service: De Azure Backup-service zelf is automatisch zonebestendig in ondersteunde regio's, zonder dat u hiervoor actie hoeft te ondernemen. Deze ingebouwde zonetolerantie is echter niet van toepassing op uw back-upgegevens.

• Redundantie van back-upopslag: Selecteer het gewenste redundantieniveau voor uw back-upgegevens door uw Recovery Services-kluis of Backup-kluis te configureren. Als u zone-redundante opslag (ZRS) selecteert, worden kopieën van uw back-upgegevens automatisch opgeslagen in meerdere beschikbaarheidszones in de Azure regio die u gebruikt.

  Als u geen ZRS gebruikt, worden uw back-upgegevens beschouwd als niet-zonegebonden en kunnen ze worden opgeslagen in een zone. Als er een zone in de regio een probleem heeft, zijn niet-zonegebonden back-upgegevens mogelijk niet beschikbaar.

Requirements

• Regioondersteuning: De service is automatisch zonebestendig in alle regio's met beschikbaarheidszones. ZRS-kluizen worden ondersteund in dezelfde regio's.

• Alleen nieuwe kluizen: Configureer ZRS op uw kluis vóór de eerste back-up.

Kosten

Wanneer u zone-redundante opslag (ZRS) inschakelt voor uw back-ups, worden er kosten in rekening gebracht tegen een ander tarief dan lokaal redundante opslag (LRS) vanwege de extra replicatie- en opslagoverhead. Zie Azure Backup prijzen voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

• Maak een nieuwe kluis die gebruikmaakt van ZRS: Wanneer u een kluis maakt, moet u ook de opslagredundantie configureren. De stappen die u volgt, verschillen, afhankelijk van het type kluis. Voor meer informatie, zie:

  • Back-upkluizen aanmaken en verwijderen
  • Een Recovery Services-kluis maken en configureren

• ZRS configureren voor bestaande kluizen: Voor Back-upkluizen configureert u opslagredundantie wanneer u de kluis maakt. Zodra een Backup-kluis is gemaakt, is de configuratie vergrendeld en niet meer aanpasbaar.

  Voor Recovery Services-kluizen moet opslagredundantie worden geconfigureerd voordat u workloads beveiligt. Zodra een workload is beveiligd, is de instelling vergrendeld en kan deze niet meer worden gewijzigd.

  U kunt een nieuwe kluis maken die is geconfigureerd voor het gebruik van ZRS en uw workloads opnieuw toewijzen aan de nieuwe kluis. Voor deze aanpak is echter downtime vereist. Zie Een Recovery Services-kluis maken en configureren - Standaardinstellingen wijzigen](/azure/backup/backup-create-recovery-services-vault#modify-default-settings) voor meer informatie. U bent ook verantwoordelijk voor het handmatig verwijderen van alle bestaande herstelpunten en andere gegevens, omdat het bewaarbeleid van de oude kluis niet langer van toepassing is. Zie Een Back-upkluis verwijderen of Een Recovery Services-kluis verwijderen voor meer informatie over het verwijderen van een kluis.

Gedrag wanneer alle zones in orde zijn

Wanneer kluizen zone-redundante opslag gebruiken en alle beschikbaarheidszones operationeel zijn, verwacht u het volgende:

• Bewerking tussen zones: Back-uptaken worden uitgevoerd op infrastructuur die wordt gerepliceerd in meerdere zones. Azure beheert taken van infrastructuur in elke zone.

• Replicatie van gegevens in meerdere zones: ZRS repliceert back-ups van gegevens in verschillende zones. Replicatie vindt synchroon plaats, wat betekent dat meerdere zones elke schrijfbewerking bevestigen voordat deze is voltooid.

Gedrag tijdens een zonefout

Wanneer kluizen zijn geconfigureerd voor het gebruik van zone-redundante opslag en er een storing in de beschikbaarheidszone optreedt, verwacht u het volgende:

• Detection and response: Voor de Azure Backup-service zelf is Microsoft verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone en reageert. U hoeft niets te doen om een zonefailover te starten.

  Belangrijk

  Voor alle gegevens of resources die niet beschikbaar zijn vanwege de zonestoring, bent u verantwoordelijk voor het detecteren van de storing en het uitvoeren van herstelacties, waaronder het herstellen van back-ups naar een gezonde zone.

• Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt echter Azure Resource Health gebruiken om de status van een afzonderlijke resource te controleren en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt ook Azure Service Health gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Servicestatuswaarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Het gedrag van actieve jobs hangt af van welke zone is mislukt.

  • Voor gegevensbronnen in de mislukte beschikbaarheidszone zijn de gegevensbronnen waarschijnlijk niet beschikbaar vanwege de zonefout. Actieve taken kunnen worden onderbroken of mislukken.
  • Voor alle gegevensbronnen in gezonde beschikbaarheidszones die actieve taken uitvoeren, kan een kleine hoeveelheid downtime, meestal een paar seconden, optreden terwijl het platform overschakelt naar het gebruik van gezonde beschikbaarheidszones voor de Azure Backup-service.

• Verwachte gegevensverlies: De hoeveelheid gegevensverlies die u kunt verwachten, wordt ook wel het beoogde herstelpunt (RPO) genoemd. De RPO voor uw back-upgegevens is afhankelijk van meerdere factoren, waaronder uw back-upschema. Over het algemeen wordt voor een zonestoring geen verlies van back-upgegevens verwacht omdat alle gegevens synchroon worden gerepliceerd tussen zones.

• Verwachte downtime: De hoeveelheid downtime die u kunt verwachten, wordt ook wel de beoogde hersteltijd (RTO) genoemd. De RTO verschilt voor elk van de volgende scenario's:

  • Voor gegevensbronnen in de mislukte beschikbaarheidszone zijn de gegevensbronnen mogelijk pas beschikbaar als de zone wordt hersteld. Back-uptaken kunnen niet worden uitgevoerd totdat de gegevensbron opnieuw beschikbaar is. De RTO is niet gedefinieerd.
  • Voor alle gegevensbronnen in gezonde beschikbaarheidszones kan een kleine hoeveelheid downtime, meestal een paar seconden, optreden terwijl het platform overschakelt naar het gebruik van gezonde beschikbaarheidszones voor de Azure Backup-service.

• Herverdeling: Eventuele volgende taakuitvoeringen maken automatisch gebruik van infrastructuur in gezonde zones, zolang de gegevensbronnen beschikbaar zijn.

  U bent verantwoordelijk voor het herstellen van uw back-up naar infrastructuur in een herstelzone en voor het opnieuw configureren van load balancers, clients en andere systemen om verkeer om te leiden naar een goede infrastructuur in de nieuwe zone.

Zoneherstel

Wanneer de beschikbaarheidszone wordt hersteld, herstelt Azure Backup automatisch bewerkingen in de beschikbaarheidszone en routeert het verkeer tussen de zones als normaal. Taken blijven actief en gegevens blijven beschikbaar.

Testen op zonefouten

Het Azure Backup platform beheert verkeersroutering, gegevensreplicatie, failover en failback. Deze functie wordt volledig beheerd, dus u hoeft geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren.

Tolerantie voor storingen in de hele regio

Azure Backup ondersteunt georedundantie en failover via geografisch redundante opslag (GRS) en herstel tussen regio's.

Geografisch redundante opslag en herstel tussen regio's

Als u regionale redundantie voor uw back-upgegevens wilt bereiken, kunt u met Azure Backup uw back-ups repliceren naar een Azure gekoppelde regio met behulp van geo-redundante opslag (GRS). GRS beschermt uw back-ups tegen regionale storingen.

De regio waarin u uw kluis implementeert, wordt de primaire regio genoemd. Uw gegevensbronnen moeten zich in de primaire regio bevinden. U kunt geen back-ups configureren naar een kluis in een andere regio.

De gekoppelde regio wordt ook wel de secundaire regio genoemd.

Diagram dat laat zien hoe gegevens worden gerepliceerd met behulp van GRS.

Als u GRS niet configureert, kan een storing in de regio van de kluis u nog steeds toegang tot de kluis geven en back-upitems laten weergeven. Zonder regionale redundantie blijven de onderliggende back-upgegevens echter niet beschikbaar voor herstelbewerkingen.

Regio-overschrijdend herstel

Wanneer u GRS configureert voor een kluis, maakt Microsoft back-ups in de gekoppelde regio beschikbaar na het declareren van een storing in de primaire regio. Als uw gegevensbron ondersteuning biedt voor het inschakelen van herstel tussen regio's, kunt u herstellen vanuit herstelpunten van secundaire regio's, zelfs als er geen storing optreedt in de primaire regio. Met herstel over regio's heen kunt u ook drills uitvoeren om uw veerkracht te beoordelen tegen regionale storingen. Als u herstel in meerdere regio's inschakelt, wordt uw back-upopslag bijgewerkt van GRS naar geografisch redundante opslag met leestoegang (RA-GRS).

Requirements

• Region support: GRS voor Azure Backup werkt alleen binnen gekoppelde Azure regio's.

• Alleen nieuwe kluizen: moet u GRS configureren op uw kluis voordat de eerste back-up plaatsvindt.

Overwegingen

• Herstellen tussen regio's: Nadat u herstellen tussen regio's hebt ingeschakeld, kan het tot 48 uur duren voordat de back-upitems beschikbaar zijn in de secundaire regio.

Kosten

Er worden extra kosten in rekening gebracht voor GRS-kluizen vanwege replicatie tussen regio's en opslag in de secundaire regio. Gegevensoverdracht tussen Azure regio's wordt in rekening gebracht op basis van de standaard bandbreedtetarieven tussen regio's. Herstel in meerdere regio's wordt tegen een ander tarief in rekening gebracht omdat Microsoft uw kluisopslag upgradet van GRS naar RA-GRS. Zie Azure Backup prijzen voor meer informatie.

Ondersteuning voor meerdere regio's configureren

• Maak een nieuwe kluis die gebruikmaakt van GRS en CRR: Wanneer u een kluis maakt, moet u ook de opslagredundantie configureren. Nadat u GRS hebt geselecteerd, kunt u optioneel CRR inschakelen voor de kluis. De stappen die u volgt, verschillen, afhankelijk van het type kluis. Voor meer informatie, zie:

  • Back-upkluizen aanmaken en verwijderen
  • Een Recovery Services-kluis maken en configureren

• GRS en CRR configureren voor bestaande kluizen: Voor Backup-kluizen moet opslagredundantie worden geconfigureerd wanneer u de kluis maakt.

  Voor Recovery Services-kluizen moet opslagredundantie worden geconfigureerd voordat u workloads beveiligt. Zodra een workload is beveiligd, is de instelling vergrendeld en kan deze niet meer worden gewijzigd.

  U kunt CRR inschakelen voor bestaande GRS-kluizen. U kunt CRR niet uitschakelen zodra deze is ingeschakeld.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer kluizen zijn geconfigureerd voor het gebruik van geografisch redundante opslag en alle regio's operationeel zijn.

• Regio-overschrijdende bewerking: Back-ups worden altijd voltooid in de primaire regio, de regio waar de kluis en gegevensbron zijn geplaatst.

• Replicatie van gegevens in meerdere regio's: Wanneer de kluis is geconfigureerd voor het gebruik van GRS, worden back-ups eerst doorgevoerd in de primaire regio met behulp van lokaal redundante opslag (LRS). Na een geslaagde voltooiing in de primaire regio worden gegevens asynchroon gerepliceerd naar de secundaire regio waar ze worden opgeslagen met LRS. Het kan tot 12 uur duren voordat de back-upgegevens van de primaire regio naar de secundaire regio worden gerepliceerd.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer de kluizen zijn geconfigureerd voor het gebruik van geografisch redundante opslag en er een storing optreedt in de primaire regio.

• Detectie en reactie: Voor gegevensbronnen die ondersteuning bieden voor herstel tussen regio's en waar herstel tussen regio's is ingeschakeld in de kluis, kunt u op elk gewenst moment uw eigen herstel tussen regio's naar de gekoppelde regio starten, ook tijdens een regiostoring of noodgeval. U bent verantwoordelijk voor het detecteren van de storing en het uitvoeren van herstelacties, waaronder het herstellen van back-ups naar een gezonde regio.

  Voor alle andere scenario's zijn de gegevens die worden gerepliceerd naar de secundaire regio alleen beschikbaar om te herstellen in de secundaire regio als Azure een noodgeval declareert in de primaire regio. Microsoft is verantwoordelijk voor het declareren van een dergelijke ramp. De hoeveelheid tijd die nodig is om een noodgeval te declareren, is afhankelijk van de ernst van het incident en de tijd die nodig is om de situatie te beoordelen. Het zou waarschijnlijk pas na een langere periode worden uitgevoerd.

• Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. Aan de andere kant:

  • U kunt Azure Resource Health gebruiken om de status van een afzonderlijke resource te controleren en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • U kunt Azure Service Health gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Servicestatuswaarschuwingen instellen om u op de hoogte te stellen van problemen.

• Verwachte gegevensverlies: De RPO voor uw back-upgegevens is afhankelijk van meerdere factoren, waaronder uw back-upschema. Over het algemeen verwacht u voor een regio-storing maximaal 36 uur gegevensverlies, omdat de RPO in de primaire regio 24 uur is en het maximaal 12 uur kan duren om de back-upgegevens van de primaire naar de secundaire regio te repliceren.

• Verwachte downtime: De RTO verschilt voor elk van de volgende scenario's:

  • Gegevensbronnen en andere resources in de mislukte regio zijn mogelijk niet beschikbaar totdat de regio wordt hersteld, dus de RTO is niet gedefinieerd.
  • Azure Backup kan mogelijk geen back-up- of herstelbewerkingen uitvoeren in de mislukte regio totdat de regio wordt hersteld, zodat de RTO niet is gedefinieerd.
  • Als u herstel tussen regio's gebruikt, is de RTO voor het initiëren van het herstellen van back-ups die al zijn gerepliceerd naar de gekoppelde regio nul. Als u herstel tussen regio's niet gebruikt, is de RTO afhankelijk van hoe lang het duurt voordat Microsoft een noodgeval in de mislukte regio declareert.

  Er kunnen geen back-uptaken worden uitgevoerd terwijl de primaire regio offline is. U kunt gegevens herstellen in de kluis, maar geen nieuwe gegevens toevoegen.

• Herverdeling: Er kunnen geen back-uptaken worden uitgevoerd terwijl de primaire regio offline is. U kunt gegevens herstellen in de kluis, maar geen nieuwe gegevens toevoegen.

  U bent verantwoordelijk voor het herstellen van uw back-up naar infrastructuur in de gekoppelde regio en voor het opnieuw configureren van load balancers, clients en andere systemen om verkeer om te leiden naar een goede infrastructuur in de gekoppelde regio.

Herstel van de regio

Wanneer de primaire regio is hersteld, hervat Azure Backup automatisch de bewerkingen in de regio. Taken hervatten en gegevens blijven beschikbaar.

Testen op regiofouten

U kunt herstellen tussen regio's gebruiken om een herstelbewerking uit te voeren naar de gekoppelde regio. U kunt deze methode gebruiken om uw herstel- en andere herstelprocessen te verifiëren.

Tolerantie voor verlies van back-upgegevens

Azure Backup biedt twee belangrijke herstelfuncties om onbedoelde of schadelijke verwijdering van uw back-upgegevens te voorkomen:

• Met voorlopig verwijderen kunt u verwijderde objecten en kluizen herstellen tijdens een configureerbare bewaarperiode. Deze periode is standaard 14 dagen, maar u kunt deze configureren. Denk aan 'soft delete' als een prullenbak voor uw back-ups en opslagplaatsen. Voor meer informatie, zie Standaard beveiligd met soft delete voor Azure Backup.

• Onveranderbare kluizen kunnen u helpen uw back-upgegevens te beveiligen door bewerkingen te blokkeren die kunnen leiden tot verlies van herstelpunten. U kunt de onveranderbare kluisinstelling vergrendelen zodat deze niet ongedaan kan worden gemaakt. U kunt ook WORM-opslag (eenmaal schrijven, veel lezen) voor back-ups gebruiken om te voorkomen dat kwaadwillende actoren onveranderbaarheid uitschakelen en back-ups verwijderen. Zie Onveranderbare kluis voor Azure Backup voor meer informatie.

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLAs voor onlineservices voor meer informatie.

De Azure Backup SLA heeft betrekking op de beschikbaarheid van de service voor zowel back-up- als herstelbewerkingen. Als u wilt worden gedekt door de SLA, moet u mislukte back-up- of hersteltaken niet minder vaak dan één keer per dertig minuten opnieuw proberen.