Algemene vragen over Azure Site Recovery

Site Recovery draagt bij aan uw BCDR-strategie (bedrijfscontinuïteit en herstel na noodgevallen), door replicatie van Virtuele Azure-machines tussen regio's, on-premises virtuele machines en fysieke servers naar Azure en on-premises machines naar een secundair datacenter in te delen en te automatiseren. Meer informatie.

Nee, Azure Site Recovery biedt geen ondersteuning voor Docker-workloads die worden uitgevoerd op virtuele machines. Als u deze virtuele machines wilt beveiligen met Site Recovery, sluit u de schijven uit waarop Docker is geïnstalleerd.

Er zijn verschillende maatregelen genomen door Site Recovery om de gegevensintegriteit te waarborgen. Er wordt een beveiligde verbinding tot stand gebracht tussen alle services met behulp van het HTTPS-protocol. Dit zorgt ervoor dat malware of externe entiteiten de gegevens niet kunnen knoeien. Een andere maatregel die is genomen, is het gebruik van controlesommen. De gegevensoverdracht tussen de bron en het doel wordt uitgevoerd door controlesommen van gegevens ertussen te berekenen. Dit zorgt ervoor dat de overgedragen gegevens consistent zijn.

Azure biedt geen ondersteuning voor permanente MAC-adressen en software met mac-licentiemodellen kan dus niet worden gebruikt voor zowel on-premises naar Azure-migratie als herstel na noodgevallen.

Nee, Azure Site Recovery biedt momenteel geen ondersteuning voor tijdelijke schijven.

De Microsoft Azure Recovery Services-agent wordt gebruikt voor het configureren/registreren bij Site Recovery Services en voor het bewaken van de status van alle onderdelen. Dit onderdeel is een van de basisbouwstenen van de volledige on-premises Infrastructuur van Azure Site Recovery. Het helpt bij het repliceren van uw workloads naar een andere Azure-regio vanaf een on-premises site en een failover naar Azure in een noodgeval.

Ja, Site Recovery werkt voor zowel toegewezen als gedeelde infrastructuurmodellen.

Nee Tenantidentiteit blijft anoniem. Uw tenants hebben geen toegang nodig tot de Site Recovery-portal. Alleen de beheerder van de serviceprovider communiceert met de portal.

Wanneer u repliceert naar Azure, worden toepassingsgegevens verzonden naar Azure Storage, maar niet naar de Site Recovery-service. Gegevens worden versleuteld tijdens overdracht (HTTPS) en blijven versleuteld in Azure.

Nee Azure-services worden rechtstreeks aan de serviceprovider gefactureerd. Serviceproviders zijn zelf verantwoordelijk voor het genereren van facturen voor hun tenants.

Nee, gegevens worden gerepliceerd naar Azure Storage in uw abonnement. Wanneer u een testfailover (noodherstelanalyse) of een daadwerkelijke failover uitvoert, worden in Site Recovery automatisch virtuele machines in uw abonnement gemaakt.

Ja.

We ondersteunen implementaties van Azure Pack, Cloud Platform System en System Center (2012 en hoger). Meer informatie over Azure Pack en Site Recovery-integratie.

Nee, u kunt virtuele Hyper-V-machines alleen repliceren naar Azure.

Bekijk de prijsgegevens van Site Recovery.

U kunt de prijscalculator gebruiken om de kosten te schatten tijdens het gebruik van Site Recovery.

Voor een gedetailleerde schatting van de kosten voert u het hulpprogramma deployment planner voor VMware of Hyper-V uit en gebruikt u het kostenramingsrapport.

Ja, er worden extra kosten in rekening gebracht voor het gebruik van cacheopslagaccounts bij het repliceren van virtuele machines met Behulp van Site Recovery. De kosten van het cacheopslagaccount blijven hetzelfde wanneer de replicaopslag van het type beheerde schijven of niet-beheerde schijven is.

Ja. Voor elk beveiligd exemplaar worden de eerste 31 dagen geen kosten in rekening gebracht voor Azure Site Recovery. Als u bijvoorbeeld de afgelopen zes maanden tien exemplaren beveiligt en u een 11e instantie verbindt met Azure Site Recovery, worden er voor de eerste 31 dagen geen kosten in rekening gebracht voor het 11e exemplaar. Voor de eerste tien exemplaren worden nog steeds Azure Site Recovery in rekening gebracht, omdat ze meer dan 31 dagen zijn beveiligd.

Ja, hoewel Site Recovery de eerste 31 dagen van een beveiligd exemplaar gratis is, worden er mogelijk kosten in rekening gebracht voor Azure Storage, opslagtransacties en gegevensoverdracht. Voor een herstelde virtuele machine kunnen ook Azure-rekenkosten in rekening worden gebracht.

Er zijn geen afzonderlijke kosten voor noodherstelanalyse. Er worden rekenkosten in rekening gebracht nadat de virtuele machine is gemaakt na de testfailover.

Nee, Site Recovery onderschept gerepliceerde gegevens niet en bevat geen informatie over wat er wordt uitgevoerd op uw virtuele machines of fysieke servers. Er worden alleen replicatiegegevens uitgewisseld tussen uw on-premises Hyper-V-hosts, VMware-hypervisors of fysieke servers en de Azure-opslag of uw secundaire site. Met Site Recovery kunnen deze gegevens niet worden onderschept. Alleen de metagegevens die nodig zijn om replicatie en failover te organiseren, worden naar de Site Recovery-service verzonden.

Site Recovery is ISO 27001:2013, 27018, HIPAA, DPA gecertificeerd en bevindt zich in het proces van SOC2- en FedRAMP JAB-evaluaties.

Ja. Wanneer u een Site Recovery-kluis in een regio maakt, zorgen we ervoor dat alle metagegevens die we nodig hebben om replicatie en failover in te schakelen, binnen de geografische grens van die regio blijven.

Voor virtuele machines en fysieke servers die repliceren naar Azure, worden zowel versleuteling in transit als versleuteling-at-rest (in Azure) ondersteund.

Ja, tls 1.2-protocol wordt standaard afgedwongen voor azure-naar-Azure Site Recovery-scenario's.

Mobility-agents die op de gerepliceerde items zijn geïnstalleerd, communiceren alleen met processerver op TLS 1.2. Communicatie van configuratieserver naar Azure en van processerver naar Azure kan echter op TLS 1.1 of 1.0 staan. Volg de richtlijnen voor het afdwingen van TLS 1.2 op alle configuratieservers en processervers die door u zijn ingesteld.

Alle communicatie tussen de microservices van Azure Site Recovery vindt plaats in het TLS 1.2-protocol. Site Recovery maakt gebruik van beveiligingsproviders die zijn geconfigureerd in het systeem (OS) en maakt gebruik van het nieuwste beschikbare TLS-protocol. U moet TLS 1.2 expliciet inschakelen in het register en vervolgens gebruikt Site Recovery TLS 1.2 voor communicatie met services.

U kunt de beheerde identiteit van de Recovery Services-kluis inschakelen door naar de instelling Identiteit te gaan. Zodra de kluis is geregistreerd bij Microsoft Entra ID, kunt u naar uw opslagaccounts gaan en de volgende roltoewijzingen aan de kluis geven:

• Op Resource Manager gebaseerde opslagaccounts (standaardtype):
  • Inzender
  • Inzender van opslag-blobgegevens
• Op Resource Manager gebaseerde opslagaccounts (Premium-type):
  • Inzender
  • Eigenaar van opslagblobgegevens
• Klassieke opslagaccounts:
  • Inzender voor klassiek opslagaccount
  • Servicerol sleuteloperator voor klassiek opslagaccount

Azure Site Recovery houdt geen wijzigingen in de virtuele bronmachine bij buiten het bron-besturingssysteem. Als u bijvoorbeeld Azure naar Azure-replicatie gebruikt en de grootte van de virtuele bronmachine wijzigt, wordt de wijziging in de grootte van de virtuele bronmachine niet gerepliceerd naar de virtuele doelmachine.

• Virtuele Azure-machines: Site Recovery kan elke workload die wordt uitgevoerd op een ondersteunde virtuele Azure-machine repliceren.
• Virtuele Hyper-V-machines: Site Recovery kan elke workload die wordt uitgevoerd op een virtuele Hyper-V-machine beveiligen.
• Fysieke servers: Site Recovery kan fysieke servers met Windows of Linux beveiligen.
• Virtuele VMware-machines: Site Recovery kan elke workload beveiligen die wordt uitgevoerd op een virtuele VMware-machine.

U kunt Site Recovery gebruiken om de meeste workloads te beveiligen die worden uitgevoerd op een ondersteunde virtuele machine of fysieke server. Site Recovery biedt ondersteuning voor toepassingsbewuste replicatie, zodat apps kunnen worden hersteld naar een intelligente status. Het is geïntegreerd met Microsoft-toepassingen zoals SharePoint, Exchange, Dynamics, SQL Server en Active Directory, en werkt nauw samen met toonaangevende leveranciers, waaronder Oracle, SAP, IBM en Red Hat. Lees hier meer informatie over workloadbeveiliging.

Ja. Wanneer u Site Recovery gebruikt om replicatie en failover in uw filialen te organiseren, krijgt u een uniforme indeling en weergave van al uw werkbelastingen op een centrale locatie. Vanuit het hoofdkantoor kunt u eenvoudig failovers uitvoeren en herstel na noodgeval beheren voor alle filialen. Het is niet nodig de afzonderlijke filialen te bezoeken.

Ja, Site Recovery ondersteunt noodgeval voor virtuele Azure-machines tussen Azure-regio's. Bekijk veelgestelde vragen over herstel na noodgevallen van virtuele Azure-machines. Als u wilt repliceren tussen twee Azure-regio's op hetzelfde continent, gebruikt u onze azure-aanbieding voor herstel na noodgevallen in Azure. U hoeft geen configuratieserver-/processerver- en ExpressRoute-verbindingen in te stellen.

Ja, Site Recovery biedt ondersteuning voor herstel na noodgevallen van on-premises virtuele VMware-machines. Bekijk veelgestelde vragen over herstel na noodgevallen van virtuele VMware-machines.

Ja, Site Recovery biedt ondersteuning voor herstel na noodgevallen van on-premises virtuele Hyper-V-machines. Bekijk veelgestelde vragen over herstel na noodgevallen van virtuele Hyper-V-machines.

Ja, Site Recovery ondersteunt herstel na noodgevallen van on-premises fysieke servers met Windows en Linux naar Azure. Meer informatie over vereisten voor herstel na noodgevallen naar Azure. De fysieke servers worden na een failover uitgevoerd als virtuele machines in Azure. Failback van Azure naar een on-premises fysieke server wordt momenteel niet ondersteund. U kunt alleen een failback uitvoeren naar een virtuele VMware-machine.

Nee, Azure Site Recovery biedt geen ondersteuning voor het verplaatsen van Recovery Services-kluis met beveiligde virtuele machines die erin worden gehost.

Azure Site Recovery repliceert gegevens naar een Azure-opslagaccount of beheerde schijven via een openbaar eindpunt. Replicatie kan echter ook worden uitgevoerd via site-naar-site-VPN. Met site-naar-site-VPN-connectiviteit kunnen organisaties bestaande netwerken verbinden met Azure of Azure-netwerken met elkaar. Site-naar-site-VPN vindt plaats via IPSec-tunneling via internet, met behulp van bestaande on-premises netwerkapparatuur en netwerkapparaten in Azure, systeemeigen functies zoals Vpn Gateway (Virtual Private Network) van Azure of opties van derden, zoals Check Point CloudGaurd, Palo Alto NextGen Firewall.

• Privéconnectiviteit via het openbare internet met Microsoft Edge
• Recovery Service-kluizen die zijn geconfigureerd voor beveiliging met privé-eindpunten
• Replicatie via een privénetwerkverbinding van de klant
• Eenvoudige overgang naar 'Toekomstige status'
• Geen SLA en mogelijk hogere latentie
• Vereist een beschikbaarheid van een on-premises VPN-apparaat

Onze partner Riverbed biedt gedetailleerde richtlijnen voor het werken met Azure Site Recovery. Bekijk de oplossingshandleiding.

Ja, ExpressRoute kan worden gebruikt om on-premises virtuele machines te repliceren naar Azure.

• Azure Site Recovery repliceert gegevens naar een Azure Storage via een openbaar eindpunt. U moet Microsoft-peering instellen of een bestaande openbare peering gebruiken (afgeschaft voor nieuwe circuits) om ExpressRoute te gebruiken voor Site Recovery-replicatie.
• Microsoft-peering is het aanbevolen routeringsdomein voor replicatie.
• Replicatie wordt alleen ondersteund via privépeering wanneer privé-eindpunten zijn ingeschakeld voor de kluis.
• Als u VMware-machines of fysieke machines beveiligt, moet u ervoor zorgen dat ook aan de netwerkvereisten voor de configuratieserver wordt voldaan. Verbinding maken iviteit van specifieke URL's is vereist voor de configuratieserver voor het indelen van Site Recovery-replicatie. ExpressRoute kan niet worden gebruikt voor deze connectiviteit.
• Nadat de virtuele machines zijn overgeschakeld naar een virtueel Azure-netwerk, kunt u deze openen met behulp van de persoonlijke peering-installatie met het virtuele Azure-netwerk.

Het gebruik van opslagaccounts als doelopslag wordt niet ondersteund door Azure Site Recovery. Het wordt aanbevolen om beheerde schijven te gebruiken als doelopslag voor uw machines. Beheerde schijven ondersteunen alleen het LRS-type voor gegevenstolerantie.

• Hyper-V: Virtuele Hyper-V-machines kunnen elke 30 seconden (met uitzondering van Premium Storage) of vijf minuten worden gerepliceerd.
• Virtuele Azure-machines, virtuele VMware-machines, fysieke servers: hier is een replicatiefrequentie niet relevant. Replicatie is continu.

Uitgebreide of gekoppelde replicatie wordt niet ondersteund. Vraag deze functie aan in het feedbackforum.

Dit wordt niet ondersteund. Vraag deze functie aan in het feedbackforum.

Dit wordt ondersteund wanneer u virtuele VMware-machines en virtuele Hyper-V-machines repliceert naar Azure met behulp van Azure Portal.

Dynamische schijven worden ondersteund bij het repliceren van virtuele Hyper-V-machines en bij het repliceren van virtuele VMware-machines en fysieke machines naar Azure. De besturingssysteemschijf moet een basisschijf zijn.

Ja. Meer informatie over bandbreedtebeperking vindt u in deze artikelen:

• Capaciteitsplanning voor het repliceren van virtuele VMware-machines en fysieke servers
• Capaciteitsplanning voor het repliceren van virtuele Hyper-V-machines naar Azure

Ja. Azure Site Recovery voor Linux Operation System ondersteunt aangepaste scripts voor toepassingen voor app-consistentie. Het aangepaste script met opties vooraf en na wordt gebruikt door de Azure Site Recovery Mobility-agent tijdens app-consistentie. Hieronder vindt u de stappen om deze in te schakelen.

1. Meld u aan als root op de computer.

2. Wijzig de map naar de installatielocatie van de Azure Site Recovery Mobility-agent. Standaard is '/usr/local/ASR'
   # cd /usr/local/ASR

3. Map wijzigen in 'VX/scripts' onder installatielocatie
   # cd VX/scripts

4. Maak een bash-shellscript met de naam 'customscript.sh' met uitvoermachtigingen voor de hoofdgebruiker.
   a. Het script moet ondersteuning bieden voor de opdrachtregelopties '--pre' en '--post' (let op de dubbele streepjes)
   b. Wanneer het script wordt aangeroepen met pre-option, moet het de invoer/uitvoer van de toepassing blokkeren en wanneer het wordt aangeroepen met post-option, moet het de invoer/uitvoer van de toepassing ontdooien.
   c. Een voorbeeldsjabloon -
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. Voeg de invoer-/uitvoeropdrachten blokkeren en de blokkering op in pre- en poststappen voor de toepassingen waarvoor app-consistentie is vereist. U kunt ervoor kiezen om een ander script toe te voegen waarin deze worden opgegeven en aangeroepen vanuit 'customscript.sh' met vooraf en na de opties.

Een replicatiebeleid definieert de instellingen voor de bewaargeschiedenis van herstelpunten. Het beleid definieert ook de frequentie van app-consistente momentopnamen. Standaard maakt Azure Site Recovery een nieuw replicatiebeleid met standaardinstellingen van:

• Eén dag voor de bewaargeschiedenis van herstelpunten.
• Geen app-consistente momentopnamen.

Een crashconsistent herstelpunt bevat de gegevens op de schijf alsof u het netsnoer van de server hebt opgehaald tijdens de momentopname. Het crashconsistente herstelpunt bevat niets dat zich in het geheugen bevond toen de momentopname werd gemaakt.

Tegenwoordig kunnen de meeste toepassingen goed herstellen van crashconsistente momentopnamen. Een crashconsistent herstelpunt is voldoende voor besturingssystemen en toepassingen zonder database, zoals bestandsservers, DHCP-servers en afdrukservers.

Site Recovery maakt elke 5 minuten een crashconsistent herstelpunt.

Toepassingsconsistente herstelpunten worden gemaakt op basis van toepassingsconsistente momentopnamen. Toepassingsconsistente herstelpunten leggen dezelfde gegevens vast als crashconsistente momentopnamen, terwijl ook gegevens worden vastgelegd in het geheugen en alle transacties die worden verwerkt.

Vanwege hun extra inhoud zijn toepassingsconsistente momentopnamen het meest betrokken en nemen ze het langst. We raden toepassingsconsistente herstelpunten aan voor databasebesturingssystemen en toepassingen zoals SQL Server.

Toepassingsconsistente herstelpunten leggen alle gegevens in het geheugen en in het proces vast. Omdat herstelpunten die gegevens vastleggen, hebben ze framework zoals Volume Shadow Copy Service in Windows nodig om de toepassing stil te leggen. Als het opnameproces regelmatig plaatsvindt, kan dit van invloed zijn op de prestaties wanneer de workload al bezet is. Het is niet raadzaam om lage frequentie te gebruiken voor app-consistente herstelpunten voor niet-databaseworkloads. Zelfs voor databaseworkload is 1 uur voldoende.

Site Recovery kan een toepassingsconsistent herstelpunt maken met een minimale frequentie van 1 uur.

Laten we een voorbeeld van een replicatiebeleid bekijken om te begrijpen hoe Site Recovery herstelpunten genereert. Dit replicatiebeleid heeft een herstelpunt met een bewaarvenster van 1 dag en een app-consistente frequentiemomentopname van 1 uur.

Site Recovery maakt elke 5 minuten een crashconsistent herstelpunt. U kunt deze frequentie niet wijzigen. Voor de meest recente 2 uur kunt u kiezen uit 24 crashconsistente punten en 2 app-consistente punten. Naarmate de tijd vordert, verwijdert Site Recovery alle herstelpunten na de afgelopen 2 uur en slaat slechts één herstelpunt per uur op tot 24 uur van de dag.

In de volgende schermopname ziet u het voorbeeld. In de schermopname:

• Binnen de afgelopen 2 uur zijn er herstelpunten met een frequentie van 5 minuten.

• Na de afgelopen 2 uur houdt Site Recovery slechts één herstelpunt per uur bij.

  

Het oudste herstelpunt dat u kunt gebruiken, is 15 dagen met een beheerde schijf en drie dagen met een niet-beheerde schijf.

Nee, Site Recovery bewaart al uw vorige herstelpunten. Afhankelijk van het bewaarvenster van de herstelpunten vervangt Site Recovery het oudste punt alleen als er nieuwe punten worden gegenereerd. Vanwege het probleem kan Site Recovery geen nieuwe herstelpunten genereren. Totdat er nieuwe herstelpunten zijn, blijven alle oude punten behouden nadat u het bewaarvenster hebt bereikt.

Ga naar Site Recovery Vault>Site Recovery-infrastructuurreplicatiebeleid.> Selecteer het beleid dat u wilt bewerken en sla de wijzigingen op. Elke wijziging is ook van toepassing op alle bestaande replicaties.

Het eerste herstelpunt dat wordt gegenereerd, heeft de volledige kopie. Eventuele opeenvolgende herstelpunten hebben deltawijzigingen.

Ja, als u de bewaarperiode van één dag tot drie dagen verhoogt, slaat Site Recovery de herstelpunten gedurende een extra twee dagen op. Voor de extra tijd worden opslagkosten in rekening gebracht, omdat er 12 extra herstelpunten zijn die moeten worden opgeslagen met een toename van de bewaarperiode van één dag tot drie dagen. Een enkel herstelpunt kan bijvoorbeeld verschillen van 10 GB hebben, met een kosten per GB van $ 0,16 per maand. Extra kosten zijn $ 1,60 × 12 per maand.

U hebt toegang tot de virtuele Azure-machines via een beveiligde internetverbinding, via een site-naar-site-VPN of via Azure ExpressRoute. U moet een aantal dingen voorbereiden om verbinding te kunnen maken. Meer informatie.

Azure is ontworpen voor herstelbaarheid. Site Recovery is al ontworpen voor failover naar een secundair Azure-datacenter, in overeenstemming met de Azure SLA. Als dit gebeurt, zorgen we ervoor dat uw metagegevens en kluizen binnen dezelfde geografische regio blijven als die u hebt gekozen voor uw kluis.

U kunt een ongeplande failover vanuit de secundaire site activeren. Site Recovery heeft geen connectiviteit vanuit de primaire site nodig om de failover uit te voeren.

Failover wordt niet automatisch uitgevoerd. U start failovers met één klik in de portal of u kunt Site Recovery PowerShell gebruiken om een failover te activeren. Failback is een eenvoudige actie in de Site Recovery-portal.

Als u wilt automatiseren, kunt u on-premises Orchestrator of Operations Manager gebruiken om een storing in een virtuele machine te detecteren en vervolgens de failover te activeren met behulp van de SDK.

• Lees meer over herstelplannen.
• Lees meer over failover.
• Meer informatie over failback van virtuele VMware-machines en fysieke servers

Ja, u kunt het herstel van de alternatieve locatie gebruiken om een failback uit te voeren naar een andere host van Azure.

• Voor virtuele VMware-machines
• Voor virtuele Hyper-V-machines

Zodra een machine van de bronlocatie is overgeschakeld naar de doellocatie, zijn er drie opties beschikbaar waaruit u kunt kiezen. Alle drie dienen verschillende doeleinden -

1. Volledige migratie betekent dat u niet meer teruggaat naar de bronlocatie. U bent gemigreerd naar de doelregio en nu bent u klaar. Als u op Volledige migratie klikt, worden doorvoeren geactiveerd en schakelt u replicatie intern uit.
2. Doorvoer betekent dat dit niet het einde van het replicatieproces is. Het replicatie-item samen met alle configuraties blijft behouden en u kunt op een later moment opnieuw beveiligen selecteren om de replicatie van uw machines weer naar de bronregio in te schakelen.
3. Als u Replicatie uitschakelt, wordt de replicatie uitgeschakeld en worden alle gerelateerde configuraties verwijderd. Dit heeft geen invloed op de reeds bestaande computer in de doelregio.

Ja. U kunt Site Recovery-werkstromen automatiseren met behulp van de REST API, PowerShell of de Azure SDK. Momenteel ondersteunde scenario's voor het implementeren Site Recovery met behulp van PowerShell:

• Virtuele Hyper-V-machines in VM-clouds repliceren naar Azure PowerShell Resource Manager
• Virtuele Hyper-V-machines repliceren zonder VMM naar Azure PowerShell Resource Manager
• VMware repliceren naar Azure met PowerShell Resource Manager

Nee, de buitengebruikstelling van de AzureRM-module heeft geen invloed op de werking van automatische updates van Site Recovery. Er zijn geen wijzigingen nodig voor het interne runbook en de REST API die wordt gebruikt, blijft werken zoals bedoeld met het Automation-account.

Meer informatie over nieuwe updates en informatie over samenvouwen.

Volgende stappen

• Lees het Site Recovery-overzicht