Általános kérdések az Azure Site Recovery szolgáltatásról

A Site Recovery hozzájárul az üzletmenet-folytonossági és vészhelyreállítási (BCDR) stratégiához azáltal, hogy az Azure-beli virtuális gépek régiók, helyszíni virtuális gépek és fizikai kiszolgálók közötti replikálását vezénylik és automatizálják az Azure-ba, a helyszíni gépeket pedig egy másodlagos adatközpontba. További információ.

Nem, az Azure Site Recovery nem támogatja a virtuális gépeken futó Docker-számítási feladatokat. Ha ezeket a virtuális gépeket a Site Recoveryvel szeretné védeni, zárja ki azokat a lemezeket, amelyeken telepítve van a Docker.

A Site Recovery különböző intézkedéseket hozott az adatintegritás biztosítása érdekében. A HTTPS protokoll használatával biztonságos kapcsolat jön létre az összes szolgáltatás között. Ez biztosítja, hogy bármely kártevő vagy külső entitás ne módosítsa az adatokat. Egy másik intézkedés az ellenőrzőösszegek használata. A forrás és a cél közötti adatátvitelt a közöttük lévő adatok számítási ellenőrzőösszegei hajtják végre. Ez biztosítja, hogy az átvitt adatok konzisztensek legyenek.

Az Azure nem támogatja az állandó MAC-címeket, ezért a MAC-alapú licencmodellekkel rendelkező szoftverek nem használhatók helyszíni és Azure-beli migráláshoz vagy vészhelyreállításhoz.

Nem, az Azure Site Recovery jelenleg nem támogatja a rövid élettartamú lemezeket.

A Microsoft Azure Recovery Services-ügynök a Site Recovery-szolgáltatások konfigurálására/regisztrálására, valamint az összes összetevő állapotának figyelésére szolgál. Ez az összetevő a teljes Helyszíni Azure Site Recovery-infrastruktúra egyik alapvető építőeleme. Segít replikálni a számítási feladatokat egy másik Azure-régióba egy helyszíni helyről, és katasztrófa esetén feladatátvételt végrehajtani az Azure-ba.

Igen, a Site Recovery támogatja mind a dedikált, mind a megosztott infrastruktúra-modelleket.

Szám A bérlői identitás névtelen marad. A bérlőnek nincs szüksége a Site Recovery-portál elérésére. Csak a szolgáltatást nyújtó rendszergazdája kommunikál a portállal.

Az Azure-ba történő replikáláskor az alkalmazásadatok az Azure Storage-ba kerülnek, a Site Recovery szolgáltatásba azonban nem. Az adatok átvitel közben titkosítottak (HTTPS), és titkosítva maradnak az Azure-ban.

Szám Az Azure közvetlenül a szolgáltatóval áll számlázási kapcsolatban. A bérlők felé történő számlázásért a szolgáltató felel.

Nem, az adatok replikálva lesznek az Azure Storage-ba az előfizetésében. Feladatátvételi teszt (vészhelyreállítási gyakorlat) vagy tényleges feladatátvétel végrehajtásakor a Site Recovery automatikusan létrehoz virtuális gépeket az előfizetésében.

Igen.

Támogatjuk az Azure Pack, a felhőplatform-rendszer és a System Center-alapú (2012-ben és újabb verziókban) üzemelő példányokat. További információ az Azure Pack és a Site Recovery integrációjáról.

Nem, a Hyper-V virtuális gépeket csak az Azure-ba replikálhatja.

Tekintse át a Site Recovery díjszabásának részleteit.

A díjkalkulátorral felbecsülheti a Site Recovery használata során felmerülő költségeket.

A költségek részletes becsléséhez futtassa a VMware vagy Hyper-V üzembehelyezési tervező eszközét, és használja a költségbecslési jelentést.

Igen, a gyorsítótár-tárfiókok használatának többletköltségei vannak a virtuális gépek Site Recovery használatával történő replikálásakor. A gyorsítótár tárfiókjának költségei változatlanok maradnak, ha a replikatároló felügyelt vagy nem felügyelt lemez típusú.

Igen. Az első 31 napban egyetlen védett példány sem von maga után költségeket az Azure Site Recoveryben. Ha például az elmúlt hat hónapban 10 példányt véd, és egy 11. példányt csatlakoztat az Azure Site Recoveryhez, az első 31 napban a 11. példányért nem kell fizetnie. Az első 10 példány Azure Site Recovery-költségei továbbra is fel lesznek számolva, mivel a példányok 31 napnál hosszabb ideje állnak védelem alatt.

Igen. A Site Recoveryben a példányok védelme az első 31 nap alatt ingyenes, de az Azure Storage használatával, a tárolási tranzakciókkal és az adatátvitellel kapcsolatos díjtételeket felszámítjuk. A virtuális gépek helyreállítása szintén számítási költségekkel járhat az Azure-ban.

A vészhelyreállítási részletezésnek nincs külön költsége. A feladatátvételi teszt után a virtuális gép létrehozása után számítási költségek merülnek fel.

Nem, a Site Recovery nem elfogja a replikált adatokat, és nincs információja arról, hogy mi fut a virtuális gépeken vagy fizikai kiszolgálókon. A replikációs adatcsere a helyszíni Hyper-V gazdagépek, a VMware hipervizorok vagy fizikai kiszolgálók és az Azure tárolási szolgáltatás között történik. A Site Recovery nem képes ezekhez az adatokhoz hozzáférni. A Site Recovery szolgáltatás csak a replikáció és a feladatátvétel levezényléséhez szükséges metaadatokat kapja meg.

A Site Recovery ISO 27001:2013, 27018, HIPAA, DPA minősítéssel rendelkezik, és SOC2 és FedRAMP JAB-értékelések folyamatban van.

Igen. Amikor létrehoz egy Site Recovery-tárolót egy régióban, biztosítjuk, hogy a replikáció és a feladatátvétel engedélyezéséhez és vezényléséhez szükséges összes metaadat az adott régió földrajzi határain belül maradjon.

Az Azure-ba replikált virtuális gépek és fizikai kiszolgálók esetében mind az átvitel közbeni titkosítás, mind a inaktív titkosítás (az Azure-ban) támogatott.

Igen, a TLS 1.2 protokoll alapértelmezés szerint kikényszeríthető az Azure–Azure Site Recovery-forgatókönyv esetében.

A replikált elemekre telepített mobilitási ügynökök csak a TLS 1.2-n kommunikálnak a Folyamatkiszolgálóval. A konfigurációs kiszolgáló és az Azure közötti kommunikáció azonban a TLS 1.1-en vagy 1.0-n is lehetséges. Kövesse az útmutatást a TLS 1.2 kényszerítéséhez az Ön által beállított összes konfigurációs kiszolgálón és folyamatkiszolgálón.

Az Azure Site Recovery mikroszolgáltatásai közötti kommunikáció a TLS 1.2 protokollon történik. A Site Recovery a rendszerben (OS) konfigurált biztonsági szolgáltatókat használja, és a legújabb elérhető TLS-protokollt használja. Explicit módon engedélyeznie kell a TLS 1.2-t a beállításjegyzékben, majd a Site Recovery elkezdi használni a TLS 1.2-t a szolgáltatásokkal való kommunikációhoz.

Az Identitás beállítással bekapcsolhatja a helyreállítási tár felügyelt identitását. Miután a tároló regisztrálva van a Microsoft Entra-azonosítóval, megnyithatja a tárfiókjait, és a következő szerepkör-hozzárendeléseket adhat a tárolóhoz:

• Resource Manager-alapú tárfiókok (standard típus):
  • Közreműködő
  • Storage blobadat-közreműködő
• Resource Manager-alapú tárfiókok (Prémium típus):
  • Közreműködő
  • Storage-blobadatok tulajdonosa
• Klasszikus tárfiókok:
  • Klasszikus tárfiók közreműködője
  • Klasszikus tárfiókkulcs-kezelő szolgáltatásszerepkör

Az Azure Site Recovery nem követi nyomon a forrás operációs rendszeren kívüli forrás virtuális gépek változásait. Ha például azure-beli replikációt használ, és módosítja a forrás virtuális gép méretét, a forrás virtuális gép méretének módosítása nem lesz replikálva a cél virtuális gépre.

• Azure-beli virtuális gépek: A Site Recovery képes replikálni a támogatott Azure-beli virtuális gépeken futó számítási feladatokat.
• Hyper-V virtuális gépek: A Site Recovery képes megvédeni a Hyper-V virtuális gépen futó számítási feladatokat.
• Fizikai kiszolgálók: A Site Recovery képes megvédeni a Windows vagy Linux rendszert futtató fizikai kiszolgálókat.
• VMware virtuális gépek: A Site Recovery képes megvédeni a VMware virtuális gépeken futó számítási feladatokat.

A Site Recovery használatával védheti a támogatott virtuális gépen vagy fizikai kiszolgálón futó számítási feladatok többségét. A Site Recovery támogatja az alkalmazásérzékeny replikációt, hogy az alkalmazások intelligens állapotba állíthatók. Integrálható olyan Microsoft-alkalmazásokkal, mint a SharePoint, az Exchange, a Dynamics, az SQL Server és az Active Directory, és szorosan együttműködik a vezető gyártókkal, köztük az Oracle-vel, az SAP-vel, az IBM-mel és a Red Hattal. További információk a számítási feladatok védelméről.

Igen. Ha a Site Recovery használatával vezényeli a replikációt és a feladatátvételt a fiókirodákban, egységes vezénylést és az összes fiókirodai számítási feladat megtekintését fogja kapni egy központi helyen. A központi telephelyről könnyen intézheti a feladatátvételt és a vészhelyreállítást az összes fiókiroda tekintetében anélkül, hogy el kellene látogatnia a fiókirodák telephelyeire.

Igen, a Site Recovery támogatja az Azure-beli virtuális gépek Azure-régiók közötti vészhelyreállítását. Tekintse át az Azure-beli virtuális gépek vészhelyreállítására vonatkozó gyakori kérdéseket . Ha ugyanazon a kontinensen két Azure-régió között szeretne replikálni, használja az Azure-ból az Azure-ba irányuló vészhelyreállítási ajánlatunkat. Nincs szükség konfigurációs kiszolgáló/folyamatkiszolgáló és ExpressRoute-kapcsolatok beállítására.

Igen, a Site Recovery támogatja a helyszíni VMware virtuális gépek vészhelyreállítását. Tekintse át a VMware virtuális gépek vészhelyreállításával kapcsolatos gyakori kérdéseket .

Igen, a Site Recovery támogatja a helyszíni Hyper-V virtuális gépek vészhelyreállítását. Tekintse át a Hyper-V virtuális gépek vészhelyreállításával kapcsolatos gyakori kérdéseket .

Igen, a Site Recovery támogatja a Windowst és Linuxot az Azure-ba futtató helyszíni fizikai kiszolgálók vészhelyreállítását. Ismerje meg az Azure-ba történő vészhelyreállítás követelményeit. A fizikai kiszolgálók virtuális gépekként futnak az Azure-ban a feladatátvétel után. Az Azure-ból egy helyszíni fizikai kiszolgálóra történő feladat-visszavétel jelenleg nem támogatott. A feladat-visszavétel csak VMware virtuális gépre lehet.

Nem, az Azure Site Recovery nem támogatja az abban üzemeltetett védett virtuális gépeket tartalmazó Recovery Services-tároló áthelyezését.

Az Azure Site Recovery nyilvános végponton replikálja az adatokat egy Azure Storage-fiókba vagy felügyelt lemezekre. A replikáció azonban a helyek közötti VPN-en keresztül is elvégezhető. A helyek közötti VPN-kapcsolat lehetővé teszi a szervezetek számára, hogy meglévő hálózatokat csatlakoztassanak az Azure-hoz vagy az Azure-hálózatokhoz. A helyek közötti VPN az interneten keresztüli IPSec-bújtatáson keresztül történik, az Azure-ban meglévő helyszíni peremhálózati berendezések és hálózati berendezések használatával, akár natív funkciókkal, mint például az Azure Virtual Private Network (VPN) átjárója vagy külső féltől származó lehetőségek, például a Check Point CloudGaurd, a Palo Alto NextGen tűzfal.

• Privát kapcsolat a nyilvános interneten keresztül a Microsoft Edge-hez
• Privát végpontokkal rendelkező biztonságra konfigurált helyreállítási szolgáltatási tárolók
• Replikáció az ügyfél privát virtuális hálózati kapcsolatán keresztül
• Egyszerű áttűnés a "Future State" (Jövőbeli állapot) állapotra
• Nincs SLA és potenciálisan nagyobb késés
• Helyszíni VPN-eszköz rendelkezésre állását igényli

Partnerünk, a Riverbed részletes útmutatást nyújt az Azure Site Recovery használatához. Tekintse át a megoldás útmutatóját.

Igen, az ExpressRoute használható helyszíni virtuális gépek Azure-ba való replikálására.

• Az Azure Site Recovery egy nyilvános végponton keresztül replikálja az adatokat egy Azure Storage-ba. Az ExpressRoute site Recovery-replikációhoz való használatához be kell állítania a Microsoft-társviszonyt , vagy egy meglévő nyilvános társviszonyt kell használnia (az új kapcsolatcsoportok esetében elavult).
• A microsoftos társviszony-létesítés a replikációhoz ajánlott útválasztási tartomány.
• A replikáció csak akkor támogatott privát társviszony-létesítésen keresztül, ha a privát végpontok engedélyezve vannak a tárolóban.
• Ha VMware-gépeket vagy fizikai gépeket véd, győződjön meg arról, hogy a konfigurációs kiszolgáló hálózati követelményei is teljesülnek. Csatlakozás konfigurációs kiszolgálónak adott URL-címekre való alkalmasságra van szüksége a Site Recovery-replikáció vezényléséhez. Az ExpressRoute nem használható ehhez a kapcsolathoz.
• Miután a virtuális gépeket feladatátvételt végeztek egy Azure-beli virtuális hálózaton, a privát társviszony-létesítési beállítással érheti el őket az Azure-beli virtuális hálózattal.

A tárfiókok céltárolóként való használatát az Azure Site Recovery nem támogatja. Javasoljuk, hogy inkább felügyelt lemezeket használjon a gépek céltárolójaként. A felügyelt lemezek csak az LRS-típust támogatják az adatrugalmasság érdekében.

• Hyper-V: A Hyper-V virtuális gépek 30 másodpercenként replikálhatók (a prémium szintű tárolás kivételével) vagy öt percenként.
• Azure-beli virtuális gépek, VMware virtuális gépek, fizikai kiszolgálók: A replikációs gyakoriság itt nem releváns. A replikáció folyamatos.

A kiterjesztett vagy láncolt replikáció nem támogatott. Kérje ezt a funkciót a visszajelzési fórumon.

Ez nem támogatott. Kérje ezt a funkciót a visszajelzési fórumon.

Ez akkor támogatott, ha VMware virtuális gépeket és Hyper-V virtuális gépeket replikál az Azure-ba az Azure Portal használatával.

A dinamikus lemezek támogatottak Hyper-V virtuális gépek replikálásakor, valamint VMware virtuális gépek és fizikai gépek Azure-ba történő replikálásakor. Az operációs rendszer lemezének alaplemeznek kell lennie.

Igen. A sávszélesség szabályozásáról az alábbi cikkekben olvashat bővebben:

• VMware virtuális gépek és fizikai kiszolgálók replikálásának kapacitástervezése
• Kapacitástervezés Hyper-V virtuális gépek Azure-ba történő replikálásához

Igen. Az Azure Site Recovery for Linux operációs rendszer támogatja az alkalmazáskonzisztencia egyéni szkriptjeinek használatát. Az alkalmazáskonzisztencia során az Azure Site Recovery Mobility Agent az elő- és utóbeállításokat tartalmazó egyéni szkriptet használja. Az alábbiakban az engedélyezés lépéseit követjük.

1. Jelentkezzen be gyökérként a gépbe.

2. Módosítsa a címtárat az Azure Site Recovery Mobility Agent telepítési helyére. Alapértelmezett érték: "/usr/local/ASR"
   # cd /usr/local/ASR

3. Könyvtár módosítása "VX/szkriptek" értékre a telepítési hely alatt
   # cd VX/scripts

4. Hozzon létre egy "customscript.sh" nevű bash shell-szkriptet a gyökérfelhasználó végrehajtási engedélyeivel.
   a. A szkriptnek támogatnia kell a "--pre" és a "--post" parancsot (jegyezze fel a két kötőjelet) parancssori beállításokat
   b. Ha a szkriptet előbeállítással hívják meg, le kell rögzítenie az alkalmazás bemenetét/kimenetét, és ha az utóbeállítással van meghívva, fel kell olvasztania az alkalmazás bemenetét/kimenetét.
   c. Mintasablon –
   

   # 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. Az alkalmazáskonzisztenciát igénylő alkalmazások előzetes és utólagos lépéseiben adja hozzá a bemeneti/kimeneti parancsok rögzítését és feloldását. Választhat, hogy hozzáad egy másik szkriptet, amely megadja azokat, és meghívja azt a "customscript.sh" elő- és utóbeállításokkal.

A replikációs szabályzat határozza meg a helyreállítási pontok adatmegőrzési előzményeinek beállításait. A szabályzat az alkalmazáskonzisztens pillanatképek gyakoriságát is meghatározza. Az Azure Site Recovery alapértelmezés szerint létrehoz egy új replikációs szabályzatot a következő alapértelmezett beállításokkal:

• Egy nap a helyreállítási pontok megőrzési előzményeihez.
• Nincsenek alkalmazáskonzisztens pillanatképek.

Az összeomlás-konzisztens helyreállítási pontok lemezen tárolt adatai úgy vannak megadva, mintha a pillanatkép során lekérte volna a tápkábelt a kiszolgálóról. Az összeomlás-konzisztens helyreállítási pont nem tartalmaz semmit, amely a pillanatkép készítésekor a memóriában volt.

Ma a legtöbb alkalmazás képes jól helyreállítani az összeomláskonzisztens pillanatképeket. Az összeomláskonzisztens helyreállítási pont elegendő adatbázis nélküli operációs rendszerekhez és alkalmazásokhoz, például fájlkiszolgálókhoz, DHCP-kiszolgálókhoz és nyomtatókiszolgálókhoz.

A Site Recovery 5 percenként létrehoz egy összeomláskonzisztens helyreállítási pontot.

Az alkalmazáskonzisztens helyreállítási pontok alkalmazáskonzisztens pillanatképekből jönnek létre. Az alkalmazáskonzisztens helyreállítási pontok ugyanazokat az adatokat rögzítik, mint az összeomláskonzisztens pillanatképek, miközben a memóriában és az összes folyamatban lévő tranzakcióban is rögzítenek adatokat.

A további tartalmak miatt az alkalmazáskonzisztens pillanatképek a leginkább érintettek, és a leghosszabb ideig tart. Javasoljuk, hogy alkalmazáskonzisztens helyreállítási pontokat biztosítsunk adatbázis-operációs rendszerekhez és alkalmazásokhoz, például az SQL Serverhez.

Az alkalmazáskonzisztens helyreállítási pontok a memóriában és a folyamatban lévő összes adatot rögzítik. Mivel a helyreállítási pontok rögzítik ezeket az adatokat, a windowsos Kötet árnyékmásolata szolgáltatáshoz hasonló keretrendszerre van szükségük az alkalmazás kivezetéséhez. Ha a rögzítési folyamat gyakori, az hatással lehet a teljesítményre, ha a számítási feladat már foglalt. Nem javasoljuk, hogy alacsony gyakorisággal használja az alkalmazáskonzisztens helyreállítási pontokat nem adatbázis-számítási feladatokhoz. Az adatbázis-számítási feladatok esetében is elegendő az 1 óra.

A Site Recovery létrehozhat egy alkalmazáskonzisztens helyreállítási pontot, amelynek minimális gyakorisága 1 óra.

Annak megértéséhez, hogy a Site Recovery hogyan hozza létre a helyreállítási pontokat, lássunk egy példát egy replikációs szabályzatra. Ez a replikációs szabályzat egy helyreállítási ponttal rendelkezik, amely 1 napos megőrzési idővel és 1 órás alkalmazáskonzisztens gyakorisági pillanatképtel rendelkezik.

A Site Recovery 5 percenként létrehoz egy összeomláskonzisztens helyreállítási pontot. Ezt a gyakoriságot nem módosíthatja. A legutóbbi 2 órában 24 összeomláskonzisztens pont és 2 alkalmazáskonzisztens pont közül választhat. Az idő előrehaladtával a Site Recovery az elmúlt 2 órán túli összes helyreállítási pontot kimetszi, és óránként csak egy helyreállítási pontot takarít meg a nap 24 órájáig.

Az alábbi képernyőkép a példát mutatja be. A képernyőképen:

• Az elmúlt 2 órában 5 perces gyakorisággal vannak helyreállítási pontok.

• Az elmúlt 2 órában a Site Recovery óránként csak egy helyreállítási pontot tart meg.

  

A legrégebbi használható helyreállítási pont a felügyelt lemezzel 15 nap, a nem felügyelt lemezzel pedig három nap.

Nem, a Site Recovery megtartja az összes korábbi helyreállítási pontot. A helyreállítási pontok megőrzési időszakától függően a Site Recovery csak akkor cseréli le a legrégebbi pontot, ha új pontokat hoz létre. A probléma miatt a Site Recovery nem tud új helyreállítási pontokat létrehozni. Amíg nincsenek új helyreállítási pontok, az összes régi pont megmarad, miután elérte a megőrzési időkeretet.

Lépjen a Site Recovery Vault>Site Recovery-infrastruktúra>replikációs szabályzataihoz. Jelölje ki a szerkeszteni kívánt szabályzatot, és mentse a módosításokat. A módosítások az összes meglévő replikációra is érvényesek.

Az első létrehozott helyreállítási pont a teljes másolattal rendelkezik. Az egymást követő helyreállítási pontok eltérést mutatnak.

Igen, ha egy napról három napra növeli a megőrzési időt, a Site Recovery további két napra menti a helyreállítási pontokat. A hozzáadott idő tárolási díjakat fog eredményezni, mivel 12 további helyreállítási pontot kell menteni a megőrzési idő egy napról három napra történő növelésével. Egy helyreállítási pont például 10 GB-os változásváltozással rendelkezhet, havonta 0,16 USD/GB költséggel. További díjak 1,60 $ × 12 havonta.

Az Azure-beli virtuális gépeket biztonságos internetkapcsolaton, helyek közötti VPN-en vagy Az Azure ExpressRoute-on keresztül érheti el. A csatlakozáshoz több dolgot is elő kell készítenie. További információ.

Az Azure-t hibatűrőnek terveztük. A Site Recovery már ki van tervezve egy másodlagos Azure-adatközpontba való feladatátvételre az Azure SLA-val összhangban. Ha ez történik, biztosítjuk, hogy a metaadatok és tárolók ugyanabban a földrajzi régióban maradjanak, amelyet a tárolóhoz választott.

Elindíthat egy nem tervezett feladatátvételt a másodlagos helyről. A Site Recovery nem követeli meg a feladatátvétel végrehajtásához, hogy az elsődleges helyről kapcsolódjon.

A feladatátvétel nem automatikus. A feladatátvételeket egyetlen kattintással kezdeményezheti a portálon, vagy a Site Recovery PowerShell használatával aktiválhat feladatátvételt. A sikertelen visszalépés egy egyszerű művelet a Site Recovery portálon.

Az automatizáláshoz használhatja a helyszíni Orchestratort vagy az Operations Managert egy virtuális gép meghibásodásának észleléséhez, majd aktiválhatja a feladatátvételt az SDK használatával.

• További információ a helyreállítási tervekről.
• További információ a feladatátvételről.
• További információ a VMware virtuális gépek és fizikai kiszolgálók feladat-visszavételéről

Igen, a másik hely helyreállításával feladat-visszavételt végezhet az Azure-tól eltérő gazdagépre.

• VMware virtuális gépekhez
• Hyper-V virtuális gépekhez

Miután egy forráshelyről származó gépet feladatátvételt végzett a célhelyre, három lehetőség közül választhat. Mindhárom különböző célt szolgál -

1. A teljes migrálás azt jelenti, hogy többé nem fog visszatérni a forráshelyre. Áttelepített a célrégióba, és ezzel elkészült. A Teljes migrálás eseményindítóra kattintva véglegesíti a véglegesítést, majd belsőleg letiltja a replikációt.
2. A véglegesítés azt jelenti, hogy ez nem a replikációs folyamat vége. A replikációs elem és az összes konfiguráció megmarad, és később újra védheti a gépeket a forrásrégióba való visszareplikálásához.
3. A replikáció letiltása letiltja a replikációt, és eltávolítja az összes kapcsolódó konfigurációt. Ez nem érinti a célrégióban már meglévő gépet.

Igen. A Site Recovery-munkafolyamatokat a REST API, a PowerShell vagy az Azure SDK használatával automatizálhatja. A Site Recovery PowerShell-lel való üzembe helyezésének jelenleg támogatott forgatókönyvei:

• Hyper-V virtuális gépek replikálása virtuális gépek felhőiben az Azure PowerShell Resource Managerbe
• Hyper-V virtuális gépek replikálása VMM nélkül az Azure PowerShell Resource Managerbe
• VMware replikálása az Azure-ba a PowerShell Resource Managerrel

Nem, az AzureRM-modul kivonása nem befolyásolja a Site Recovery automatikus frissítéseinek működését. A belső runbook esetében nincs szükség módosításokra, és a helyben használt REST API továbbra is az automation-fióknak megfelelően működik.

Ismerje meg az új frissítéseket, és szerezze be az összesítő információkat.

Következő lépések

• Olvassa el a Site Recovery áttekintését