أسئلة عامة حول Azure Site Recovery

يساهم Site Recovery في استراتيجية استمرارية العمل واسترداد بعد عطل فادح (BCDR)، من خلال تنسيق وأتمتة النسخ المتماثل لأجهزة Azure الظاهرية بين المناطق والأجهزة الظاهرية المحلية والخوادم الفعلية في Azure والأجهزة المحلية في مركز بيانات ثانوي. اعرف المزيد.

لا، لا يدعم Azure Site Recovery أحمال عمل Docker التي تعمل على الأجهزة الظاهرية. لحماية هذه الأجهزة الظاهرية باستخدام استرداد الموقع، استبعد الأقراص التي تم تثبيت المرسى عليها.

هناك العديد من التدابير التي اتخذتها Site Recovery لضمان سلامة البيانات. يتم تأسيس اتصال آمن بين كافة الخدمات باستخدام بروتوكول HTTPS. وهذا يضمن أنه لا يمكن لأي برامج ضارة أو كيانات خارجية العبث بالبيانات. وثمة تدبير آخر اتُّخذ وهو استخدام المجموعات الاختبارية. يتم تنفيذ نقل البيانات بين المصدر والهدف من خلال حساب المجموعات الاختبارية للبيانات بينهما. وهذا يضمن تناسق البيانات المنقولة.

لا يدعم Azure عناوين MAC الثابتة، لذلك لا يمكن استخدام البرامج ذات نماذج الترخيص المستندة إلى MAC لكل من الترحيل المحلي إلى Azure أو التعافي من الكوارث.

لا، لا يدعم Azure Site Recovery حاليا الأقراص سريعة الزوال.

يتم استخدام عامل Microsoft Azure Recovery Services لتكوين/تسجيل مع خدمات Site Recovery، ومراقبة صحة جميع المكونات. هذا المكون هو أحد اللبنات الأساسية لبنية Azure Site Recovery الأساسية المحلية بأكملها. يساعد على نسخ أحمال العمل الخاصة بك إلى منطقة Azure أخرى من موقع محلي، وتجاوز الفشل إلى Azure في كارثة.

نعم، يدعم Site Recovery نماذج البنية التحتية المخصصة والمشتركة.

‏‏لا. تظل هوية المستأجر مجهولة. لا يحتاج المستأجرون إلى الوصول إلى مدخل Site Recovery. لا يتفاعل مع المدخل إلا مسؤول مقدم الخدمة.

عند النسخ المتماثل إلى Azure، يتم إرسال بيانات التطبيق إلى تخزين Azure ولكن ليس إلى خدمة Site Recovery. يتم تشفير البيانات أثناء النقل (HTTPS)، وتظل مشفرة في Azure.

‏‏لا. علاقة فوترة Azure مباشرة مع مقدم الخدمة. مقدمو الخدمات مسؤولون عن إنشاء فواتير محددة للمستأجرين.

لا، يتم نسخ البيانات إلى تخزين Azure في اشتراكك. عند إجراء اختبار تجاوز الفشل (تدريب التعافي من الكوارث) أو تجاوز فشل فعلي، يقوم Site Recovery تلقائيا بإنشاء أجهزة ظاهرية في اشتراكك.

نعم.

نحن ندعم Azure Pack وCloud Platform System وSystem Center القائم على عمليات النشر (2012 والإصدارات الأحدث). تعرف على المزيد حول تكامل Azure Pack و Site Recovery.

لا، يمكنك نسخ الأجهزة الظاهرية Hyper-V نسخا متماثلا فقط إلى Azure.

راجع تفاصيل تسعير Site Recovery.

يمكنك استخدام حاسبة التسعير لتقدير التكاليف أثناء استخدام Site Recovery.

للحصول على تقدير مفصل للتكاليف، قم بتشغيل أداة مخطط التوزيع ل VMware أو Hyper-V، واستخدم تقرير تقدير التكلفة.

نعم، هناك رسوم إضافية لاستخدام حساب تخزين ذاكرة التخزين المؤقت عند نسخ الأجهزة الظاهرية باستخدام Site Recovery. تظل تكاليف حساب تخزين ذاكرة التخزين المؤقت كما هي عندما يكون تخزين النسخة المتماثلة من نوع الأقراص المدارة أو الأقراص غير المدارة.

نعم. لا يتحمل أي مثيل محمي أي رسوم لـAzure Site Recovery مقابل أول 31 يومًا. على سبيل المثال، إذا كنت تحمي 10 مثيلات للأشهر الستة الماضية وقمت بتوصيل مثيل 11 ب Azure Site Recovery، فلا توجد رسوم للمثيل الحادي عشر لأول 31 يوما. تستمر المثيلات العشر الأولى في تحمل رسوم Azure Site Recovery نظرا لأنها محمية منذ أكثر من 31 يومًا.

نعم، على الرغم من أن Site Recovery مجاني خلال الأيام الـ 31 الأولى من المثيل المحمي، فقد تتحمل رسوما على Azure Storage وحركات التخزين ونقل البيانات. قد يؤدي الجهاز الظاهري المسترد أيضًا إلى فرض رسوم في حوسبة Azure.

لا توجد أي تكلفة منفصلة لحفر التعافي من الكوارث. توجد رسوم حساب بعد إنشاء الجهاز الظاهري بعد تجاوز فشل الاختبار.

لا، لا يعترض Site Recovery بيانات النسخ المتماثل، ولا يملك أي معلومات حول ما يتم تشغيله على الأجهزة الظاهرية أو الخوادم الفعلية. يتم تبادل بيانات النسخ المتماثل بين المضيفين Hyper-V المحليين أو VMware hypervisors أو الملقمات الفعلية وتخزين Azure أو موقعك الثانوي. لا يملك Site Recovery القدرة على اعتراض تلك البيانات. يتم إرسال بيانات التعريف المطلوبة لتنسيق النسخ المتماثل وتجاوز الفشل إلى خدمة Site Recovery.

Site Recovery هو ISO 27001:2013، 27018، HIPAA، DPA معتمد، وهو في عملية تقييم SOC2 وFedRAMP JAB.

نعم. عند إنشاء مخزن Site Recovery في منطقة ما، نضمن أن تظل جميع بيانات التعريف التي نحتاجها لتمكين النسخ المتماثل وتجاوز الفشل وتنسيقها ضمن الحدود الجغرافية لتلك المنطقة.

بالنسبة للأجهزة الظاهرية والخوادم الفعلية التي تنسخ نسخا متماثلا إلى Azure، يتم دعم كل من التشفير أثناء النقل والتشفير في حالة الراحة (في Azure ).

نعم، يتم فرض بروتوكول TLS 1.2 بشكل افتراضي لسيناريو Site Recovery الخاصة بالنسخ من Azure إلى Azure.

يتصل وكلاء التنقل المثبتة على العناصر المنسوخة نسخًا متماثلًا إلى خادم العمليات فقط على TLS 1.2. ومع ذلك، الاتصال من خادم التكوين إلى Azure ومن خادم العمليات إلى Azure قد يكون على TLS 1.1 أو 1.0. اتبع الإرشادات لفرض TLS 1.2 على جميع خوادم التكوين وخوادم المعالجة التي قمت بإعدادها.

تحدث كافة الاتصالات بين الخدمات المصغرة لـAzure Site Recovery على بروتوكول TLS 1.2. يستخدم Site Recovery موفري الأمان المكونين في النظام (نظام التشغيل) ويستخدم أحدث بروتوكول TLS متوفر. يحتاج المرء إلى تمكين TLS 1.2 بشكل صريح في السجل ثم سيبدأ Site Recovery باستخدام TLS 1.2 للاتصال بالخدمات.

يمكنك تشغيل الهوية المدارة لمخزن خدمات الاسترداد عن طريق الانتقال إلى إعداد الهوية . بمجرد تسجيل المخزن باستخدام معرف Microsoft Entra، يمكنك الانتقال إلى حسابات التخزين الخاصة بك وإعطاء تعيينات الأدوار التالية إلى المخزن:

• حسابات التخزين المستندة إلى Resource Manager (النوع القياسي):
  • المساهم
  • المساهم في بيانات مخزن البيانات الثنائية الكبيرة
• حسابات التخزين المستندة إلى Resource Manager (نوع Premium):
  • المساهم
  • مالك بيانات للبيانات الثنائية الكبيرة للتخزين
• حسابات التخزين الكلاسيكية:
  • مساهم حساب التخزين الكلاسيكي
  • دور خدمة مشغل مفتاح حساب التخزين الكلاسيكي

لا يتعقب Azure Site Recovery تغييرات الجهاز الظاهري المصدر خارج نظام التشغيل المصدر. على سبيل المثال، إذا كنت تستخدم Azure للنسخ المتماثل Azure وتغيير حجم الجهاز الظاهري المصدر، لا يتم نسخ التغيير في حجم الجهاز الظاهري المصدر إلى الجهاز الظاهري الهدف.

• أجهزة Azure الظاهرية: يمكن ل Site Recovery نسخ أي حمل عمل يعمل على جهاز Azure ظاهري مدعوم.
• الأجهزة الظاهرية Hyper-V: يمكن ل Site Recovery حماية أي حمل عمل يعمل على جهاز Hyper-V ظاهري.
• الخوادم الفعلية: يمكن ل Site Recovery حماية الخوادم الفعلية التي تعمل بنظام التشغيل Windows أو Linux.
• أجهزة VMware الظاهرية: يمكن ل Site Recovery حماية أي حمل عمل قيد التشغيل في جهاز ظاهري VMware.

يمكنك استخدام Site Recovery لحماية معظم أحمال العمل التي تعمل على جهاز ظاهري معتمد أو خادم فعلي. يوفر Site Recovery الدعم للنسخ المتماثل المُدرك للتطبيق، بحيث يمكن استرداد التطبيقات إلى حالة ذكية. وهو يتكامل مع تطبيقات مايكروسوفت مثل SharePoint Exchange وDynamics وMicrosoft SQL Server وActive Directory، ويعمل بشكل وثيق مع كبار الموردين، بما في ذلك Oracle، وSAP، وIBM وRed Hat. تعرف على المزيد حول حماية حمل العمل.

نعم. عند استخدام Site Recovery لتنسيق النسخ المتماثل وتجاوز الفشل في المكاتب الفرعية الخاصة بك، ستحصل على تنسيق وعرض موحدين لكافة أعباء عمل المكتب الفرعي في موقع مركزي. يمكنك بسهولة تشغيل تجاوز الفشل وإدارة التعافي من الكوارث لجميع الفروع من المكتب الرئيسي الخاص بك، دون زيارة الفروع.

نعم، يدعم Site Recovery الكوارث لأجهزة Azure الظاهرية بين مناطق Azure. راجع الأسئلة الشائعة حول التعافي من الكوارث في جهاز Azure الظاهري. إذا كنت ترغب في النسخ المتماثل بين منطقتين من مناطق Azure في نفس القارة، فاستخدم Azure لعرض التعافي من الكوارث في Azure. ليس هناك حاجة لإعداد خادم التكوين/خادم العملية واتصالات ExpressRoute.

نعم، يدعم Site Recovery التعافي من الكوارث لأجهزة VMware الظاهرية المحلية. راجع الأسئلة الشائعة للتعافي من الكوارث لأجهزة VMware الظاهرية.

نعم، يدعم Site Recovery التعافي من الكوارث لأجهزة Hyper-V الظاهرية المحلية. راجع الأسئلة الشائعة للتعافي من الكوارث للأجهزة الظاهرية Hyper-V.

نعم، يدعم Site Recovery التعافي من الكوارث للخوادم الفعلية المحلية التي تعمل بنظامي التشغيل Windows وLinux إلى Azure. تعرف على متطلبات التعافي من الكوارث في Azure. تعمل الخوادم الفعلية كأجهزة ظاهرية في Azure بعد تجاوز الفشل. لا يتم حاليًا دعم إرجاع الموارد من Azure إلى خادم فعلي محلي. لا يمكنك إرجاع الموارد إلا إلى جهاز VMware الظاهري.

لا، لا يدعم Azure Site Recovery نقل مخزن خدمات الاسترداد الذي يحتوي على أجهزة ظاهرية محمية مستضافة فيه.

يقوم Azure Site Recovery بنسخ البيانات نسخًا متماثلاً إلى حساب تخزين Azure أو الأقراص المدارة، عبر نقطة نهاية عامة. ومع ذلك، يمكن إجراء النسخ المتماثل عبر VPN من موقع إلى موقع أيضًا. يسمح اتصال VPN من موقع إلى موقع للمؤسسات بتوصيل الشبكات الموجودة بـ Azure أو شبكات Azure بعضها ببعض. يحدث VPN من موقع إلى موقع عبر نفق IPSec عبر الإنترنت، باستخدام معدات الشبكة المحلية الموجودة وأجهزة الشبكة في Azure، إما الميزات الأصلية مثل بوابة شبكة Azure الظاهرية الخاصة (VPN) أو خيارات الجهات الخارجية مثل Check Point CloudGaurd، Palo Alto NextGen Firewall.

• اتصال خاص عبر الإنترنت العام بـ Microsoft Edge
• مخازن خدمة الاسترداد التي تم تكوينها للأمان باستخدام نقاط النهاية الخاصة
• النسخ المتماثل عبر اتصال الشبكة الظاهرية الخاصة بالعميل
• سهولة الانتقال إلى "حالة المستقبل"
• لا توجد اتفاقية مستوى الخدمة وزمن انتقال أعلى محتمل
• يتطلب توفر جهاز VPN المحلي

يقدم شريكنا، Riverbed، إرشادات مفصلة حول العمل معAzure Site Recovery. راجع دليل الحل.

نعم، يمكن استخدام ExpressRoute لنسخ الأجهزة الظاهرية المحلية نسخا متماثلا إلى Azure.

• يقوم Azure Site Recovery بنسخ البيانات نسخًا متماثلاً إلى Azure Storage عبر نقطة نهاية عامة. تحتاج إلى إعداد نظير Microsoft أو استخدام نظير عام موجود (مهمل للدوائر الجديدة) لاستخدام ExpressRoute للنسخ المتماثل لاسترجاع الموقع.
• نظير Microsoft هو مجال التوجيه المستحسن للنسخ المتماثل.
• يتم دعم النسخ المتماثل عبر التناظر الخاص فقط عند تمكين نقاط النهاية الخاصة للمخزن.
• إذا كنت تحمي أجهزة VMware أو الأجهزة الفعلية، فتأكد من استيفاء متطلبات الشبكة لخادم التكوين أيضا. يعد الاتصال بعناوين URL محددة أمرًا ضروريًا لخادم التكوين لتنسيق النسخ المتماثل Site Recovery. لا يمكن استخدام ExpressRoute لهذا الاتصال.
• بعد تجاوز فشل الأجهزة الظاهرية إلى شبكة Azure الظاهرية، يمكنك الوصول إليها باستخدام إعداد التناظر الخاص مع شبكة Azure الظاهرية.

لا يدعم Azure Site Recovery استخدام حسابات التخزين كمساحة تخزين مستهدفة. من المستحسن استخدام الأقراص المدارة كمساحة تخزين مستهدفة لأجهزتك. لا تدعم الأقراص المدارة إلا نوع LRS لمرونة البيانات.

• Hyper-V: يمكن نسخ الأجهزة الظاهرية Hyper-V كل 30 ثانية (باستثناء التخزين المتميز) أو خمس دقائق.
• أجهزة Azure الظاهرية وأجهزة VMware الظاهرية والخوادم الفعلية: تكرار النسخ المتماثل غير ذي صلة هنا. النسخ المتماثل مستمر.

النسخ المتماثل الموسع أو المتسلسل غير معتمد. اطلب هذه الميزة في منتدى الملاحظات.

هذا غير مدعوم. اطلب هذه الميزة في منتدى الملاحظات.

يتم دعم هذا عند النسخ المتماثل لأجهزة VMware الظاهرية وأجهزة Hyper-V الظاهرية إلى Azure، باستخدام مدخل Microsoft Azure.

يتم دعم الأقراص الديناميكية عند النسخ المتماثل لأجهزة Hyper-V الظاهرية، وعند نسخ الأجهزة الظاهرية VMware والأجهزة الفعلية إلى Azure. يجب أن يكون قرص نظام التشغيل قرصًا أساسيًا.

نعم. يمكنك قراءة المزيد حول كبح النطاق الترددي في هذه المقالات:

• تخطيط السعة لنسخ الأجهزة الظاهرية VMware والخوادم الفعلية
• تخطيط السعة لنسخ الأجهزة الظاهرية Hyper-V إلى Azure

نعم. يدعم Azure Site Recovery لنظام تشغيل Linux البرامج النصية المخصصة للتطبيقات لتناسق التطبيق. يتم استخدام البرنامج النصي المخصص مع خيارات ما قبل وبعد بواسطة عامل التنقل استرداد موقع Azure أثناء تناسق التطبيق. فيما يلي الخطوات لتمكينه.

1. تسجيل الدخول كجذر في الجهاز.

2. تغيير الدليل إلى موقع تثبيت عامل تنقل Azure Site Recover. الوضع الافتراضي هو "/usr/local/ASR"
   # cd /usr/local/ASR

3. قم بتغيير الدليل إلى "VX/scripts" ضمن موقع التثبيت
   # cd VX/scripts

4. قم بإنشاء برنامج نصي bash shell المسمى "customscript.sh" له أذونات التنفيذ لمستخدم الجذر.
   أ. يجب أن يعتمد البرنامج النصي خيارات سطر الأوامر "pre--" و"post--" (لاحظ الشرطات المزدوجة)
   ب. عندما يتم استدعاء البرنامج النصي مع الخيار المسبق، فإنه ينبغي تجميد إدخال/إخراج التطبيق وعند استدعائه مع الخيار اللاحق، فإنه ينبغي إلغاء تجميد إدخال/إخراج التطبيق.
   جـ. نموذج قالب -
   

   # 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. أضف أوامر تجميد الإدخال/الإخراج وإلغاء تجميدها في خطوات ما قبل وما بعد للتطبيقات التي تتطلب اتساق التطبيق. يمكنك اختيار إضافة برنامج النصي آخر يحددها ويستدعيها من "customscript.sh" مع خيارات ما قبل وبعد التطبيق.

يُعرف نهج النسخ المتماثل إعدادات محفوظات الاستبقاء لنقاط الاسترداد. يحدد النهج أيضًا وتيرة اللقطات المتسقة مع التطبيق. بشكل افتراضي، يقوم Azure Site Recovery بإنشاء نهج نسخ متماثل جديد مع الإعدادات الافتراضية من:

• 24 ساعة لاستبقاء بيانات الاحتفاظ بنقاط الاسترداد.
• القطات متسقة غير متوفرة مع التطبيق.

تحتوي نقطة الاسترداد المتناسقة مع الأعطال على البيانات الموجودة على القرص كما لو كنت قد سحبت سلك الطاقة من الخادم في أثناء اللقطة. لا تتضمن نقطة الاسترداد المتوافقة مع الأعطال أي شيء كان في الذاكرة عند التقاط اللقطة.

اليوم، يمكن استرداد معظم التطبيقات بشكل جيد من اللقطات المتسقة مع الأعطال. نقطة الاسترداد المتوافقة مع الأعطال كافية لأنظمة التشغيل والتطبيقات بدون قاعدة بيانات مثل خوادم الملفات وخوادم DHCP وخوادم الطباعة.

ينشئ Site Recovery نقطة استرداد متناسقة مع الأعطال كل 5 دقائق.

يتم إنشاء نقاط الاسترداد المتناسقة مع التطبيق من لقطات متناسقة مع التطبيق. تلتقط نقاط الاسترداد المتوافقة مع التطبيق نفس البيانات مثل لقطات المتناسقة مع الأعطال بينما تلتقط أيضًا البيانات في الذاكرة وجميع المعاملات قيد التنفيذ.

بسبب المحتوى الإضافي الخاص بهم، اللقطات المتناسقة مع التطبيق هي أكثر المشاركين وأكثر ما يستغرق الوقت. نوصي بنقاط الاسترداد المتناسقة مع التطبيقات لأنظمة تشغيل قاعدة البيانات والتطبيقات مثل SQL Server.

تلتقط نقاط الاسترداد المتوافقة مع التطبيق كافة البيانات في الذاكرة وفي العملية. لأن نقاط الاسترداد تلتقط تلك البيانات، فإنها تتطلب إطار عمل مثل Volume Shadow Copy Service على نظام التشغيل Windows لإلغاء تنشيط التطبيق. إذا كانت عملية التقاط متكررة، فإنه يمكن أن تؤثر على الأداء عندما يكون حمل العمل مشغولاً بالفعل. لا ننصح باستخدام الوتيرة المنخفضة لنقاط الاسترداد المتوافقة مع التطبيق لأحمال العمل التي ليس لها قاعدة بيانات. حتى بالنسبة إلى عبء العمل قاعدة البيانات، فإن ساعة واحدة تكفي.

يمكن أن ينشئ Site Recovery نقطة استرداد متوافقة مع التطبيق مع أدنى وتيرة وهي 1 ساعة.

لفهم كيفية إنشاء Site Recovery نقاط الاسترداد، دعنا نرى مثالًا على نهج النسخ المتماثل. يحتوي نهج النسخ المتماثل هذا على نقطة استرداد مع نافذة استبقاء على مدار ساعة ولقطة متناسقة مع التطبيق تتردد كل ساعة.

ينشئ Site Recovery نقطة استرداد متناسقة مع الأعطال كل 5 دقائق. لا يمكنك تغيير هذا التردد. لأحدث ساعتين، تستطيع الاختيار من بين 24 نقطة متسقة مع الأعطال ونقطتين متسقتين مع التطبيق. مع تقدم الوقت، يقوم Site Recovery بتقليم جميع نقاط الاسترداد بعد آخر ساعتين ويحفظ نقطة استرداد واحدة فقط في الساعة لمدة تصل إلى 24 ساعة من اليوم.

توضح لقطة الشاشة التالية المثال. في لقطة الشاشة:

• في غضون الساعة الماضية، هناك نقاط استرداد مع تردد كل دقيقتان.

• بعد الساعين الماضيين، يحتفظ Site Recovery بنقطة استرداد واحدة فقط في الساعة.

  

أقدم نقطة استرداد يمكنك استخدامها هي 15 يوما مع القرص المدار وثلاثة أيام مع القرص غير المدار.

لا، يحتفظ Site Recovery بجميع نقاط الاسترداد السابقة. اعتمادًا على نافذة الاستبقاء الخاصة بنقاط الاسترداد، فإن Site Recovery لا يستبدل النقطة الأقدم إلا إذا كان ينشئ نقاط جديدة. وبسبب هذه المشكلة، لا يمكن لـSite Recovery إنشاء أي نقاط استرداد جديدة. حتى تكون هناك نقاط استرداد جديدة، تظل جميع النقاط القديمة بعد الوصول إلى نافذة الاستبقاء.

انتقل إلى Site Recovery Vault>Site Recovery Infrastructure>Replication policies. حدد النهج الذي تريد تحريره، ثم احفظ التغييرات. ينطبق أي تغيير على جميع النسخ المتماثلة الموجودة أيضا.

نقطة الاسترداد الأولى التي تم إنشاؤها تحتوي على النسخة الكاملة. أي نقاط استرداد تليها لها تغييرات دلتا.

نعم، إذا قمت بزيادة فترة الاستبقاء من يوم واحد إلى ثلاثة أيام، يحفظ Site Recovery نقاط الاسترداد لمدة يومين إضافيين. سيتحمل الوقت الإضافي رسوم تخزين حيث سيكون هناك 12 نقطة استرداد إضافية يجب حفظها مع زيادة فترة الاستبقاء من يوم واحد إلى ثلاثة أيام. على سبيل المثال، قد تحتوي نقطة الاسترداد الواحدة على تغييرات delta تبلغ 10 جيجا بايت مع تكلفة لكل غيغابايت قدرها 0.16 دولار شهريًا. ستكون الرسوم الإضافية 1.60 × 12 دولار كل شهر.

يمكنك الوصول إلى أجهزة Azure الظاهرية عبر اتصال إنترنت آمن أو عبر VPN من موقع إلى موقع أو عبر Azure ExpressRoute. تحتاج إلى إعداد عدة أشياء من أجل الاتصال. اعرف المزيد.

تم تصميم Azure للمرونة. تم تصميم Site Recovery بالفعل من أجل تجاوز الفشل إلى مركز بيانات Azure ثانوي، وفقًا لـ Azure SLA. إذا حدث ذلك، فتأكدنا من بقاء بياناتك التعريفية والمخازن ضمن نفس المنطقة الجغرافية التي اخترتها لمخزنك.

يمكنك تشغيل تجاوز الفشل غير المخطط له من الموقع الثانوي. لا يحتاج Site Recovery إلى الاتصال من الموقع الأساسي لتنفيذ تجاوز الفشل.

لا يتم تجاوز الفشل بشكل تلقائي. يمكنك بدء عمليات تجاوز الفشل بنقرة واحدة في المدخل، أو يمكنك استخدام Site Recovery PowerShell لتشغيل تجاوز الفشل. إرجاع الموارد هو إجراء بسيط في مدخل Site Recovery.

لأتمتة تجاوز الفشل يمكنك استخدام منسق محلي أو إدارة العمليات للكشف عن فشل جهاز ظاهري ومن ثم تشغيل تجاوز الفشل باستخدام SDK.

• اقرأ المزيد حول خطط الاسترداد.
• اقرأ المزيد حول تجاوز الفشل.
• اقرأ المزيد حول فشل أجهزة VMware الظاهرية والخوادم الفعلية

نعم، يمكنك استخدام استرداد الموقع البديل لإرجاع الموارد إلى مضيف مختلف من Azure.

• لأجهزة VMware الظاهرية
• لأجهزة Hyper-V الظاهرية

بمجرد أن يتجاوز الجهاز من موقع المصدر الفشل إلى الموقع المستهدف فهناك ثلاثة خيارات متاحة لك للاختيار من بينها. كل خيار من الخيارات الثلاثة تخدم أغراضًا مختلفة -

1. يعني الترحيل الكامل أنك لن تعود إلى موقع المصدر بعد الآن. لقد انتقلت إلى المنطقة المستهدفة وقد انتهى الأمر الآن. النقر فوق Complete Migration triggers Commit ثم قم بتعطيل النسخ المتماثل داخليًا.
2. التثبيت يعني أن هذه ليست نهاية العملية الخاصة بالنسخ المتماثل. سيبقى عنصر النسخ المتماثل مع جميع التكوينات، ويمكنك الوصول إلى إعادة الحماية في وقت لاحق لتمكين النسخ المتماثل لأجهزتك مرة أخرى إلى منطقة المصدر.
3. سيؤدي تعطيل النسخ المتماثل إلى تعطيل النسخ المتماثل وإزالة كافة التكوينات ذات الصلة. لن يؤثر ذلك على الجهاز الحالي الموجود في المنطقة المستهدفة بالفعل.

نعم. يمكنك أتمتة سير عمل موقع الاسترداد باستخدام واجهة برمجة تطبيقات Rest أو PowerShell أو Azure SDK. السيناريوهات المعتمدة حاليًا لنشر Site Recovery باستخدام PowerShell:

• نسخ الأجهزة الظاهرية Hyper-V نسخا متماثلا في سحابات الأجهزة الظاهرية إلى Azure PowerShell Resource Manager
• النسخ المتماثل لأجهزة Hyper-V الظاهرية بدون VMM إلى Azure PowerShell Resource Manager
• نسخ VMware نسخا متماثلا إلى Azure باستخدام PowerShell Resource Manager

لا، لا يؤثر إيقاف الوحدة النمطية AzureRM على كيفية عمل التحديثات التلقائية ل Site Recovery. لا توجد تغييرات مطلوبة لدفتر التشغيل الداخلي، وتستمر واجهة برمجة تطبيقات REST المستخدمة في العمل على النحو المنشود مع حساب التنفيذ التلقائي.

تعرف على التحديثات الجديدة، والحصول على معلومات مجموعة التحديثات.

الخطوات التالية

• قراءة نظرة عامة على Site Recovery