Betrouwbaarheid in Azure Backup

Azure Backup is een ingebouwde Azure-service die cloud- en on-premises workloads veilig beveiligt. Backup kan de bescherming van meerdere workloads schalen en biedt naadloze integratie met Azure workloads, waaronder virtuele machines (VM's), SAP HANA in Azure VM's, SQL in Azure VM's, Azure Files, Azure Blob Storage, Azure Data Lake Storage, Azure beheerde schijven, Azure Elastic SAN volumes en Azure Kubernetes Service (AKS). U hoeft geen automatisering of infrastructuur te beheren, 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 back-ups bestand kunnen zijn tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regio-storingen. Ook worden enkele belangrijke informatie over de Sla (Backup Service Level Agreement) gemarkeerd.

Opmerking

In dit artikel wordt beschreven hoe de Backup-service zelf bestand is tegen verschillende problemen en hoe u deze toleranter kunt maken. Er wordt niet uitgelegd hoe u Back-up gebruikt om uw VM's, gegevens of andere assets te beveiligen. Zie Overzicht van Back-up voor meer informatie over het gebruik van Back-up.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Als u een back-up van uw productieworkloads wilt maken, raden we u aan uw kluis op de volgende manieren te configureren:

  • Gebruik zone-redundante opslag (ZRS) als de minimale redundantielaag voor uw back-ups. ZRS repliceert uw back-ups in meerdere beschikbaarheidszones, zodat u uw back-ups kunt herstellen tijdens een storing in de beschikbaarheidszone.

  • Als u geografisch redundante opslag (GRS) gebruikt om uw back-ups te repliceren naar een gekoppelde Azure regio, schakelt u CRR (Cross-Region Restore) in voor ondersteunde gegevensbronnen. Met CRR kunt u de back-ups op elk gewenst moment herstellen in de gekoppelde regio.

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

Opmerking

Deze aanbevelingen voor opslagredundantie zijn van toepassing op locaties waar back-upkopieën worden gerepliceerd, niet op de Backup-service of op de resources waar u een back-up van maakt. Back-upbeveiliging en opslagredundantie vormen een aanvulling op elkaar. Back-ups beschermen tegen gegevensverlies en redundantie beschermt tegen infrastructuurfouten.

Zie Back-up van cloud en on-premises workloads naar de cloud voor een lijst met andere aanbevelingen voor back-up, inclusief aanbevelingen voor 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

Back-up kan een back-up maken van verschillende gegevensbronnen en deze herstellen. U configureert back-ups anders, afhankelijk van de gegevensbron waarmee u werkt. De volgende gegevensbronnen zijn gebruikelijk:

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

Back-up slaat uw back-upgegevens op in kluizen. Kluizen zijn onlineopslagentiteiten in Azure die gegevens bevatten, zoals back-upkopieën, herstelpunten en back-upbeleid. Recovery Services-kluizen en Backup-kluizen zijn twee typen kluizen. U kunt een of beide typen gebruiken, afhankelijk van wat u moet beveiligen. Zie de veelgestelde vragen over de kluizen die worden ondersteund voor back-up en herstel voor een lijst met gegevensbronnen 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 problemen kunt oplossen die optreden tijdens back-up- en herstelbewerkingen. U maakt ook back-upbeleid dat is gekoppeld aan taken. Beleidsregels geven configuratie op zoals het back-upschema en hoe lang u gegevens wilt bewaren.

Digitale kluizen slaan uw back-upbeleid en configuratie op, samen met metagegevens over taken, waarmee u taken kunt bijhouden en problemen kunt oplossen.

Fysieke architectuur

Microsoft beheert de kerninfrastructuur van de Backup-service. Deze infrastructuur is verantwoordelijk voor het beheer en de werking van de service, waaronder het activeren en bewaken van taken.

Back-ups worden opgeslagen in de kluis. Kluizen zijn gebouwd op Azure Storage. Kluizen repliceren uw back-upgegevens automatisch en de duurzaamheid en tolerantie van de back-up zijn afhankelijk van de opslagredundantie van de kluis.

  • Lokaal redundante opslag (LRS) repliceert gegevens binnen uw opslagkluis naar een of meer Azure beschikbaarheidszones die zich in de primaire regio van uw keuze bevinden. U kunt de gewenste beschikbaarheidszone niet kiezen, maar Azure LRS-accounts mogelijk verplaatsen of uitbreiden tussen zones om de taakverdeling te verbeteren. Uw gegevens zijn niet gegarandeerd verspreid over zones. Zie Overzicht van beschikbaarheidszones voor meer informatie.

  • ZRS en GRS bieden extra bescherming. In dit artikel worden deze opties uitgebreid beschreven.

Opmerking

Sommige gegevensbronnen ondersteunen back-ups van operationele lagen , die gegevens opslaan op een andere locatie in plaats van in de kluis. Azure back-ups van beheerde schijven en AKS-back-ups ondersteunen operationele tier back-ups, die worden opgeslagen in schijfsnapshots. In dit artikel worden geen back-upopslag van operationele lagen besproken, maar u kunt de richtlijnen voor tolerantie in dit artikel toepassen op back-upbewerkingen en -werkstromen voor deze back-uptypen.

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 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. Zie Problemen met back-upkluisbeheerbewerkingen oplossen als u herhaalde fouten ondervindt.

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.

Back-up beheert de configuratie van de beschikbaarheidszone van de service en voor uw gegevens afzonderlijk.

  • Service: De Backup-service is automatisch zonebestendig in ondersteunde regio's. 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 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.

Diagram met de Back-up kernservice, die automatisch zone-resilient is, en zone-redundante back-upopslag.

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 ZRS inschakelt voor uw back-ups, worden er kosten in rekening gebracht tegen een ander tarief dan LRS vanwege de extra replicatie- en opslagoverhead. Zie Back-upprijzen voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

  • Maak een nieuwe kluis die gebruikmaakt van ZRS: Configureer opslagredundantie wanneer u een kluis maakt. U volgt verschillende stappen, afhankelijk van het type kluis. Zie de volgende artikelen voor meer informatie:

  • ZRS configureren voor bestaande kluizen: Voor Back-upkluizen configureert u opslagredundantie wanneer u de kluis maakt. Nadat u een Backup-kluis hebt gemaakt, is de instelling vergrendeld en kunt u deze niet wijzigen.

    Voor Recovery Services-kluizen moet u opslagredundantie configureren voordat u workloads beveiligt. Nadat u een workload hebt beveiligd, is de instelling vergrendeld en kunt u deze niet wijzigen.

    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 Standaardinstellingen wijzigen voor meer informatie. U bent ook verantwoordelijk voor het handmatig verwijderen van bestaande herstelpunten en andere gegevens, omdat het bewaarbeleid van de oude kluis niet meer van toepassing is. Zie Een Backup-kluis verwijderen of Een Recovery Services-kluis verwijderen voor meer informatie.

Gedrag wanneer alle zones in orde zijn

Deze sectie beschrijft wat u kunt verwachten bij het configureren van kluizen voor ZRS, wanneer alle zones operationeel zijn.

  • Bewerking tussen zones: Back-ups worden uitgevoerd op infrastructuur welke is gerepliceerd in meerdere zones. Azure beheert taken van infrastructuur in elke zone.

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

Gedrag tijdens een zonefout

Deze sectie beschrijft wat u kunt verwachten wanneer u kluizen voor ZRS configureert en er een storing is in een van de zones.

  • Detection en response: Voor de Backup-service zelf is Microsoft verantwoordelijk voor het detecteren van fouten in beschikbaarheidszones en reageren. U hoeft niets te doen om een zonefailover te starten.

    Belangrijk

    Voor 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 goede zone.

  • Notification: Microsoft informeert u niet automatisch wanneer een zone uitvalt. 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 taken is afhankelijk van welke zone mislukt.

    • Voor alle gegevensbronnen in de uitgevallen beschikbaarheidszone zorgt het uitvallen van die zone ervoor dat de gegevensbronnen niet beschikbaar zijn. Actieve taken kunnen worden onderbroken of mislukt.

    • 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 gezonde beschikbaarheidszones voor de Backup-service.

  • Verwachte gegevensverlies: De verwachte hoeveelheid gegevensverlies 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 verwachte hoeveelheid downtime 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 gezonde beschikbaarheidszones voor de Backup-service.

  • Herverdeling: 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 gezonde zone 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 Back-up bewerkingen automatisch in de beschikbaarheidszone en routeert het verkeer tussen de zones als normaal. Taken blijven actief en gegevens blijven beschikbaar.

Testen op zonefouten

Het Back-upplatform 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

Back-up ondersteunt georedundantie en failover via GRS en CRR.

Belangrijk

GRS voor backup werkt alleen binnen gekoppelde Azure regio's.

Geografisch redundante opslag en herstel tussen regio's

Als u regionale redundantie voor uw back-upgegevens wilt bereiken, gebruikt u Backup om uw back-ups te repliceren naar een Azure gekoppelde regio met behulp van 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 voor 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 en er een storing optreedt in de kluisregio, hebt u mogelijk toegang tot de kluis en kunt u back-up items 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 een storing in de primaire regio. Als uw gegevensbron CRR ondersteunt, kunt u herstellen vanaf herstelpunten van secundaire regio's, zelfs wanneer er geen storing optreedt in de primaire regio. Met CRR kunt u ook drills uitvoeren om tolerantie te beoordelen tegen regionale storingen. Wanneer u CRR inschakelt, upgrade Microsoft uw back-upopslag van GRS naar georedundante opslag met leestoegang (RA-GRS).

Requirements

  • Region support: GRS voor Back-up werkt alleen binnen gepaarde Azure-regio's.

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

Overwegingen

  • CRR: Nadat u CRR hebt ingeschakeld, kunnen back-upitems maximaal 48 uur 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 voor gegevensoverdracht. CRR wordt tegen een ander tarief in rekening gebracht omdat uw kluisopslag door Microsoft wordt bijgewerkt van GRS naar RA-GRS. Zie Back-upprijzen 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 opslagredundantie configureren. Nadat u GRS hebt geselecteerd, kunt u desgewenst CRR inschakelen op de kluis. De stappen die u volgt, hangen af van het type kluis. Zie de volgende artikelen voor meer informatie:

  • GRS en CRR configureren voor bestaande kluizen: Voor Back-upkluizen moet u opslagredundantie configureren wanneer u de kluis maakt.

    Voor Recovery Services-kluizen moet u opslagredundantie configureren voordat u workloads beveiligt. Nadat een workload is beveiligd, is de instelling vergrendeld en kunt u deze niet wijzigen.

    U kunt CRR inschakelen voor bestaande GRS-kluizen. Nadat u CRR hebt ingeschakeld, kunt u deze niet uitschakelen.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u kluizen configureert voor het gebruik van GRS en alle regio's operationeel zijn.

  • Bewerking tussen regio's: Back-ups worden altijd voltooid in de primaire regio, de regio waar de kluis en gegevensbron zijn geïmplementeerd.

  • Replicatie van gegevens in meerdere regio's: Wanneer u de kluis configureert voor het gebruik van GRS, worden back-ups eerst doorgevoerd in de primaire regio met behulp van LRS. Nadat de voltooiing in de primaire regio is voltooid, worden gegevens asynchroon gerepliceerd naar de secundaire regio. De secundaire regio maakt gebruik van LRS om gegevens op te slaan. Het kan maximaal 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 u kluizen configureert voor het gebruik van GRS en er een storing optreedt in de primaire regio.

  • Detectie en reactie: Voor gegevensbronnen die CRR ondersteunen en waar CRR is ingeschakeld in de kluis, kunt u uw eigen CRR op elk gewenst moment initiëren naar de gekoppelde regio, inclusief tijdens een storing in de regio of een 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 zijn 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 noodgeval. 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. Microsoft declareert doorgaans pas na een langere periode een noodgeval.

  • Notification: Microsoft informeert u niet automatisch wanneer een regio uitvalt. Aan de andere kant:

  • Verwachte gegevensverlies: De RPO voor uw back-upgegevens is afhankelijk van meerdere factoren, waaronder uw back-upschema. In 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 pas beschikbaar als de regio wordt hersteld, dus de RTO is niet gedefinieerd.

    • Back-up kan mogelijk geen back-up- of herstelbewerkingen uitvoeren in de uitgevallen regio totdat deze is hersteld, waardoor de hersteldoelstelling (RTO) niet gedefinieerd is.

    • Als u CRR gebruikt, is de RTO voor het starten van het herstel van back-ups die al zijn gerepliceerd naar de gekoppelde regio nul. Als u CRR niet gebruikt, is de RTO afhankelijk van hoe lang het duurt voordat Microsoft een noodgeval in de mislukte regio declareert.

  • Herverdeling: Er kunnen geen back-uptaken worden uitgevoerd terwijl de primaire regio offline is. U kunt gegevens in de kluis herstellen, maar u kunt 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 wordt hersteld, herstelt Back-up automatisch bewerkingen in de regio. Taken hervatten en gegevens blijven beschikbaar.

Test voor regiofouten

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

Tolerantie voor verlies van back-upgegevens

Back-up 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 bewerken. Denk aan soft delete als een soort prullenbak voor uw back-ups en kluizen. Zie voor meer informatie Beveiligd standaard met soft delete voor Back-up.

  • 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 Write Once, Read Many (WORM)-opslag voor back-ups gebruiken om te voorkomen dat kwaadwillende actoren de onveranderbaarheid uitschakelen en back-ups verwijderen. Zie voor meer informatie Onveranderbare kluis voor Back-up.

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 SLA voor back-up omvat de beschikbaarheid van de service voor zowel back-up- als herstelbewerkingen. Als u wilt worden gedekt door de SLA, moet u ten minste eenmaal per 30 minuten mislukte back-up- of hersteltaken opnieuw proberen.

Verwante inhoud

  • Last updated on