ما هي التكرار والنسخ المتماثل والنسخ الاحتياطي؟

غالبا ما نفكر في السحابة كنظام موزع عالميا وفي كل مكان. ومع ذلك، في الواقع تتكون السحابة من الأجهزة التي تعمل في مراكز البيانات. تتطلب المرونة أن تقوم بحساب بعض المخاطر المرتبطة بالمواقع الفعلية التي تعمل فيها المكونات المستضافة على السحابة.

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

التكرار هو القدرة على الاحتفاظ بنسخ متطابقة متعددة من مكون الخدمة، واستخدام هذه النسخ بطريقة تمنع أي مكون واحد من أن يصبح نقطة فشل واحدة.

النسخ المتماثل أو تكرار البيانات هو القدرة على الاحتفاظ بنسخ متعددة من البيانات، تسمى النسخ المتماثلة.

النسخ الاحتياطي هو القدرة على الاحتفاظ بنسخة طابع زمني من البيانات التي يمكن استخدامها لاستعادة البيانات التي تم فقدانها.

من منظور الموثوقية، هناك طريقة مهمة للتخفيف من العديد من المخاطر وهي تضمين شكل من أشكال التكرار أو النسخ المتماثل أو النسخ الاحتياطي في تخطيط استمرارية الأعمال.

إشعار

لا توفر هذه المقالة إرشادات التصميم أو معلومات مفصلة حول خدمات Azure الفردية. للحصول على معلومات حول كيفية عمل خدمات Azure المحددة من منظور الموثوقية، راجع دليل موثوقية كل خدمة.

التكرار

يتكون التكرار من نشر مثيلات متعددة من مكون. في حين أن التكرار أمر مباشر لفهمه، فإنه في بعض الحالات، يمكن أن يصبح تنفيذه معقدا.

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

السيناريو: التكرار عديم الحالة

في هذا المثال، يتم نشر مكون API عديم الحالة على جهاز ظاهري. لتجنب وقت التعطل لمكون واجهة برمجة التطبيقات إذا كان هناك فشل في الأجهزة على المضيف الفعلي، يقوم المثال بتنفيذ حل متكرر:

• نشر نسخ متعددة من مثيل واجهة برمجة التطبيقات.
• تنفيذ موازن تحميل لتوزيع الطلبات بين مثيلات واجهة برمجة التطبيقات.

يراقب موازن التحميل صحة كل مثيل لإرسال الطلبات فقط إلى مثيلات سليمة.

اعتبارات التكرار

عند تنفيذ حلول زائدة عن الحاجة، كما هو الحال في السيناريو أعلاه، من المهم مراعاة ما يلي:

• تكاليف الموارد. بحكم التعريف، يتضمن التكرار وجود نسخ متعددة من شيء ما، ما يزيد من التكلفة الإجمالية لاستضافة الحل.

• اداء. كلما توسعت المنطقة الجغرافية التي توزع نسخا من الأشياء، زادت المخاطر التي تساعد على التخفيف منها. ومع ذلك، ستستغرق الطلبات الواردة من العملاء وقتا أطول للسفر لمسافات أطول لأنه يتعين عليهم اجتياز المزيد من البنية الأساسية للشبكة، وهذا يزيد من زمن انتقال الشبكة.

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

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

• توزيع العمل. عندما يكون لديك مثيلات متعددة لمكون، تحتاج إلى توزيع العمل بينها. قد تقوم بنشر العمل عبر جميع المثيلات بالتساوي، أو قد ترسل طلبات إلى مثيل أساسي واحد وتستخدم مثيلا ثانويا فقط إذا كان المثيل الأساسي غير متوفر.

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

• مراقبة الصحة. تحدد صحة كل مثيل ما إذا كان يمكن لهذا المثيل القيام بعمله، كما أن مراقبة الصحة مهمة لتمكين الاسترداد السريع إذا كانت هناك مشكلة.

  عادة ما تقوم موازنات التحميل بمراقبة السلامة. بالنسبة للمكونات التي لا تتضمن موازن تحميل، قد يكون لديك مكون خارجي يراقب صحة جميع المثيلات، أو قد يراقب كل مثيل صحة المثيلات الأخرى.

المواقع الفعلية في السحابة

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

على سبيل المثال:

• يعمل الجهاز الظاهري في مكان فعلي واحد في أي وقت.
• يتم تخزين البيانات في موقع فعلي معين، على سبيل المثال على محرك أقراص ذي حالة صلبة (SSD) أو قرص ثابت متصل بالخوادم.

حتى إذا كانت هناك نسخ متعددة من جزء من البيانات أو مثيلات مكون، فإن كل نسخة مرتبطة بالأجهزة الفعلية المخزنة عليها.

يمكن تنظيم الموقع الفعلي لبيئة السحابة ككل في نطاقات فعلية. في كل نطاق مادي، هناك مخاطر محتملة قد تعرض المكونات أو البيانات داخل هذا النطاق للخطر. فيما يلي مخاطر قائمة غير شاملة يمكن تعريفها من حيث النطاق المادي:

النطاق الفعلي	المخاطر المحتملة
قطعة معينة من الأجهزة، مثل قرص أو خادم	فشل في الأجهزة
حامل في مركز بيانات	انقطاع تبديل الشبكة من أعلى الرف
مركز بيانات	مشكلة في نظام تبريد المبنى
مجموعة من مراكز البيانات، والتي تسمى في Azure منطقة توفر	عاصفة كهربائية على مستوى المدينة
المنطقة الجغرافية الأوسع التي يوجد بها مركز البيانات، مثل المدينة، وهي منطقة Azure	كارثة طبيعية واسعة النطاق

من منظور الموثوقية، هناك طريقة مهمة للتخفيف من المخاطر المرتبطة بالنطاق المادي وهي نشر مثيلات مكون عبر نطاقات مادية مختلفة. قد تقدم لك خدمات Azure ذات التكرار المضمن طريقة واحدة أو أكثر من الطرق الثلاث التالية لنشر مثيلات زائدة عن الحاجة:

• يضع التكرار المحلي المثيلات في أجزاء متعددة من مركز بيانات Azure واحد ويحمي من حالات فشل الأجهزة التي قد تؤثر على مثيل واحد. يوفر التكرار المحلي عادة أقل تكلفة وزمن انتقال. ومع ذلك، قد يعني فشل مركز البيانات أن جميع المثيلات غير متوفرة.

• يوزع التكرار في المنطقة المثيلات عبر مناطق توفر متعددة في منطقة Azure واحدة. يحمي التكرار في المنطقة من فشل مركز البيانات، بالإضافة إلى فشل الأجهزة.

• يضع التكرار الجغرافي المثيلات عبر مناطق Azure المتعددة ويوفر الحماية من الانقطاعات الإقليمية واسعة النطاق. يأتي التكرار الجغرافي بتكلفة أعلى ويتطلب النظر في تصميم الحل الأوسع وكيفية التبديل بين مثيلات مكوناتك في كل منطقة. تحتاج أيضا إلى التفكير في زمن الانتقال، الموضح في النسخ المتماثل المتزامن وغير المتزامن.

كيفية عمل التكرار في Azure: خدمات الحوسبة

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

في Azure، يعمل جهاز ظاهري فردي (VM) على مضيف فعلي واحد في مركز بيانات Azure. يمكنك توفير إرشادات إلى Azure للتأكد من تشغيل الجهاز الظاهري في المكان الذي تتوقعه، مثل المنطقة ومنطقة التوفر، وفي بعض الحالات، قد ترغب في وضعه على مضيف مخصص لك.

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

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

النسخ المتماثل: التكرار للبيانات

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

هناك أنواع مختلفة من النسخ المتماثل، ويضع كل منها أولويات مختلفة حول تناسق البيانات والأداء والتكلفة. يؤثر كل نوع من أنواع النسخ المتماثل على مقياسين رئيسيين يستخدمان في مناقشات استمرارية الأعمال: هدف وقت الاسترداد (RTO)، وهو الحد الأقصى لمقدار وقت التعطل الذي يمكنك تحمله في سيناريو الكارثة، وهدف نقطة الاسترداد (RPO)، وهو الحد الأقصى لمقدار فقدان البيانات الذي يمكنك تحمله في سيناريو الكارثة. لمعرفة المزيد حول هذه المقاييس وكيفية ارتباطها باستمرارية الأعمال، راجع ما هي استمرارية الأعمال والتوافر العالي والتعافي من الكوارث؟.

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

هام

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

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

النسخ المتماثل المتزامن وغير المتزامن

عند نسخ البيانات نسخا متماثلا، يجب الاحتفاظ بأي تغييرات على تلك البيانات متزامنة بين النسخ المتماثلة. هناك بعض التحديات الأساسية عند محاولة الحفاظ على التناسق عند تغيير البيانات:

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

• إدارة التغيير. قد تتغير البيانات أثناء مزامنة النسخ المتماثلة وبالتالي يمكن أن تصبح إدارة تناسق البيانات معقدة.

لمواجهة هذه التحديات، هناك طريقتان رئيسيتان يمكنك من خلالهما نسخ تغييرات البيانات وإدارة تناسق البيانات:

• يتطلب النسخ المتماثل المتزامن إجراء تحديثات على نسخ متماثلة متعددة قبل اعتبار التحديث كاملا. يوضح الرسم التخطيطي التالي كيفية عمل النسخ المتماثل المتزامن:

  

  في هذا المثال، يحدث التسلسل التالي من الخطوات:

  1. يقوم العميل بتغيير البيانات، ويتم إرسال الطلب إلى النسخة المتماثلة 1، التي تعالج الطلب وتخزن البيانات التي تم تغييرها.
  2. ترسل النسخة المتماثلة 1 التغييرات إلى النسخة المتماثلة 2، التي تعالج الطلب وتخزن البيانات التي تم تغييرها.
  3. تقر النسخة المتماثلة 2 بالتغيير مرة أخرى إلى النسخة المتماثلة 1.
  4. تقر النسخة المتماثلة 1 بالتغيير مرة أخرى إلى العميل.

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

• يحدث النسخ المتماثل غير المتزامن في الخلفية. يوضح الرسم التخطيطي التالي كيفية عمل النسخ المتماثل غير المتزامن:

  

  في هذا المثال، يحدث التسلسل التالي من الخطوات:

  1. يقوم العميل بتغيير البيانات، ويتم إرسال الطلب إلى النسخة المتماثلة 1.
  2. تعالج النسخة المتماثلة 1 الطلب، وتخزن البيانات التي تم تغييرها، وتقر على الفور بالتغيير مرة أخرى إلى العميل.
  3. في وقت لاحق في وقت لاحق، تزامن النسخة المتماثلة 1 التغيير إلى النسخة المتماثلة 2.

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

أدوار النسخ المتماثلة

في العديد من أنظمة النسخ المتماثل، يمكن أن تأخذ النسخ المتماثلة أدوارا مختلفة، مما يساعد على تنسيق التغييرات على البيانات ويقلل من فرصة التعارضات. هناك نوعان رئيسيان من الأدوار، نشطوسلبي. هناك طريقتان شائعتان لتوزيع النسخ المتماثلة مع هذه الأدوار:

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

  

  في نظام نشط-سلبي، يحدد طول الوقت الذي يستغرقه تجاوز الفشل RTO. عادة ما يتم قياس RTO لنظام نشط-سلبي بالدقائق.

  تدعم بعض حلول النسخ المتماثل أيضا النسخ المتماثلة للقراءة فقط، والتي تمكنك من قراءة (ولكن ليس الكتابة) البيانات من النسخ المتماثلة السلبية. يمكن أن يكون هذا الأسلوب مفيدا للحصول على مزيد من الاستخدام من النسخ المتماثلة الخاصة بك، مثل عندما تحتاج إلى إجراء تحليلات أو إعداد تقارير حول البيانات دون التأثير على النسخة المتماثلة الأساسية التي تستخدمها لعمل معاملات التطبيق الخاص بك. تدعم العديد من خدمات Azure النسخ المتماثلة للقراءة فقط، بما في ذلك تخزين Azure مع نوع النسخ المتماثل GRS (RA-GRS) للوصول للقراءة، والنسخ المتماثل الجغرافي النشط لقاعدة بيانات Azure SQL.

• يتيح النسخ المتماثل النشط النشط استخدام نسخ متماثلة نشطة متعددة لحركة المرور المباشرة في وقت واحد، ويمكن لأي من النسخ المتماثلة معالجة الطلبات:

  

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

يمكن أن تجمع خدمات البيانات المعقدة بين النسخ المتماثل النشط والنشط-السلبي. على سبيل المثال، قد ينشرون مجموعة واحدة من النسخ المتماثلة في منطقة Azure واحدة وأخرى في منطقة مختلفة. داخل كل منطقة، تخدم النسخة المتماثلة النشطة الواحدة الطلبات بينما تقف نسخة متماثلة واحدة أو أكثر من النسخ المتماثلة السلبية بجانب تجاوز الفشل. وفي الوقت نفسه، تعمل كلتا المنطقتين في نموذج نشط-نشط، ما يسمح بتوزيع نسبة استخدام الشبكة عبرهما.

كيفية عمل النسخ المتماثل في خدمات بيانات Azure

تقدم كل خدمة Azure تخزن البيانات شكلا من أشكال النسخ المتماثل. ومع ذلك، قد تستخدم كل خدمة نهجا مختلفا خاصا ببنية الخدمة والاستخدامات المقصودة.

على سبيل المثال، يمكن أن يوفر Azure Storage كلا من النسخ المتماثل المتزامن وغير المتزامن من خلال مجموعة من القدرات:

• يتم نسخ نسخ متعددة من بياناتك بشكل متزامن داخل منطقتك الأساسية. يمكنك اختيار ما إذا كنت تريد وضع النسخ المتماثلة على أجهزة فعلية مختلفة في مركز بيانات واحد في التخزين الزائد محليا (LRS) أو توزيعها عبر مناطق توفر متعددة للتخزين المتكرر في المنطقة (ZRS).
• إذا تم إقران منطقتك الأساسية وقمت بتمكين التخزين المتكرر جغرافيا (GRS)، يتم أيضا نسخ البيانات نسخا متماثلا إلى المنطقة المقترنة. نظرا لأن المناطق المقترنة بعيدة جغرافيا، يحدث هذا النسخ المتماثل بشكل غير متزامن لتقليل التأثير على معدل نقل التطبيق الخاص بك.
• يمكنك اختيار استخدام التخزين المتكرر في المنطقة والتخزين المتكرر جغرافيا في وقت واحد باستخدام طبقة التخزين المتكررة للمنطقة الجغرافية (GZRS). يتم نسخ البيانات داخل المنطقة بشكل متزامن، ويتم نسخ البيانات عبر المناطق بشكل غير متزامن.

لمزيد من المعلومات، راجع تكرار Azure Storage.

مثال آخر هو Azure Cosmos DB، والذي يوفر أيضا النسخ المتماثل. تحتوي جميع قواعد بيانات Azure Cosmos DB على نسخ متماثلة متعددة. عند توزيع النسخ المتماثلة عالميا، فإنه يدعم عمليات الكتابة متعددة المناطق، حيث يمكن للعملاء الكتابة إلى نسخة متماثلة في أي من المناطق التي تستخدمها. يتم نسخ عمليات الكتابة هذه بشكل متزامن داخل المنطقة، ثم نسخها نسخا متماثلا بشكل غير متزامن عبر مناطق أخرى. يوفر Azure Cosmos DB آلية لحل التعارض في حالة وجود تعارضات في الكتابة عبر النسخ المتماثلة المختلفة. لمعرفة المزيد، راجع توزيع البيانات العمومية باستخدام Azure Cosmos DB - تحت الغطاء.

إذا كنت تستخدم الأجهزة الظاهرية، يمكنك استخدام Azure Site Recovery لنسخ الأجهزة الظاهرية وأقراصها بين مناطق التوفر أو إلى منطقة Azure أخرى.

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

نسخة احتياطية

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

باستخدام النسخ الاحتياطي، يمكنك توفير حلول لنسخ بياناتك احتياطيا واستردادها داخل سحابة Microsoft Azure أو إليها. يمكن أن يحميك النسخ الاحتياطي من مجموعة متنوعة من المخاطر، بما في ذلك:

• الخسائر الكارثية للأجهزة أو البنية الأساسية الأخرى.
• تلف البيانات وحذفها.
• الهجمات الإلكترونية، مثل برامج الفدية الضارة.

هام

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

كيف يؤثر النسخ الاحتياطي على متطلباتك

عند استخدامها كجزء من استراتيجية التعافي من الكوارث، تدعم النسخ الاحتياطية عادة RTO وRPO التي يتم قياسها بالساعات:

• يتأثر RTO بالوقت الذي تستغرقه لبدء عمليات الاسترداد وإكمالها، بما في ذلك استعادة نسخة احتياطية والتحقق من اكتمال الاستعادة بنجاح. اعتمادا على حجم النسخ الاحتياطي وعدد ملفات النسخ الاحتياطي التي تحتاج إلى القراءة منها، من الشائع أن يستغرق الأمر عدة ساعات أو حتى أكثر لاستعادة النسخة الاحتياطية بالكامل.

• يتأثر RPO بتردد عملية النسخ الاحتياطي. إذا كنت تأخذ النسخ الاحتياطية بشكل متكرر، فهذا يعني أنك تفقد بيانات أقل إذا كان عليك الاستعادة من نسخة احتياطية. ومع ذلك، تتطلب النسخ الاحتياطية التخزين، وفي بعض الحالات، قد تؤثر على أداء الخدمة أثناء أخذ النسخ الاحتياطية. لهذا السبب، تحتاج إلى النظر في تكرار النسخ الاحتياطي والعثور على التوازن الصحيح لمتطلبات مؤسستك. يجب أن يكون تكرار النسخ الاحتياطي أحد الاعتبارات في تخطيط استمرارية الأعمال.

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

النسخ الاحتياطي في خدمات Azure

توفر العديد من خدمات Azure إمكانات النسخ الاحتياطي لبياناتك.

يعد Azure Backup حلا مخصصا للنسخ الاحتياطي للعديد من خدمات Azure الرئيسية، بما في ذلك الأجهزة الظاهرية وتخزين Azure وخدمة Azure Kubernetes (AKS).

أيضا، توفر العديد من قواعد البيانات المدارة قدرات النسخ الاحتياطي الخاصة بها كجزء من الخدمة، مثل:

• توفر قاعدة بيانات Azure SQL نسخا احتياطية تلقائية.
• يوفر Azure Cosmos DB قدرات النسخ الاحتياطي المستمر والدوري.
• يمكنك Azure Key Vault من تنزيل نسخة احتياطية من البيانات في مخزنك.
• توفر Azure App Service نسخا احتياطيا تلقائيا ومخصصا لتطبيقات الويب، ويمكنها أيضا إجراء نسخ احتياطي لقواعد البيانات الخاصة بها.

النسخ الاحتياطي مقابل النسخ المتماثل

النسخ الاحتياطي والنسخ المتماثل يحميك كل منهما من المخاطر المختلفة، والنهجان متكاملان لبعضهما البعض.

يدعم النسخ المتماثل المرونة اليومية ويستخدم عادة في استراتيجية قابلية وصول عالية. تتطلب بعض نهج النسخ المتماثل القليل من وقت التعطل أو فقدان البيانات وتدعم RTO وRPO منخفضين. ومع ذلك، لا يحميك النسخ المتماثل من المخاطر التي تؤدي إلى فقدان البيانات أو تلفها.

في المقابل، غالبا ما يكون النسخ الاحتياطي خط دفاع أخير ضد المخاطر الكارثية. غالبا ما تتطلب النسخ الاحتياطية RTO وRPO عالية نسبيا، على الرغم من أن الطريقة التي تقوم بتكوين النسخ الاحتياطية تؤثر بالضبط على مدى ارتفاعها. غالبا ما يكون الاستعادة الإجمالية من النسخ الاحتياطي جزءا من خطة التعافي من الكوارث.

إعداد المكونات للتكرار

عند تصميم نظام يستخدم التكرار كجزء من بنيته، من المهم أيضا التفكير في كيفية:

• تكوين مورد مكرر للتناسق.
• إدارة السعة أثناء فشل المثيل عن طريق التوفير الزائد.

تكوين مورد مكرر

في بيئات السحابة، يعد تكوين كل مورد من مواردك أمرا بالغ الأهمية. على سبيل المثال، عند إنشاء موازن تحميل شبكة اتصال، يمكنك تكوين مجموعة متنوعة من الإعدادات التي تؤثر على كيفية عملها؛ وعند نشر دالة باستخدام Azure Functions، يمكنك تكوين الإعدادات المتعلقة بإعدادات الأمان والأداء وتكوين التطبيق. يحتوي كل مورد في Azure على نوع من التكوين الذي يدفع سلوكه.

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

يتمثل النهج الشائع للحفاظ على التناسق في مواردك في استخدام البنية الأساسية كتعليق برمجي (IaC)، مثل Bicep أو Terraform. تمكنك هذه الأدوات من إنشاء ملفات تحدد موردا، ويمكنك إعادة استخدام هذه التعريفات لكل مثيل للمورد. باستخدام IaC، يمكنك تقليل عبء إنشاء وإدارة مثيلات متعددة من الموارد لأغراض المرونة، وهناك العديد من الفوائد الأخرى أيضا. لمعرفة المزيد، راجع ما هي البنية الأساسية كتعليق برمجي (IaC)؟وتوصيات لاستخدام البنية الأساسية كتعليمية.

إدارة السعة مع الإفراط في التوفير

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

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

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

للإفراط في توفير مثيلات خادم الويب الخاص بك لحساب فشل منطقة توفر واحدة، اتبع الخطوات التالية:

1. حدد عدد المثيلات التي يتطلبها حمل العمل الأقصى.
2. استرداد عدد مثيلات التوفير الزائد عن طريق ضرب عدد مثيلات حمل العمل الذروة بعامل [(zones/(zones-1)].
3. تقريب النتيجة إلى أقرب رقم صحيح.

إشعار

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

ذروة عدد مثيلات حمل العمل	عامل [(zones/(zones-1)]	المعَادلة	مثيلات التوفير (مقربة)
3	3/2 أو 1.5	(3 × 1.5 = 4.5)	5 مثيلات
4	3/2 أو 1.5	(4 × 1.5 = 6)	6 مثيلات
5	3/2 أو 1.5	(5 × 1.5 = 7.5)	8 مثيلات
6	3/2 أو 1.5	(6 × 1.5 = 9)	9 مثيلات
7	3/2 أو 1.5	(7 × 1.5 = 10.5)	11 مثيلا
8	3/2 أو 1.5	(8 × 1.5 = 12)	12 مثيلا
9	3/2 أو 1.5	(9 × 1.5 = 13.5)	14 مثيلا
10	3/2 أو 1.5	(10 × 1.5 = 15)	15 مثيلا

في المثال السابق، يتطلب حمل العمل الذروة ستة مثيلات من خادم الويب، لذلك يتطلب الإفراط في التوفير ما مجموعه تسعة مثيلات:

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

تعرف على تجاوز الفشل وإرجاع الموارد.