Een back-up maken van bestanden en toepassingen in Azure Stack Hub

Overweeg een situatie waarin Azure Stack Hub als host fungeert voor virtuele machines (VM's) waarop gebruikersworkloads worden uitgevoerd. U moet een back-up maken van de bestanden en toepassingen van de workloads en deze herstellen. In dit artikel over referentiearchitectuur wordt een benadering beschreven die een geoptimaliseerde oplossing biedt voor back-up- en herstelactiviteiten.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Werkstroom

De cloudonderdelen omvatten de volgende services:

• Een Azure-abonnement dat als host fungeert voor alle cloudresources die zijn opgenomen in deze oplossing.
• Een Microsoft Entra-tenant die is gekoppeld aan het Azure-abonnement. Het biedt verificatie van Microsoft Entra-beveiligingsprinciplen om toegang tot Azure-resources te autoriseren.
• Een Azure Recovery Services-kluis in de Azure-regio die zich het dichtst bij het on-premises datacenter bevindt waarop de Azure Stack Hub-implementatie wordt gehost.

Afhankelijk van de criteria die in dit artikel worden gepresenteerd, kunnen cloudonderdelen ook de volgende services bevatten:

• Een Azure ExpressRoute-circuit dat het on-premises datacenter en de Azure-regio verbindt die als host fungeert voor de Azure Recovery Services-kluis. Het circuit is geconfigureerd om Microsoft-peering te hebben om grotere back-ups te kunnen maken.

• De Azure Import/Export-service voor het inschakelen van offline MABS-back-ups naar Azure.

  Notitie

  Vanaf 08/20 is de offline back-up van MABS naar Azure die gebruikmaakt van Azure Data Box in preview.

Afhankelijk van het gebruik van de Azure Import/Export-service voor offline back-ups van MABS naar Azure, heeft de oplossing mogelijk ook een Azure Storage-account in dezelfde Azure-regio als de Recovery Services-kluis.

De on-premises onderdelen omvatten de volgende services:

• Een geïntegreerd azure Stack Hub-systeem in het verbonden implementatiemodel waarop de huidige update wordt uitgevoerd (vanaf augustus 2020) en zich in het on-premises datacenter van de klant bevindt.

• Een Windows Server 2016- of Windows Server 2019-VM die wordt gehost door het geïntegreerde Systeem van Azure Stack Hub en waarop MABS v3 Update Release (UR) 1 wordt uitgevoerd.

• Azure Stack Hub-VM's met de MABS-beveiligingsagent, waarmee back-ups worden beheerd naar en hersteld van de MABS Azure Stack Hub-VM. Met de MABS-beveiligingsagent worden wijzigingen in beveiligde workloads bijgehouden en worden de wijzigingen overgedragen naar het MABS-gegevensarchief. De beveiligingsagent identificeert ook gegevens op de lokale computer die kunnen worden beveiligd en die een rol spelen in het herstelproces.

• Een Mars-agent (Microsoft Azure Recovery Services) die is geïnstalleerd op de server waarop MABS wordt uitgevoerd. De agent integreert MABS- en Azure Recovery Services-kluis.

  Notitie

  Een MARS-agent wordt ook wel een Azure Backup-agent genoemd.

Onderdelen

• Azure Stack Hub
• Microsoft Entra ID
• Azure Storage-account
• Azure ExpressRoute

Alternatieven

De aanbevolen oplossing die in dit artikel wordt beschreven, is niet de enige manier om back-up- en herstelfunctionaliteit te bieden aan gebruikersworkloads die worden uitgevoerd in Azure Stack Hub. Klanten hebben andere opties, waaronder:

• Lokale back-up en herstel met behulp van de functie Back-up van Windows Server die is opgenomen in het Windows Server-besturingssysteem. Gebruikers kunnen vervolgens lokale back-ups kopiëren naar langetermijnopslag. Deze benadering ondersteunt toepassingsconsistente back-ups door te vertrouwen op Windows VSS-providers, maar verhoogt het gebruik van lokale schijfruimte en overhead voor back-uponderhoud.
• Back-up en herstel met behulp van Azure Backup met de lokaal geïnstalleerde MARS-agent. Deze aanpak minimaliseert het gebruik van lokale schijfruimte en automatiseert het proces van het uploaden van back-ups naar cloudopslag. Het biedt echter geen ondersteuning voor toepassingsconsistente back-ups.
• Back-up en herstel met behulp van een back-upoplossing die is geïnstalleerd in hetzelfde datacenter, maar buiten Azure Stack Hub. Deze aanpak vereenvoudigt scenario's waarbij een niet-verbonden implementatiemodel van Azure Stack Hub is betrokken.
• Back-up en herstel op Azure Stack Hub met behulp van momentopnamen van schijven. Voor deze aanpak is vereist dat de VM waarvan een back-up wordt gemaakt, wordt gestopt. Dit is doorgaans geen haalbare optie voor bedrijfskritieke workloads, maar kan in sommige scenario's acceptabel zijn.

Scenariodetails

Back-up en herstel zijn essentiële onderdelen van een uitgebreide strategie voor bedrijfscontinuïteit en herstel na noodgevallen. Het ontwerpen en implementeren van een consistente en betrouwbare back-upbenadering in een hybride omgeving is lastig, maar kan aanzienlijk worden vereenvoudigd door integratie met Microsoft Azure-services. Dit geldt niet alleen voor de workloads die worden uitgevoerd op een traditionele on-premises infrastructuur, maar ook voor workloads die worden gehost door externe openbare en privécloudproviders. De voordelen van integratie met Azure-services zijn echter duidelijk wanneer de hybride omgevingen Azure Stack-portfolioaanbiedingen bevatten, waaronder de Azure Stack Hub.

Hoewel een van de belangrijkste sterke punten van Azure Stack Hub is dat het het PaaS-model (Platform-as-a-Service) ondersteunt, kunnen klanten ook hun bestaande IaaS-workloads (Infrastructure-as-a-Service) moderniseren. Dergelijke workloads kunnen bestandsshares, Microsoft SQL Server-databases, Microsoft SharePoint-farms en Microsoft Exchange Server-clusters omvatten. Als u ze migreert naar VM's die worden uitgevoerd op hypergeconvergeerde, zeer tolerante clusters met beheer- en programmeermodellen die consistent zijn met Microsoft Azure, leidt dit tot een geminimaliseerde beheer- en onderhoudsoverhead.

Voor het implementeren van back-ups van bestanden en toepassingen die worden uitgevoerd op azure Stack Hub-VM's, raadt Microsoft een hybride benadering aan die afhankelijk is van een combinatie van cloud- en on-premises onderdelen om een schaalbare, krachtige, robuuste, veilige, eenvoudig te beheren en kostenefficiënte back-upoplossing te bieden. Het centrale onderdeel van deze oplossing is Microsoft Azure Backup Server (MABS) v3, dat deel uitmaakt van de Azure Backup-aanbieding. MABS is afhankelijk van de Azure Stack Hub-infrastructuur voor reken-, netwerk- en kortetermijnopslagresources en maakt gebruik van opslag op basis van Azure om te fungeren als het langetermijnback-uparchief. Deze aanpak minimaliseert of elimineert de noodzaak om fysieke back-upmedia zoals tapes te onderhouden.

Kernfunctionaliteit

De voorgestelde oplossing ondersteunt de volgende functionaliteit op Azure Stack Hub-VM's met Windows Server 2019, 2016, 2012 R2, 2012, 2008 R2 SP1 (64-bits met Windows Management Framework 4.0), 2008 SP2 (64-bits met Windows Management Framework 4.0) en Windows 10 (64-bits):

• Back-up en herstel van volumes van New Technology File System (NTFS) en Resilient File System (ReFS), shares, mappen, bestanden en systeemstatus.

• Back-up en herstel van SQL Server 2019, 2017, 2016 (met vereiste servicepacks (SP's)) en 2014 (met vereiste SP's) en hun databases.

• Back-up en herstel van Exchange Server 2019- en Exchange Server 2016-servers en -databases, inclusief zelfstandige servers en databases in een DAG (Database Availability Group).

• Herstel van afzonderlijke postvakken en postvakdatabases in een DAG.

• Back-up en herstel van SharePoint 2019- en SharePoint 2016-farms (met de nieuwste IP-farms) en front-endwebserverinhoud.

• Herstellen van SharePoint 2019- en SharePoint 2016-databases, webtoepassingen, bestanden, lijstitems en zoekonderdelen.

  Notitie

  Als u Windows 10-clientbesturingssystemen wilt implementeren in Azure Stack Hub, moet u Over Windows-licenties per gebruiker beschikken of deze hebben aangeschaft via een Gekwalificeerde Multitenant Hoster (QMTH).

MABS implementeert het back-upschema disk-to-disk-to-cloud (D2D2C), waarbij de primaire back-up lokaal is opgeslagen op de server waarop de MABS-installatie wordt gehost. Lokale back-ups worden vervolgens gekopieerd naar een Azure Site Recovery-kluis. De lokale schijf fungeert als kortetermijnopslag, terwijl de kluis langetermijnopslag biedt.

Het back-upproces bestaat uit de volgende vier fasen:

1. U installeert de MABS-beveiligingsagent op een computer die u wilt beveiligen en voegt deze toe aan een beveiligingsgroep.
2. U stelt beveiliging in voor de computer of de bijbehorende app, inclusief back-up naar lokale MABS-schijven voor kortetermijnopslag en naar Azure voor langetermijnopslag. Als onderdeel van de installatie geeft u het back-upschema op voor beide typen back-ups.
3. De beveiligde workload maakt een back-up van de lokale MABS-schijven volgens de planning die u hebt opgegeven.
4. De lokale back-up die is opgeslagen op MABS-schijven, wordt een back-up gemaakt van de Azure Recovery Services-kluis door de MARS-agent die wordt uitgevoerd op de MABS-server.

Vereisten

De implementatie van de aanbevolen oplossing is afhankelijk van de volgende vereisten:

• Toegang tot een Azure-abonnement, met machtigingen die voldoende zijn om een Azure Recovery Services-kluis in te richten in de Azure-regio die zich het dichtst bij een on-premises datacenter bevindt dat als host fungeert voor de Azure Stack Hub-implementatie.

• Een Active Directory-domein Services-domein (AD DS) dat toegankelijk is vanaf een Azure Stack Hub-VM die als host fungeert voor een MABS-exemplaar.

• Een door Azure Stack Hub gehoste VM waarop een MABS-exemplaar wordt uitgevoerd, die voldoet aan de vereisten die worden vermeld in Azure Backup Server installeren op Azure Stack en met uitgaande connectiviteit met URL's die worden vermeld in DPM/MABS-netwerkondersteuning.

  Notitie

  Verderop in dit artikel worden aanvullende overwegingen voor schijfruimte en prestatieoverwegingen voor MABS beschreven.

  Notitie

  Als u wilt controleren of de VM die als host fungeert voor MABS verbinding heeft met de Azure Backup-service, kunt u de Get-DPMCloud Verbinding maken ion-cmdlet (opgenomen in de Azure Backup Server PowerShell-module) gebruiken.

  Notitie

  MABS vereist ook een lokaal exemplaar van SQL Server. Zie Azure Backup Server installeren en upgraden voor meer informatie over sql Server-vereisten.

Data types

Vanuit het perspectief van MABS zijn er twee gegevenstypen om rekening mee te houden:

• Bestandsgegevens zijn gegevens die zich doorgaans bevinden op bestandsservers (zoals Microsoft Office-bestanden, tekstbestanden of mediabestanden) en die moeten worden beveiligd als platte bestanden.
• Toepassingsgegevens zijn gegevens die aanwezig zijn op toepassingsservers (zoals Exchange-opslaggroepen, SQL Server-databases of SharePoint-farms) en waarvoor MABS rekening moet houden met de bijbehorende toepassingsvereisten.

Back-uptypen

Of u nu bestandsgegevens of toepassingsgegevens beveiligt, de beveiliging begint met het maken van een replica van de gegevensbron in de lokale opslag van een MABS-exemplaar. De replica wordt regelmatig gesynchroniseerd of bijgewerkt volgens de instellingen die u configureert. De methode die MABS gebruikt om de replica te synchroniseren, is afhankelijk van het type gegevens dat wordt beveiligd. Als een replica als inconsistent wordt geïdentificeerd, voert MABS een consistentiecontrole uit. Dit is een blok-by-block-verificatie van de replica op basis van de gegevensbron.

Voor een bestandsvolume of share op een server gebruikt de MABS-beveiligingsagent na de eerste volledige back-up een volumefilter en wijzigingslogboek om te bepalen welke bestanden zijn gewijzigd. Vervolgens wordt een controlesomprocedure uitgevoerd voor deze bestanden om alleen de gewijzigde blokken te synchroniseren. Tijdens de synchronisatie worden deze wijzigingen overgebracht naar MABS en vervolgens toegepast op de replica, waardoor de replica wordt gesynchroniseerd met de gegevensbron.

Als een replica inconsistent wordt met de gegevensbron, genereert MABS een waarschuwing die aangeeft welke computer en welke gegevensbronnen worden beïnvloed. U kunt het probleem oplossen door de replica te herstellen door een synchronisatie met consistentiecontrole op de replica te starten. Tijdens een consistentiecontrole voert MABS een blok-by-block-verificatie uit en herstelt de replica om deze terug te keren naar consistentie met de gegevensbron. U kunt een dagelijkse consistentiecontrole voor beveiligingsgroepen plannen of handmatig een consistentiecontrole starten.

Met regelmatige tussenpozen die u kunt configureren, maakt MABS een herstelpunt voor de beveiligde gegevensbron. Een herstelpunt is een versie van de gegevens die kunnen worden hersteld.

Nadat de replica is gemaakt door MABS, worden wijzigingen in volumeblokken die deel uitmaken van toepassingsbestanden bijgehouden door het volumefilter voor toepassingsgegevens. Hoe wijzigingen worden overgebracht naar de MABS-server, is afhankelijk van de toepassing en het type synchronisatie. De bewerking met het label synchronisatie in MABS Beheer istrator Console is vergelijkbaar met een incrementele back-up en maakt een transactioneel consistente en nauwkeurige weerspiegeling van de toepassingsgegevens in combinatie met de replica.

Tijdens het type synchronisatie met het label snelle volledige back-up in MABS Beheer istrator Console wordt er een volledige VSS-momentopname (Volume Shadow Copy Service) gemaakt, maar worden alleen de gewijzigde blokken overgebracht naar de MABS-server.

Elke snelle volledige back-up maakt een herstelpunt voor toepassingsgegevens. Als de toepassing incrementele back-ups ondersteunt, maakt elke synchronisatie ook een herstelpunt. Het synchronisatieproces is afhankelijk van toepassingen:

• Voor Exchange-gegevens draagt synchronisatie een incrementele VSS-momentopname over met behulp van de Exchange VSS Writer. Herstelpunten worden gemaakt voor elke synchronisatie en voor elke snelle volledige back-up.
• SQL Server-databases die zijn verzonden naar een logboek, die zich in de modus Alleen-lezen bevinden of die gebruikmaken van het eenvoudige herstelmodel, bieden geen ondersteuning voor incrementele back-ups. Herstelpunten worden alleen gemaakt voor elke snelle volledige back-up. Voor alle andere SQL Server-databases draagt synchronisatie een back-up van transactielogboeken over, met herstelpunten die worden gemaakt voor elke incrementele synchronisatie en snelle volledige back-up. Het transactielogboek is een serieel record van alle transacties die zijn uitgevoerd op de database sinds het transactielogboek voor het laatst een back-up is gemaakt.
• SharePoint-servers bieden geen ondersteuning voor incrementele back-ups. Herstelpunten worden alleen gemaakt voor elke snelle volledige back-up.

Incrementele synchronisaties vereisen minder tijd dan nodig is om een snelle volledige back-up uit te voeren. De tijd die nodig is om gegevens te herstellen, neemt echter toe naarmate het aantal synchronisaties toeneemt. Dit komt doordat MABS de laatste volledige back-up moet herstellen en vervolgens alle incrementele synchronisaties moet herstellen en toepassen tot het tijdstip dat is opgegeven voor herstel.

Om snellere hersteltijd mogelijk te maken, voert MABS regelmatig een snelle volledige back-up uit, waarmee de replica wordt bijgewerkt om de gewijzigde blokken op te nemen. Tijdens de snelle volledige back-up maakt MABS een momentopname van de replica voordat de replica wordt bijgewerkt met behulp van de gewijzigde blokken. Om frequentere RPO's in te schakelen en het venster voor gegevensverlies te verminderen, voert MABS ook incrementele synchronisaties uit in de tijd tussen twee snelle volledige back-ups.

Net als bij bestandsgegevensbeveiliging genereert MABS, als een replica inconsistent wordt met de bijbehorende gegevensbron, een waarschuwing die aangeeft welke server en welke gegevensbronnen worden beïnvloed. Als u de inconsistentie wilt oplossen, kunt u de replica herstellen door een synchronisatie te starten met consistentiecontrole op de replica. Tijdens een consistentiecontrole voert MABS een blok-by-block-verificatie van de replica uit en herstelt deze om deze weer consistent te maken met de gegevensbronnen. U kunt een dagelijkse consistentiecontrole voor beveiligingsgroepen plannen of handmatig een consistentiecontrole starten.

Beveiligingsbeleid

Een computer of de werkbelasting wordt beveiligd wanneer u de MABS-beveiligingsagentsoftware op de computer installeert en de gegevens van de computer of de werkbelasting toevoegt aan een beveiligingsgroep. Beveiligingsgroepen worden gebruikt voor het configureren en beheren van de beveiliging van gegevensbronnen op computers. Een beveiligingsgroep is een verzameling gegevensbronnen die dezelfde beveiligingsconfiguratie delen. De beveiligingsconfiguratie is de verzameling instellingen die gebruikelijk zijn voor een beveiligingsgroep, zoals de naam van de beveiligingsgroep, het beveiligingsbeleid, opslagtoewijzingen en de methode voor het maken van replica's.

MABS slaat een afzonderlijke replica op van elk lid van de beveiligingsgroep in de opslaggroep. Een lid van een beveiligingsgroep kan dergelijke gegevensbronnen bevatten als:

• Een volume, share of map op een bestandsserver of servercluster.
• Een opslaggroep van een Exchange-server of -servercluster.
• Een database van een exemplaar van SQL Server of servercluster.

Voor elke beveiligingsgroep configureert u een beveiligingsbeleid dat is gebaseerd op uw hersteldoelen voor die beveiligingsgroep. Hersteldoelen vertegenwoordigen vereisten voor gegevensbescherming die overeenkomen met de RPO's en RPO's van uw organisatie. Binnen MABS worden ze gedefinieerd op basis van een combinatie van de volgende parameters:

• Langetermijnretentiebereik. Hiermee bepaalt u hoe lang u een back-up van gegevens op de lokale MABS-opslag wilt bewaren.

• Synchronisatie- en herstelpuntfrequenties. Dit komt rechtstreeks overeen met gegevensverliestolerantie, die op zijn beurt de RPO's van uw organisatie weerspiegelt. Het bepaalt ook hoe vaak MABS de lokale replica's moet synchroniseren met beveiligde gegevensbronnen door hun gegevenswijzigingen te verzamelen. U kunt de synchronisatiefrequentie instellen op een interval tussen 15 minuten en 24 uur. U kunt er ook voor kiezen om te synchroniseren net voordat een herstelpunt wordt gemaakt in plaats van volgens een opgegeven tijdsplanning.

• Schema voor herstelpunten op korte termijn. Hiermee wordt bepaald hoeveel herstelpunten moeten worden gemaakt in de lokale opslag voor de beveiligingsgroep. Voor bestandsbeveiliging selecteert u de dagen en tijden waarvoor u herstelpunten wilt maken. Voor gegevensbescherming van toepassingen die incrementele back-ups ondersteunen, bepaalt de synchronisatiefrequentie het herstelpuntschema.

• Snelle volledige back-upplanning. Dit is het herstelpuntschema voor gegevensbeveiliging van toepassingen die geen ondersteuning bieden voor incrementele back-ups en wel snelle volledige back-ups ondersteunen.

• Online back-upschema. Hiermee bepaalt u de frequentie van het maken van een kopie van lokale back-ups in de Azure Recovery Services-kluis die is gekoppeld aan het lokale MABS-exemplaar. U kunt plannen op dagelijkse, wekelijkse, maandelijkse of jaarlijkse basis, met een maximaal toegestane frequentie van twee back-ups per dag. MABS maakt automatisch een herstelpunt voor onlineback-ups met behulp van de meest recente lokale replica, zonder nieuwe gegevens uit de beveiligde gegevensbron over te dragen.

  Notitie

  Een Recovery Services-kluis ondersteunt maximaal 9.999 herstelpunten.

• Beleid voor onlineretentie. Hiermee geeft u de periode op waarin dagelijkse, wekelijkse, maandelijkse en jaarlijkse back-ups worden bewaard in de Azure Site Recovery-kluis die is gekoppeld aan het lokale MABS-exemplaar.

  Notitie

  Als u de nieuwste inhoud van de gegevensbron online wilt beveiligen, maakt u een nieuw herstelpunt op de lokale schijf voordat u een onlineherstelpunt maakt.

  Notitie

  Azure Recovery Services-kluis is standaard geografisch redundant, wat betekent dat elke back-up die naar de opslag wordt gekopieerd, automatisch wordt gerepliceerd naar een Azure-regio die deel uitmaakt van een vooraf gedefinieerd regiopaar. U kunt de replicatie-instellingen wijzigen in lokaal redundant als dat voldoende is voor uw tolerantiebehoeften en als u de opslagkosten wilt minimaliseren. U moet echter overwegen om de standaardinstelling te behouden. Deze optie kan niet worden gewijzigd als de kluis beveiligde items bevat.

  Notitie

  Zie BCDR (Bedrijfscontinuïteit en herstel na noodgevallen) voor een lijst met Azure-regioparen : gekoppelde Azure-regio's.

Herstelbewerkingen testen

Naast een optimaal ontworpen en geïmplementeerde back-upstrategie is het even belangrijk om het herstelproces voor elk type beveiligde workload te definiëren, documenteren en testen. Hoewel MABS ingebouwde consistentiecontroles biedt waarmee de integriteit van gegevensback-ups automatisch wordt gecontroleerd, moet het testen van herstelbewerkingen deel uitmaken van routinematige operationele procedures. Tijdens het testen wordt een herstelbewerking gevalideerd door de status van herstelde workloads te onderzoeken. De testresultaten moeten beschikbaar zijn voor eigenaren van workloads.

Over het algemeen is het testen van herstelbewerkingen vaak lastig, omdat er een omgeving nodig is die nauw lijkt op de omgeving die als host fungeert voor de beveiligde workloads. Azure Stack Hub, met de ingebouwde DevOps en infrastructuur als codemogelijkheden, vereenvoudigt het aanpakken van deze uitdaging aanzienlijk.

Rollen en verantwoordelijkheden

Het plannen en implementeren van back-ups en herstel van workloads op basis van Azure Stack Hub omvat doorgaans interactie tussen veel belanghebbenden:

• Azure Stack Hub-operators. Azure Stack Hub-operators beheren de Azure Stack Hub-infrastructuur en zorgen ervoor dat er voldoende reken-, opslag- en netwerkresources zijn voor het implementeren van een uitgebreide back-up- en hersteloplossing en deze resources beschikbaar maken voor tenants. Ze werken ook samen met eigenaren van toepassingen en gegevens om de optimale benadering te bepalen voor het implementeren van hun workloads in Azure Stack Hub.
• Azure-beheerders. Azure-beheerders beheren de Azure-resources die nodig zijn om hybride back-upoplossingen te implementeren.
• Microsoft Entra-beheerders. Microsoft Entra-beheerders beheren Microsoft Entra-resources, waaronder gebruikers- en groepsobjecten die worden gebruikt voor het inrichten, configureren en beheren van Azure-resources.
• It-personeel van de Azure Stack Hub-tenant. Deze belanghebbenden ontwerpen, implementeren en beheren MABS, inclusief de MABS-back-ups en herstelbewerkingen.
• Azure Stack Hub-gebruikers. Deze gebruikers bieden RPO- en RTO-vereisten en verzenden aanvragen voor het maken en herstellen van gegevens en toepassingen.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

Azure Stack Hub helpt de beschikbaarheid van workloads te verhogen vanwege de tolerantie die inherent is aan de infrastructuur. U kunt de beschikbaarheid verder vergroten door oplossingen te ontwerpen en te implementeren die het bereik van workloadbeveiliging uitbreiden. Dit is de toegevoegde waarde die MABS biedt. In de context van MABS die wordt uitgevoerd op Azure Stack Hub, zijn er twee aspecten van beschikbaarheid die in meer detail moeten worden verkend:

• De beschikbaarheid van MABS en de bijbehorende gegevensarchieven
• De beschikbaarheid van de herstelmogelijkheid naar een bepaald tijdstip van met MABS beveiligde workloads

U moet beide overwegen wanneer u een back-upstrategie ontwikkelt die wordt aangestuurd door beoogde herstelpunten (RPO's) en beoogde hersteltijd (RPO's). RTO en RPO vertegenwoordigen continuïteitsvereisten die worden bepaald door bedrijfsfuncties binnen een organisatie. RPO wijst een periode aan die het maximaal acceptabele gegevensverlies vertegenwoordigt als gevolg van een incident waardoor de gegevens gedurende een bepaalde periode niet beschikbaar zijn. RTO wijst de maximaal acceptabele tijdsduur aan die nodig is om de toegang tot bedrijfsfuncties opnieuw in te voeren na een incident waardoor de functies niet beschikbaar zijn.

De beschikbaarheid van MABS en de bijbehorende gegevensarchieven is afhankelijk van de beschikbaarheid van de VIRTUELE machine waarop de MABS-installatie en de lokale en cloudopslag worden gehost. Azure Stack Hub-VM's zijn standaard maximaal beschikbaar. Als er een MABS-fout opgetreden is, hebt u de mogelijkheid om met Azure Backup beveiligde items te herstellen van andere Azure Stack Hub-VM's die als host fungeert voor MABS. Houd er echter rekening mee dat voor een server die ALS host fungeert voor MABS om back-ups te herstellen die zijn uitgevoerd met behulp van MABS die op een andere server worden uitgevoerd, beide servers moeten worden geregistreerd bij dezelfde Azure Site Recovery-kluis.

De herstelmogelijkheid van met MABS beveiligde werkbelastingen is afhankelijk van het type gegevens, de back-ups en het beveiligingsbeleid van MABS. Als u deze afhankelijkheden wilt begrijpen, moet u deze concepten in meer detail verkennen.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Het beheren van gebruikersgegevens en toepassingen in hybride scenario's rechtvaardigt aanvullende beveiligingsoverwegingen. Deze overwegingen kunnen worden gegroepeerd in de volgende categorieën:

• Back-upversleuteling
• Beveiliging van Azure Recovery Services-kluis

MABS en Azure Backup dwingen de versleuteling van back-ups in rust en in transit af:

• Versleuteling-at-rest. Tijdens de installatie van MABS biedt de gebruiker een wachtwoordzin. Deze wachtwoordzin wordt vervolgens gebruikt om alle back-ups te versleutelen voordat ze worden geüpload naar een Azure Recovery Services-kluis. Ontsleuteling vindt alleen plaats nadat back-ups uit die kluis zijn gedownload. De wachtwoordzin is alleen beschikbaar voor de gebruiker die deze heeft gemaakt en voor de lokaal geïnstalleerde MARS-agent. Het is essentieel om ervoor te zorgen dat de wachtwoordzin wordt opgeslagen op een veilige locatie, omdat deze fungeert als het autorisatiemechanisme bij het uitvoeren van herstel in de cloud op een andere MABS-server dan de server waar de back-ups plaatsvonden.
• Versleuteling tijdens overdracht. MABS v3 is afhankelijk van TLS-protocol (Transport Layer Security) versie 1.2 om de verbindingen met Azure te beveiligen.

Azure Recovery Services-kluis biedt mechanismen voor het verder beveiligen van onlineback-ups, waaronder:

• Azure RBAC (op rollen gebaseerd toegangsbeheer van Azure). Met Azure RBAC kunt u verantwoordelijkheden delegeren en scheiden volgens het principe van minimale bevoegdheden. Er zijn drie ingebouwde rollen voor Azure Backup waarmee de toegang tot back-upbeheerbewerkingen wordt beperkt:
  • Inzender voor back-ups. Biedt toegang tot het maken en beheren van back-ups, met uitzondering van het verwijderen van de Recovery Services-kluis en het delegeren van toegang tot anderen.
  • Back-upoperator. Biedt toegang die gelijk is aan die van de inzender voor back-ups, met uitzondering van het verwijderen van back-ups en het beheren van back-upbeleid.
  • Back-uplezer. Biedt toegang tot het bewaken van back-upbeheerbewerkingen.
• Azure-resourcevergrendelingen. U kunt alleen-lezen- en verwijderingsvergrendelingen maken en toewijzen aan een Azure Site Recovery-kluis om het risico te beperken dat de kluis per ongeluk of opzettelijk wordt gewijzigd of verwijderd.
• Voorlopig verwijderen. Met voorlopig verwijderen kunt u kluis- en back-upgegevens beschermen tegen onbedoelde of schadelijke verwijderingen. Als een gebruiker met voorlopig verwijderen een back-upitem verwijdert, worden de bijbehorende gegevens gedurende 14 dagen bewaard, waardoor de gegevens gedurende die periode kunnen worden hersteld zonder gegevensverlies. Voor het bewaren van back-upgegevens van 14 dagen in de status voorlopig verwijderen worden geen kosten in rekening gebracht. Voorlopig verwijderen is standaard ingeschakeld.
• Beveiliging van beveiligingsgevoelige bewerkingen. De Azure Recovery Services-kluis implementeert automatisch een andere verificatielaag wanneer een beveiligingsgevoelige bewerking, zoals het wijzigen van een wachtwoordzin, wordt geprobeerd. Deze extra validatie zorgt ervoor dat alleen geautoriseerde gebruikers deze bewerkingen uitvoeren.
• Bewaking en waarschuwingen van verdachte activiteiten. Azure Backup biedt ingebouwde bewaking en waarschuwingen voor beveiligingsgevoelige gebeurtenissen die betrekking hebben op Azure Backup-bewerkingen. Back-uprapporten vereenvoudigen het bijhouden van gebruik, het controleren van back-ups en herstelbewerkingen en het identificeren van belangrijke back-uptrends.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Wanneer u rekening houdt met de kosten van de back-upoplossing die in dit artikel wordt beschreven, moet u rekening houden met zowel on-premises als cloudonderdelen. De prijzen van on-premises onderdelen worden bepaald door het prijsmodel van Azure Stack Hub. Net als bij Azure biedt Azure Stack Hub een regeling voor betalen per gebruik die beschikbaar is via enterprise-overeenkomsten en het Cloud Solution Provider-programma. Deze regeling omvat een maandelijkse prijs per Windows Server-VM. Als u bestaande Windows Server-licenties kunt gebruiken, kunt u deze kosten aanzienlijk verlagen tot de prijzen van basis-VM's. MABS is afhankelijk van SQL Server als gegevensarchief, maar er zijn geen licentiekosten gekoppeld aan het uitvoeren van dat SQL Server-exemplaar als deze alleen wordt gebruikt voor MABS.

Er zijn azure-gerelateerde kosten voor het gebruik van de volgende resources:

• Azure Backup. Prijzen voor Azure Backup worden grotendeels bepaald door het aantal beveiligde workloads en de grootte van gegevensback-ups (vóór compressie en versleuteling) voor elk ervan. De kosten worden ook beïnvloed door de keuze tussen lokaal redundante opslag (LRS) en geografisch redundante opslag (GRS) voor de replicatie van de Azure Recovery Services-kluisinhoud. Zie prijzen voor Azure Backup voor meer informatie.
• Azure ExpressRoute. Prijzen voor Azure ExpressRoute zijn gebaseerd op een van twee modellen:
  • Onbeperkt gegevensverkeer. Dit is een maandelijks bedrag waarbij alle inkomende en uitgaande gegevensoverdrachten zijn opgenomen.
  • Naar gebruik. Dit is een maandelijks bedrag waarbij alle binnenkomende gegevensoverdrachten gratis en uitgaande gegevensoverdrachten per gigabyte in rekening worden gebracht.
• Azure Import/Export. De kosten voor Azure Import/Export omvatten een vaste kosten per apparaat voor apparaatafhandeling.
• Azure Storage. Wanneer u Azure Import/Export gebruikt, zijn de standaardtarieven en transactiekosten van Azure Storage van toepassing.

Zonder ExpressRoute moet u mogelijk rekening houden met het toegenomen bandbreedtegebruik van uw internetverbinding voor back-ups en herstelbewerkingen. De kosten variëren afhankelijk van veel factoren, waaronder geografisch gebied, huidig bandbreedtegebruik en de internetprovider.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.

Beheerbaarheid

Een van de belangrijkste factoren die van invloed zijn op uw back-up- en herstelstrategie, is de configuratie van beveiligingsgroepen en de criteria die u gebruikt om te bepalen welke beveiligde workloads tot dezelfde beveiligde groepen moeten behoren. Zoals eerder in dit artikel is beschreven, is een beveiligingsgroep een verzameling gegevensbronnen, zoals volumes, shares of toepassingsgegevensarchieven met algemene back-up- en herstelinstellingen. Bij het definiëren van een beveiligingsgroep moet u het volgende opgeven:

• Gegevensbronnen, zoals servers en workloads die u wilt beveiligen.
• Back-upopslag, inclusief instellingen voor kortetermijn- en langetermijnbeveiliging.
• Herstelpunten, die punten in de tijd zijn waaruit een back-up van gegevens kan worden gemaakt, kunnen worden hersteld.
• Toegewezen schijfruimte, de hoeveelheid schijfruimte uit de opslaggroep die is toegewezen voor back-ups.
• Initiële replicatie, de methode die wordt gebruikt voor de eerste back-up van gegevensbronnen. De methode kan een onlineoverdracht (via een netwerk) of een offlineoverdracht (zoals via de Azure Import/Export-service) zijn.
• De consistentiecontrolemethode, de methode voor het verifiëren van de integriteit van gegevensback-ups.

De volgende methoden worden vaak gebruikt om te bepalen welke beveiligde workloads tot dezelfde beveiligde groepen moeten behoren:

• Op computer. Deze methode combineert alle gegevensbronnen voor een computer in dezelfde beveiligingsgroep.
• Op workload. Met deze methode worden bestanden en elk toepassingsgegevenstype gescheiden in verschillende beveiligingsgroepen. Het herstellen van een server die als host fungeert voor meerdere workloads, vereist echter mogelijk meerdere herstelbewerkingen van verschillende beveiligingsgroepen.
• Door RPO en RTO. Met deze methode worden gegevensbronnen gegroepeerd met vergelijkbare RPO's. U beheert de RPO door de synchronisatiefrequentie voor de beveiligingsgroep in te stellen, waarmee de hoeveelheid mogelijk gegevensverlies (gemeten in tijd) tijdens onverwachte storingen wordt bepaald. In het scenario dat in dit artikel wordt beschreven, bepaalt u de RTO door de bewaarperiode in te stellen binnen de kortetermijnopslag. Hiermee bepaalt u de periode waarin back-ups kunnen worden hersteld vanuit de lokale kortetermijnopslag, in plaats van vanuit de langetermijnopslag in de cloud. Back-ups maken van de lokale kortetermijnopslag resulteert in een snellere herstelbewerking.
• Op gegevenskenmerken. Deze methode houdt rekening met de frequentie van gegevenswijzigingen, gegevensgroeisnelheid of opslagvereisten als de criteria voor groeperingen.

Gebruik bij het benoemen van beveiligingsgroepen unieke, betekenisvolle namen. Een naam kan elke combinatie zijn van alfanumerieke tekens en spaties van maximaal 64 tekens.

Wanneer u een beveiligingsgroep maakt, kiest u een methode voor het maken van de eerste replica. Met de initiële replicatie worden alle gegevens gekopieerd die zijn geselecteerd voor beveiliging naar de server waarop MABS wordt gehost en worden deze vervolgens gekopieerd naar de Azure Site Recovery-kluis. Beide kopieën worden gecontroleerd op consistentie. MABS kan automatisch replica's maken via het netwerk, maar u kunt handmatig replica's maken door een back-up te maken, gegevens over te dragen en offline te herstellen.

Zie Initiële replicatie via het netwerk voor meer informatie over het kiezen van de methode voor het maken van replica's. Het artikel bevat een tabel met schattingen van hoe lang MABS nodig heeft om automatisch een replica via het netwerk te maken voor verschillende beveiligde gegevensgrootten en netwerksnelheden.

Het offline-seedingproces ondersteunt het gebruik van de Azure Import/Export-service, die gegevens kan overdragen naar een Azure Storage-account met behulp van SATA-schijven. Deze mogelijkheid kan worden gebruikt wanneer onlineback-up te traag is vanwege de hoeveelheid back-upgegevens of de snelheid van de netwerkverbinding met Azure.

De werkstroom voor offline seeding heeft de volgende stappen:

1. U kopieert de eerste back-upgegevens naar een of meer SATA-schijven met behulp van het hulpprogramma AzureOfflineBackupDiskPrep.
2. Het hulpprogramma genereert automatisch een Azure Import-taak en een Microsoft Entra-app in het abonnement dat als host fungeert voor het Azure Storage-doelaccount en de Azure Recovery Services-kluis. De app biedt Azure Backup veilige en scoped toegang tot de Azure Import Service, zoals vereist voor het offline seedingproces.
3. U verzendt de schijven naar het Azure-datacenter dat als host fungeert voor het Azure Storage-doelaccount.
4. Het personeel van het Azure-datacenter kopieert gegevens van de schijven naar het Azure Storage-account.
5. De werkstroom activeert een kopie van het Azure Storage-account naar de Azure Recovery Services-kluis.

DevOps

Hoewel back-up en herstel als onderdeel van IT-bewerkingen worden beschouwd, zijn er enkele DevOps-specifieke overwegingen die de moeite waard zijn om te worden opgenomen in een uitgebreide back-upstrategie. Azure Stack Hub faciliteert geautomatiseerde implementatie van verschillende workloads, waaronder VM-toepassingen en -services. U kunt deze mogelijkheid gebruiken om de MABS-implementatie te stroomlijnen op Azure Stack Hub-VM's, wat de eerste installatie in scenario's met meerdere tenants vereenvoudigt. Door Azure Resource Manager-sjablonen, VM-extensies en de DPM PowerShell-module te combineren, is het mogelijk om de configuratie van MABS te automatiseren, inclusief de installatie van de beveiligingsgroepen, bewaarinstellingen en back-upschema's. In de geest van de best practices van DevOps moet u sjablonen en scripts opslaan in een bronbeheerfaciliteit en de implementatie ervan configureren met behulp van pijplijnen. Deze procedures helpen de hersteltijd te minimaliseren in gevallen waarin de infrastructuur die nodig is voor het herstellen van bestanden en toepassingsgegevens opnieuw moet worden gemaakt.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie overzicht van de pijler Prestatie-efficiëntie voor meer informatie.

Wanneer u VAN plan bent MABS te implementeren in Azure Stack Hub, moet u rekening houden met de hoeveelheid verwerking, opslag en netwerkbronnen die zijn toegewezen aan de VM's waarop de implementatie wordt gehost. Microsoft raadt aan om een quad-core CPU van 2,33 gigahertz (GHz) toe te wijzen om te voldoen aan de verwerkingsbehoeften van MABS en ongeveer 10 GB schijfruimte voor de binaire installatiebestanden. Andere opslagvereisten kunnen als volgt worden gecategoriseerd:

• Schijfruimte voor back-ups. De algemene aanbeveling voor back-upschijfruimte is het toewijzen van een opslaggroep met schijfruimte die ongeveer 1,5 keer zo groot is als alle gegevens waarvan een back-up moet worden gemaakt. Nadat de schijven aan de virtuele machine zijn gekoppeld, beheert MABS volume- en schijfruimtebeheer. Het aantal schijven dat u aan een VIRTUELE machine kunt koppelen, is afhankelijk van de grootte.

  Notitie

  Sla back-ups gedurende meer dan vijf dagen niet lokaal op. Back-ups ouder dan vijf dagen moeten worden offload naar de Azure Site Recovery-kluis.

• Schijfruimte voor de cachelocatie van de MARS-agent. Overweeg station C te gebruiken op de VIRTUELE machine waarop de MABS-installatie wordt gehost.

• Schijfruimte voor lokaal faseringsgebied tijdens herstelbewerkingen. Overweeg het tijdelijke station D te gebruiken op de virtuele machine waarop de MABS-installatie wordt gehost.

Als u opslag wilt inrichten voor de VM waarop de MABS-installatie wordt gehost, gebruikt u beheerde schijven in de Premium-prestatielaag. De verwachte prestatiekenmerken zijn 2300 I/O-bewerkingen per seconde (IOPS) en 145 MB/s per schijf. In tegenstelling tot Azure zijn er geen prestatiegaranties voor Azure Stack Hub.

Als u een nauwkeurigere schatting wilt maken van de opslag die nodig is voor back-ups van workloads op basis van Azure Stack Hub, kunt u overwegen de Azure Stack VM-groottecalculator voor MABS te gebruiken, die beschikbaar is via Microsoft Downloads. De rekenmachine wordt geïmplementeerd als een Microsoft Excel-werkmap met macro's die optimale azure Stack Hub-formaatgegevens afleiden die zijn gebaseerd op een aantal parameters die u opgeeft. Deze parameters omvatten:

• Brondetails met een lijst met de VM's die moeten worden beveiligd, inclusief voor elk:
  • De grootte van de beveiligde gegevens
  • Het workloadtype (Windows Server, SharePoint of SQL Server)
• Gegevensretentiebereik, in dagen

Elk type werkbelasting is standaard gekoppeld aan een vooraf gedefinieerde dagelijkse snelheid van wijzigingen (of verloop). U kunt deze waarden aanpassen als deze niet overeenkomen met de gebruikspatronen in uw omgeving.

De Azure Stack VM-groottecalculator voor MABS gebruikt de informatie die u opgeeft om het volgende op te geven:

• Een geschatte grootte van de Azure Stack Hub-VM die als host fungeert voor de installatie van MABS.
• Een geschatte hoeveelheid MABS-schijfruimte die nodig is voor het hosten van back-ups van gegevens.
• Een totaal aantal schijven met elk 1 terabyte (TB).
• Het IOPS-tarief dat beschikbaar is voor MABS-gebruik.
• Een geschatte tijd om de eerste back-up te voltooien. De schatting is gebaseerd op de totale grootte van de beveiligde gegevens en op de IOPS die beschikbaar zijn voor MABS-gebruik.
• Een geschatte tijd voor het voltooien van dagelijkse back-ups. De schatting is gebaseerd op de totale grootte van het dagelijkse verloop en op de IOPS die beschikbaar zijn voor MABS-gebruik.

Als u een beveiligingsgroep maakt met behulp van de grafische MABS-interface, berekent MABS wanneer u een gegevensbron toevoegt aan een beveiligingsgroep, de toewijzing van lokale schijfruimte die is gebaseerd op de kortetermijnhersteldoelen die u opgeeft. Vervolgens kunt u bepalen hoeveel ruimte moet worden toegewezen in de opslaggroep voor replica's en herstelpunten voor elke gegevensbron in de groep. U moet ervoor zorgen dat er voldoende ruimte is op de lokale schijven van de beveiligde servers voor het wijzigingslogboek. MABS biedt standaardruimtetoewijzingen voor de leden van de beveiligingsgroep. Zie de documentatie over beveiligingsgroepen implementeren voor meer informatie over de standaardruimtetoewijzingen voor verschillende MABS-onderdelen.

Overweeg het gebruik van de standaardruimtetoewijzingen, tenzij u weet dat ze niet aan uw behoeften voldoen. Het overschrijven van de standaardtoewijzingen kan leiden tot toewijzing van te weinig of te veel ruimte. De toewijzing van te weinig ruimte voor de herstelpunten kan voorkomen dat MABS voldoende herstelpunten opslaat om te voldoen aan de doelstellingen van uw bewaarbereik. De toewijzing van te veel ruimte verspilt schijfcapaciteit. Als u na het maken van een beveiligingsgroep te weinig ruimte voor een gegevensbron hebt toegewezen, kunt u de toewijzingen voor de replica- en herstelpuntvolumes voor elke gegevensbron verhogen. Als u te veel ruimte hebt toegewezen voor de beveiligingsgroep, kunt u de gegevensbron verwijderen uit de beveiligingsgroep en de replica verwijderen. Voeg vervolgens de gegevensbron toe aan de beveiligingsgroep met kleinere toewijzingen.

Als u na de implementatie de geschatte grootte wilt aanpassen van de Azure Stack Hub-VM's die MABS hosten om te voldoen aan wijzigingen in de verwerkings- of opslagvereisten, hebt u drie opties:

• Verticale schaalaanpassing implementeren. Hiervoor moet u de hoeveelheid en het type processor-, geheugen- en schijfbronnen wijzigen van de Azure Stack Hub-VM's waarop MABS wordt gehost.
• Horizontaal schalen implementeren. Hiervoor moet de Azure Stack Hub-VM's waarop MABS is geïnstalleerd, worden ingericht of de inrichting ervan ongedaan wordt gemaakt om te voldoen aan de verwerkingsvereisten van de beveiligde workloads.
• Beveiligingsbeleid wijzigen. Hiervoor moeten de parameters van het beveiligingsbeleid worden gewijzigd, waaronder het bewaarbereik, het schema voor herstelpunten en het snelle volledige back-upschema.

Als u ervoor kiest om volumes automatisch te laten groeien, is MABS verantwoordelijk voor het toegenomen back-upvolume naarmate de productiegegevens toenemen. Anders beperkt MABS de back-upopslag tot de grootte van gegevensbronnen in de beveiligingsgroep.

Er zijn twee belangrijkste opties om de beschikbare bandbreedte aan te passen:

• Verhoog de VM-grootte. Voor Azure Stack Hub-VM's bepaalt de grootte de maximale netwerkbandbreedte. Er zijn echter geen bandbreedtegaranties. In plaats daarvan kunnen VM's de hoeveelheid beschikbare bandbreedte tot de limiet gebruiken die wordt bepaald door hun grootte.
• Verhoog de doorvoer van uplinkswitches. Azure Stack Hub-systemen ondersteunen een reeks hardwareswitches die verschillende opties bieden voor uplinksnelheden. Elk Azure Stack Hub-clusterknooppunt heeft twee uplinks naar de top-of-rack-switches voor fouttolerantie. Het systeem wijst de helft van de uplinkcapaciteit toe voor kritieke infrastructuur en de rest is gedeelde capaciteit voor Azure Stack-services en al het gebruikersverkeer. Systemen die met snellere snelheden worden geïmplementeerd, hebben meer bandbreedte beschikbaar voor back-upverkeer.

Hoewel het mogelijk is om netwerkverkeer te scheiden door een tweede netwerkadapter aan een server te koppelen, deelt al het VM-verkeer van Azure Stack Hub met internet dezelfde uplink. Een tweede virtuele netwerkadapter kan verkeer niet scheiden op het niveau van het fysieke transport.

Voor grotere back-ups kunt u Overwegen Om Azure ExpressRoute te gebruiken met Microsoft-peering om verbinding te maken tussen virtuele Netwerken van Azure Stack Hub en azure Recovery Services-kluis. Azure ExpressRoute breidt on-premises netwerken uit naar de Microsoft-cloud via een privéverbinding die wordt geleverd door een connectiviteitsprovider. U kunt ExpressRoute-circuits aanschaffen voor een breed scala aan bandbreedten, van 50 Mbps tot 10 Gbps.

Samenvatting

Azure Stack Hub is een uniek aanbod dat verschilt in veel aspecten van andere virtualisatieplatforms. Daarom is er een speciale overweging met betrekking tot strategieën voor bedrijfscontinuïteit voor workloads die worden uitgevoerd op de VM's. Het gebruik van Azure-services vereenvoudigt het ontwerp en de implementatiestrategie. In dit artikel hebben we het gebruik van MABS verkend voor het maken van back-ups van bestand- en toepassingsgegevens op Azure Stack Hub-VM's in het verbonden implementatiemodel. Met deze aanpak kunnen klanten profiteren van de tolerantie en beheerbaarheid van Azure Stack Hub, en van de hyperscale en wereldwijde aanwezigheid van de Azure-cloud.

De back-upoplossing die hier wordt beschreven, is uitsluitend gericht op bestands- en toepassingsgegevens op Azure Stack Hub-VM's. Dit is slechts een onderdeel van een algemene strategie voor bedrijfscontinuïteit die rekening moet houden met verschillende andere scenario's die van invloed zijn op de beschikbaarheid van workloads. Enkele voorbeelden zijn: gelokaliseerde hardware- en softwarefouten, systeemstoringen, catastrofale gebeurtenissen en grootschalige rampen.

Volgende stappen

• Instructies: Back-upopslagaccounts maken in Azure Stack
• Instructies: back-up van VM's in Azure Stack Hub met behulp van Commvault
• Back-up maken van cloud- en on-premises workloads naar cloud
• Azure Backup Server installeren
• Back-up maken van bestanden en toepassingen in Azure Stack
• Een back-up maken van een SharePoint-farm in Azure Stack
• Een back-up maken van een SQL Server in Azure Stack

Verwante resources

Verwante hybride richtlijnen:

• Hybride architectuurontwerp
• Hybride opties voor Azure
• Overwegingen bij het ontwerpen van hybride apps
• Een hybride app implementeren met on-premises gegevens waarmee cross-clouds worden geschaald

Gerelateerde architecturen:

• Herstel na noodgevallen voor Azure Stack Hub-VM's
• Back-up maken van on-premises toepassingen en gegevens naar de cloud