Allmänna frågor om Azure Site Recovery

Site Recovery bidrar till din bcdr-strategi för affärskontinuitet och haveriberedskap genom att samordna och automatisera replikering av virtuella Azure-datorer mellan regioner, lokala virtuella datorer och fysiska servrar till Azure och lokala datorer till ett sekundärt datacenter. Läs mer.

Nej, Azure Site Recovery stöder inte Docker-arbetsbelastningar som körs på virtuella datorer. Om du vill skydda dessa virtuella datorer med Site Recovery undantar du de diskar som har Docker installerat på dem.

Site Recovery har vidtagit olika åtgärder för att säkerställa dataintegriteten. En säker anslutning upprättas mellan alla tjänster med hjälp av HTTPS-protokollet. Detta säkerställer att skadlig kod eller externa entiteter inte kan manipulera data. Ett annat mått som vidtas är att använda kontrollsummor. Dataöverföringen mellan källa och mål utförs av datakontrollsummor för data mellan dem. Detta säkerställer att de överförda data är konsekventa.

Azure stöder inte beständiga MAC-adresser, så programvara med MAC-baserade licensmodeller kan inte användas för både lokal migrering eller haveriberedskap.

Nej, Azure Site Recovery stöder för närvarande inte tillfälliga diskar.

Microsoft Azure Recovery Services-agenten används för att konfigurera/registrera med Site Recovery-tjänster och för att övervaka hälsotillståndet för alla komponenter. Den här komponenten är en av de grundläggande byggstenarna i hela den lokala Azure Site Recovery-infrastrukturen. Det hjälper dig att replikera dina arbetsbelastningar till en annan Azure-region från en lokal plats och redundansväxla till Azure i en katastrof.

Ja, Site Recovery stöder både dedikerade och delade infrastrukturmodeller.

Nej. Klientorganisationens identitet förblir anonym. Klienterna behöver inte åtkomst till Site Recovery-portalen. Endast tjänstproviderns administratör interagerar med portalen.

När du replikerar till Azure skickas programdata till Azure Storage men inte till Site Recovery-tjänsten. Data krypteras under överföring (HTTPS) och förblir krypterade i Azure.

Nej. Azures faktureringsrelation sker direkt med tjänstprovidern. Tjänstprovidern ansvarar för att skapa fakturor för sina klienter.

Nej, Data replikeras till Azure Storage i din prenumeration. När du utför ett redundanstest (haveriberedskapstest) eller en faktisk redundansväxling skapar Site Recovery automatiskt virtuella datorer i din prenumeration.

Ja.

Vi stöder Distributioner baserade på Azure Pack, Cloud Platform System och System Center (2012 och senare). Läs mer om Integrering av Azure Pack och Site Recovery.

Nej, du kan bara replikera virtuella Hyper-V-datorer till Azure.

Granska prisinformationen för Site Recovery.

Du kan använda priskalkylatorn för att beräkna kostnader när du använder Site Recovery.

För detaljerad kostnadsuppskattning kör du distributionsplaneringsverktyget för VMware eller Hyper-V och använder rapporten för kostnadsuppskattning.

Ja, det finns extra avgifter för användning av cachelagringskonto vid replikering av virtuella datorer med Hjälp av Site Recovery. Kostnaderna för cachelagringskontot förblir desamma när repliklagringen är av typen hanterade diskar eller ohanterade diskar.

Ja. Varje skyddad instans innebär att inga Azure Site Recovery-avgifter debiteras de första 31 dagarna. Om du till exempel har skyddat 10 instanser under de senaste sex månaderna och ansluter en elfte instans till Azure Site Recovery, debiteras inga avgifter för den elfte instansen under de första 31 dagarna. De första 10 instanserna fortsätter att debiteras med Azure Site Recovery-avgifter eftersom de har skyddats i mer än 31 dagar.

Ja, även om Site Recovery är kostnadsfritt under de första 31 dagarna i en skyddad instans kan du debiteras för Azure Storage, lagringstransaktioner och dataöverföring. En återställd virtuell dator kan också medföra avgifter för Azure-beräkningen.

Det finns ingen separat kostnad för haveriberedskapstest. Det kommer att finnas beräkningsavgifter efter att den virtuella datorn har skapats efter redundanstestet.

Nej, Site Recovery fångar inte upp replikerade data och har ingen information om vad som körs på dina virtuella datorer eller fysiska servrar. Replikeringsdata utbyts mellan lokala Hyper-V-värdar, VMware-hypervisorer eller fysiska servrar och Azure-lagring eller din sekundära plats. Site Recovery har inte möjlighet att fånga upp dessa data. Endast de metadata som behövs för att samordna replikeringen och redundansen skickas till Site Recovery-tjänsten.

Site Recovery är ISO 27001:2013, 27018, HIPAA, DPA-certifierad och håller på att utvärderas av SOC2 och FedRAMP JAB.

Ja. När du skapar ett Site Recovery-valv i en region ser vi till att alla metadata som vi behöver för att aktivera och samordna replikering och redundans förblir inom regionens geografiska gräns.

För virtuella datorer och fysiska servrar som replikeras till Azure stöds både kryptering under överföring och kryptering i vila (i Azure).

Ja, TLS 1.2-protokollet tillämpas som standard för Azure-till-Azure Site Recovery-scenariot.

Mobilitetsagenter som är installerade på de replikerade objekten kommunicerar endast med processservern på TLS 1.2. Kommunikationen från Configuration Server till Azure och från Process Server till Azure kan dock ske på TLS 1.1 eller 1.0. Följ riktlinjerna för att framtvinga TLS 1.2 på alla konfigurationsservrar och processerver som du har konfigurerat.

All kommunikation mellan mikrotjänsterna i Azure Site Recovery sker i TLS 1.2-protokollet. Site Recovery använder säkerhetsprovidrar som konfigurerats i systemet (OS) och använder det senaste tillgängliga TLS-protokollet. Man måste uttryckligen aktivera TLS 1.2 i registret och sedan börjar Site Recovery använda TLS 1.2 för kommunikation med tjänster.

Du kan växla till den hanterade identiteten för Recovery Services-valvet genom att gå till identitetsinställningen. När valvet har registrerats med Microsoft Entra-ID kan du gå till dina lagringskonton och ge följande rolltilldelningar till valvet:

• Resource Manager-baserade lagringskonton (standardtyp):
  • Deltagare
  • Storage Blob datadeltagare
• Resource Manager-baserade lagringskonton (Premium-typ):
  • Deltagare
  • Storage Blob Data-ägare
• Klassiska lagringskonton:
  • Klassisk lagringskontodeltagare
  • Tjänstroll för nyckeloperator för klassiskt lagringskonto

Azure Site Recovery spårar inte ändringar av den virtuella källdatorn utanför källoperativsystemet. Om du till exempel använder Azure till Azure-replikering och ändrar storleken på den virtuella källdatorn replikeras inte storleken på den virtuella källdatorn till den virtuella måldatorn.

• Virtuella Azure-datorer: Site Recovery kan replikera alla arbetsbelastningar som körs på en virtuell Azure-dator som stöds.
• Virtuella Hyper-V-datorer: Site Recovery kan skydda alla arbetsbelastningar som körs på en virtuell Hyper-V-dator.
• Fysiska servrar: Site Recovery kan skydda fysiska servrar som kör Windows eller Linux.
• Virtuella VMware-datorer: Site Recovery kan skydda alla arbetsbelastningar som körs på en virtuell VMware-dator.

Du kan använda Site Recovery för att skydda de flesta arbetsbelastningar som körs på en virtuell dator som stöds eller fysisk server. Site Recovery har stöd för programmedveten replikering så att appar kan återställas till ett intelligent tillstånd. Den integreras med Microsoft-program som SharePoint, Exchange, Dynamics, SQL Server och Active Directory och fungerar nära ledande leverantörer, inklusive Oracle, SAP, IBM och Red Hat. Lär dig mer om arbetsbelastningsskydd.

Ja. När du använder Site Recovery för att samordna replikering och redundans på avdelningskontoren får du en enhetlig orkestrering och vy över alla dina arbetsbelastningar på avdelningskontoret på en central plats. Du kan enkelt köra redundansväxlingar och administrera haveriberedskap för alla avdelningskontor från huvudkontoret, utan att besöka avdelningskontoren.

Ja, Site Recovery stöder haveri för virtuella Azure-datorer mellan Azure-regioner. Läs vanliga frågor om haveriberedskap för virtuella Azure-datorer. Om du vill replikera mellan två Azure-regioner på samma kontinent använder du vårt azure-till Azure-haveriberedskapserbjudande. Du behöver inte konfigurera konfigurationsservern/processervern och ExpressRoute-anslutningarna.

Ja, Site Recovery stöder haveriberedskap för lokala virtuella VMware-datorer. Läs vanliga frågor om haveriberedskap för virtuella VMware-datorer.

Ja, Site Recovery stöder haveriberedskap för lokala virtuella Hyper-V-datorer. Läs vanliga frågor om haveriberedskap för virtuella Hyper-V-datorer.

Ja, Site Recovery stöder haveriberedskap för lokala fysiska servrar som kör Windows och Linux till Azure. Läs mer om kraven för haveriberedskap till Azure. De fysiska servrarna körs som virtuella datorer i Azure efter redundansväxling. Återställning efter fel från Azure till en lokal fysisk server stöds inte för närvarande. Du kan bara återställa till en virtuell VMware-dator.

Nej, Azure Site Recovery stöder inte flytt av Recovery Services-valv som har skyddade virtuella datorer i det.

Azure Site Recovery replikerar data till ett Azure Storage-konto eller hanterade diskar via en offentlig slutpunkt. Replikering kan dock utföras även via plats-till-plats-VPN. Med plats-till-plats-VPN-anslutning kan organisationer ansluta befintliga nätverk till Azure eller Azure-nätverk till varandra. Plats-till-plats-VPN sker via IPSec-tunneltrafik via Internet, vilket utnyttjar befintlig lokal nätverksutrustning och nätverksinstallationer i Azure, antingen inbyggda funktioner som Azure Virtual Private Network (VPN) Gateway eller alternativ från tredje part, till exempel Check Point CloudGaurd, Palo Alto NextGen Firewall.

• Privat anslutning via offentligt Internet till Microsoft Edge
• Recovery Service-valv konfigurerade för säkerhet med privata slutpunkter
• Replikering över kundens privata virtuella nätverksanslutning
• Enkel övergång till "Framtida tillstånd"
• Inget serviceavtal och potentiellt högre svarstid
• Kräver en lokal VPN-enhetstillgänglighet

Vår partner Riverbed ger detaljerad vägledning om hur du arbetar med Azure Site Recovery. Läs deras lösningsguide.

Ja, ExpressRoute kan användas för att replikera lokala virtuella datorer till Azure.

• Azure Site Recovery replikerar data till en Azure Storage via en offentlig slutpunkt. Du måste konfigurera Microsoft-peering eller använda en befintlig offentlig peering (inaktuell för nya kretsar) för att använda ExpressRoute för Site Recovery-replikering.
• Microsoft-peering är den rekommenderade routningsdomänen för replikering.
• Replikering stöds endast via privat peering när privata slutpunkter är aktiverade för valvet.
• Om du skyddar VMware-datorer eller fysiska datorer kontrollerar du att även nätverkskraven för konfigurationsservern är uppfyllda. Anslut för specifika URL:er krävs av konfigurationsservern för orkestrering av Site Recovery-replikering. ExpressRoute kan inte användas för den här anslutningen.
• När de virtuella datorerna har redväxats till ett virtuellt Azure-nätverk kan du komma åt dem med hjälp av konfigurationen av privat peering med det virtuella Azure-nätverket.

Användning av lagringskonton som mållagring stöds inte av Azure Site Recovery. Vi rekommenderar att du i stället använder hanterade diskar som mållagring för dina datorer. Hanterade diskar stöder endast LRS-typ för dataåterhämtning.

• Hyper-V: Virtuella Hyper-V-datorer kan replikeras var 30:e sekund (förutom premiumlagring) eller fem minuter.
• Virtuella Azure-datorer, virtuella VMware-datorer, fysiska servrar: En replikeringsfrekvens är inte relevant här. Replikeringen är kontinuerlig.

Utökad eller länkad replikering stöds inte. Begär den här funktionen i feedbackforumet.

Detta stöds inte. Begär den här funktionen i feedbackforumet.

Detta stöds när du replikerar virtuella VMware-datorer och virtuella Hyper-V-datorer till Azure med hjälp av Azure-portalen.

Dynamiska diskar stöds vid replikering av virtuella Hyper-V-datorer och vid replikering av virtuella VMware-datorer och fysiska datorer till Azure. Operativsystemdisken måste vara en grundläggande disk.

Ja. Du kan läsa mer om begränsning av bandbredd i dessa artiklar:

• Kapacitetsplanering för replikering av virtuella VMware-datorer och fysiska servrar
• Kapacitetsplanering för replikering av virtuella Hyper-V-datorer till Azure

Ja. Azure Site Recovery för Linux-åtgärdssystemet har stöd för programanpassade skript för appkonsekvens. Det anpassade skriptet med för- och efteralternativ används av Azure Site Recovery Mobility Agent under appkonsekvens. Nedan visas stegen för att aktivera den.

1. Logga in som rot i datorn.

2. Ändra katalog till installationsplatsen för Azure Site Recovery Mobility Agent. Standardvärdet är "/usr/local/ASR"
   # cd /usr/local/ASR

3. Ändra katalogen till "VX/scripts" under installationsplatsen
   # cd VX/scripts

4. Skapa ett bash shell-skript med namnet "customscript.sh" med körningsbehörigheter för rotanvändare.
   a. Skriptet bör ha stöd för kommandoradsalternativen "--pre" och "--post" (Observera de dubbla bindestrecken)
   b. När skriptet anropas med förhandsalternativet ska det frysa programmets indata/utdata och när det anropas med efteralternativet bör det tina programmets indata/utdata.
   c. En exempelmall –
   

   # 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. Lägg till kommandona freeze och unfreeze input/output i för- och eftersteg för program som kräver appkonsekvens. Du kan välja att lägga till ett annat skript som anger dem och anropa det från "customscript.sh" med för- och efteralternativ.

En replikeringsprincip definierar inställningarna för kvarhållningshistoriken för återställningspunkter. Principen definierar också frekvensen för appkonsekventa ögonblicksbilder. Som standard skapar Azure Site Recovery en ny replikeringsprincip med standardinställningarna:

• En dag för kvarhållningshistoriken för återställningspunkter.
• Inga appkonsekventa ögonblicksbilder.

En kraschkonsekvent återställningspunkt har data på disken som om du hämtade strömkabeln från servern under ögonblicksbilden. Den kraschkonsekventa återställningspunkten innehåller inte något som fanns i minnet när ögonblicksbilden togs.

I dag kan de flesta program återställas väl från kraschkonsekventa ögonblicksbilder. En kraschkonsekvent återställningspunkt räcker vanligtvis för operativsystem utan databas och program som filservrar, DHCP-servrar och utskriftsservrar.

Site Recovery skapar en kraschkonsekvent återställningspunkt var femte minut.

Programkonsekventa återställningspunkter skapas från programkonsekventa ögonblicksbilder. Programkonsekventa återställningspunkter samlar in samma data som kraschkonsekventa ögonblicksbilder samtidigt som data samlas in i minnet och alla pågående transaktioner.

På grund av deras extra innehåll är programkonsekventa ögonblicksbilder de mest involverade och tar längst tid. Vi rekommenderar programkonsekventa återställningspunkter för databasoperativsystem och program som SQL Server.

Programkonsekventa återställningspunkter samlar in alla data i minnet och i processen. Eftersom återställningspunkter samlar in dessa data, kräver de ramverk som Volume Shadow Copy Service i Windows för att skicka information till programmet. Om insamlingsprocessen är frekvent kan det påverka prestanda när arbetsbelastningen redan är upptagen. Vi rekommenderar inte att du använder låg frekvens för appkonsekventa återställningspunkter för icke-databasarbetsbelastningar. Även för databasarbetsbelastning räcker det med 1 timme.

Site Recovery kan skapa en programkonsekvent återställningspunkt med en minsta frekvens på 1 timme.

För att förstå hur Site Recovery genererar återställningspunkter ska vi se ett exempel på en replikeringsprincip. Den här replikeringsprincipen har en återställningspunkt med ett kvarhållningsfönster på 1 dag och en appkonsekvent ögonblicksbild av frekvensen på 1 timme.

Site Recovery skapar en kraschkonsekvent återställningspunkt var femte minut. Du kan inte ändra den här frekvensen. Under de senaste 2 timmarna kan du välja mellan 24 kraschkonsekventa punkter och 2 appkonsekventa punkter. När tiden går rensar Site Recovery alla återställningspunkter utöver de senaste 2 timmarna och sparar bara en återställningspunkt per timme i upp till 24 timmar på dagen.

Följande skärmbild illustrerar exemplet. På skärmbilden:

• Under de senaste 2 timmarna finns det återställningspunkter med en frekvens på 5 minuter.

• Utöver de senaste 2 timmarna behåller Site Recovery bara en återställningspunkt per timme.

  

Den äldsta återställningspunkten som du kan använda är 15 dagar med Hanterad disk och tre dagar med ohanterad disk.

Nej, Site Recovery behåller alla dina tidigare återställningspunkter. Beroende på kvarhållningsfönstret för återställningspunkter ersätter Site Recovery endast den äldsta punkten om den genererar nya punkter. På grund av problemet kan Site Recovery inte generera några nya återställningspunkter. Tills det finns nya återställningspunkter finns alla gamla punkter kvar när du har nått kvarhållningsfönstret.

Gå till Site Recovery Vault>Site Recovery Infrastructure>Replication-principer. Välj den princip som du vill redigera och spara ändringarna. Alla ändringar gäller även för alla befintliga repliker.

Den första återställningspunkten som genereras har den fullständiga kopian. Alla efterföljande återställningspunkter har deltaändringar.

Ja, om du ökar kvarhållningsperioden från en dag till tre dagar sparar Site Recovery återställningspunkterna ytterligare två dagar. Den extra tiden medför lagringsavgifter eftersom det kommer att finnas ytterligare 12 återställningspunkter som måste sparas med en ökning av kvarhållningsperioden från en dag till tre dagar. En enskild återställningspunkt kan till exempel ha deltaändringar på 10 GB med en kostnad per GB på 0,16 USD per månad. Ytterligare avgifter skulle vara $ 1,60 × 12 per månad.

Du kan komma åt de virtuella Azure-datorerna via en säker Internetanslutning, via ett plats-till-plats-VPN eller via Azure ExpressRoute. Du måste förbereda ett antal saker för att kunna ansluta. Läs mer.

Azure är utformat med flexibilitet i fokus. Site Recovery är redan konstruerat för redundans till ett sekundärt Azure-datacenter, i enlighet med Azure SLA. Om detta händer ser vi till att dina metadata och valv förblir inom samma geografiska region som du valde för valvet.

Du kan utlösa en oplanerad redundansväxling från den sekundära platsen. Site Recovery behöver ingen anslutning från den primära platsen för att utföra redundansväxlingen.

Den sker inte automatiskt. Du initierar redundansväxlingar med ett enda klick i portalen, eller så kan du använda Site Recovery PowerShell för att utlösa en redundansväxling. Återställning efter fel är en enkel åtgärd i Site Recovery-portalen.

För att automatisera kan du använda lokal Orchestrator eller Operations Manager för att identifiera ett fel på en virtuell dator och sedan utlösa redundansväxlingen med hjälp av SDK.

• Läs mer om återställningsplaner.
• Läs mer om redundans.
• Läs mer om att återställa virtuella VMware-datorer och fysiska servrar

Ja, du kan använda den alternativa platsåterställningen för att återställa till en annan värd än Azure.

• För virtuella VMware-datorer
• För virtuella Hyper-V-datorer

När en dator från källplatsen har växlats över till målplatsen finns det tre alternativ som du kan välja mellan. Alla tre har olika syften -

1. Fullständig migrering innebär att du inte längre går tillbaka till källplatsen. Du migrerade över till målregionen och nu är du klar. Om du klickar på Slutför migrering utlöses Incheckning och sedan Inaktivera replikering internt.
2. Incheckning innebär att detta inte är slutet på replikeringsprocessen. Replikeringsobjektet tillsammans med all konfiguration finns kvar och du kan trycka på Skydda igen vid en senare tidpunkt för att aktivera replikering av dina datorer tillbaka till källregionen.
3. Inaktivera Replikering inaktiverar replikeringen och tar bort all relaterad konfiguration. Det påverkar inte den redan befintliga datorn i målregionen.

Ja. Du kan automatisera Site Recovery-arbetsflöden med hjälp av REST API, PowerShell eller Azure SDK. Scenarier som stöds för att distribuera Site Recovery med hjälp av PowerShell:

• Replikera virtuella Hyper-V-datorer i VMM-moln till Azure PowerShell Resource Manager
• Replikera virtuella Hyper-V-datorer utan VMM till Azure PowerShell Resource Manager
• Replikera VMware till Azure med PowerShell Resource Manager

Nej, tillbakadragningen av AzureRM-modulen påverkar inte hur automatiska Site Recovery-uppdateringar fungerar. Inga ändringar behövs för den interna runbooken och REST-API:et som används fortsätter att fungera som avsett med automationskontot.

Lär dig mer om nya uppdateringar och få samlad information.

Nästa steg

• Läs Site Recovery-översikten