اللقطة (Snapshot) مقابل النسخ الاحتياطي مقابل التعافي من الكوارث: ما الفرق؟

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

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

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

تُعد اللقطات أدوات تشغيلية قيّمة لأنها سريعة الإنشاء وسريعة التراجع — غالبًا ثوانٍ للإنشاء ودقائق للاسترجاع. من الأمثلة النموذجية أخذ لقطة قبل ترقية نظام التشغيل، أو قبل تغيير جوهري في الإعدادات، أو قبل تطبيق مجموعة تحديثات، أو قبل اختبار إصدار جديد من تطبيق على نسخة من جهاز إنتاجي. فإذا حدث خلل، يستطيع المسؤول التراجع خلال دقائق بدلًا من إعادة بناء الجهاز من الصفر.

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

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

هناك أيضًا خطر أدق: تحفظ اللقطة الحالة كما هي، بما في ذلك أي تلف أو برمجية خبيثة موجودة مسبقًا. فإذا أُخذت اللقطة بعد أن بدأ برنامج فدية بتشفير الملفات، لكن قبل أن يلاحظ أحد ذلك، فإنها تحفظ فقط الحالة المخترقة. أما النسخة الاحتياطية المستقلة، التي تُؤخذ وفق جدولها الخاص وتُخزَّن بشكل منفصل، فتمنحك مجموعة أوسع من النقاط الزمنية للاستعادة منها.

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

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

ولأن النسخة مستقلة عن مصدر التخزين، يمكن استخدامها لاستعادة ملف واحد، أو قرص كامل، أو جهاز افتراضي بأكمله حتى لو لم يعد الجهاز الأصلي أو مضيفه أو مصفوفة التخزين الأساسية موجودة أصلًا. تعتمد كثير من المؤسسات أسلوب «3-2-1» الكلاسيكي: ثلاث نسخ على الأقل من البيانات المهمة، على نوعين مختلفين من وسائط التخزين، مع الاحتفاظ بنسخة واحدة على الأقل خارج الموقع أو خارج النظام. كما تُعزَّز مستودعات النسخ الاحتياطي بشكل متزايد ضد العبث، عبر نوافذ عدم قابلية التعديل، أو بيانات اعتماد منفصلة، أو تخزين للكتابة مرة واحدة فقط، بحيث لا يستطيع المهاجم الذي يخترق بيئة الإنتاج حذف النسخ الاحتياطية أيضًا.

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

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

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

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

النسخ الاحتياطي عنصر من عناصر الحماية؛ أما التعافي من الكوارث فهو القدرة الشاملة التي تستخدم النسخ الاحتياطية والنسخ المتماثل والبنية التحتية معًا. يمكن أن تمتلك نسخًا احتياطية ممتازة ومُختبرة جيدًا، ومع ذلك تعجز عن استعادة خدمة بسرعة إن لم يكن هناك مكان للاستعادة إليه، أو تصميم شبكي لموقع التعافي، أو دليل تشغيل مُتدرَّب عليه.

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

مقياسان يشكّلان أي تصميم للحماية، وينبغي تحديد كليهما عن قصد لكل خدمة وليس افتراضهما:

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

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

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

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

لكل مستوى، حدد سياسة اللقطات، وجدول النسخ الاحتياطي ومدة الاحتفاظ المتوافقة مع RPO الخاص بذلك المستوى، وموقف التعافي من الكوارث — سواء تحتاج الخدمة إلى نسخة احتياطية جاهزة (warm standby) في مكان آخر، أو يكفيها الاستعادة من النسخة الاحتياطية ضمن RTO. يفيد أيضًا الفصل بين من يأخذ النسخ الاحتياطية ومن يستطيع حذفها، ومراجعة صلاحيات الوصول إلى مستودعات النسخ الاحتياطي دوريًا — فالحماية التي يمكن تعطيلها بصمت عبر حساب واحد مخترق ليست حماية حقيقية.

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

تجمع الاستراتيجية العملية بين الأساليب الثلاثة وفقًا لأهمية كل خدمة:

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

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

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