• تعليم
• ميكروسوفت
• شروحات

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

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

1. ما يعنيه "الاسترداد في نقطة زمنية" فعليًا

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

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

2. خدمة النسخ الاحتياطي للوحدات التخزينية (VSS): الأساس الذي يُبنى عليه ويندوز

تعتمد تقريبًا كل أشكال قدرات نقطة زمنية معينة على نظام ويندوز — بدءًا من علامة التبويب "الإصدارات السابقة" في خصائص الملف، وصولًا إلى محفوظات الملفات (File History)، والنسخ الاحتياطية المتسقة التي يعتمد عليها خادم النسخ الاحتياطي لويندوز ومعظم أدوات النسخ الاحتياطي من جهات خارجية — على مكون أساسي واحد: خدمة النسخ الاحتياطي للوحدات التخزينية، والتي عادة ما يتم اختصارها بـ VSS.

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

3. مستويان مختلفان تمامًا للاسترداد في نقطة زمنية معينة على ويندوز

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

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

4. لماذا لا يُعد النسخ الاحتياطي لخادم ويندوز استردادًا حقيقيًا في نقطة زمنية معينة

يستخدم خادم النسخ الاحتياطي لويندوز (Windows Server Backup)، وهو أداة النسخ الاحتياطي المدمجة في Windows Server، خدمة VSS لإنشاء لقطات على مستوى الكتلة (block-level snapshots) لوحدات التخزين بناءً على جدول زمني تحدده. إنها أداة محلية قوية لاسترداد النظام بالكامل وعلى مستوى وحدة التخزين، ويمكنها استرداد ملفات فردية، أو وحدات تخزين، أو أنظمة كاملة — لكنها تعمل بنفس المبدأ الخاص بأي أداة مجدولة لأخذ اللقطات: نقاط الاسترداد موجودة فقط في اللحظات التي تم فيها تشغيل مهمة النسخ الاحتياطي فعليًا.

إذا كانت آلية الاسترداد الوحيدة لديك هي مهمة نسخ احتياطي ليلي من Windows Server Backup، فلديك خطة قوية للتعافي من الكوارث — ولكن ليس لديك استرداد في نقطة زمنية معينة بالمعنى الدقيق، والأمر يستحق أن تكون دقيقًا بشأن هذا التمييز داخليًا بدلاً من اكتشافه أثناء وقوع حادث فعلي.

5. الاسترداد الحقيقي في نقطة زمنية معينة: سلسلة سجلات SQL Server

خادم SQL الذي يعمل على ويندوز هو أوضح مثال على الاسترداد الحقيقي في نقطة زمنية معينة المتاح في بيئة ويندوز النموذجية، ويعمل من خلال آلية تختلف تمامًا عن لقطات VSS: سجل المعاملات (transaction log).

يتم كتابة كل تغيير يطرأ على قاعدة بيانات خادم SQL تعمل في نموذج الاسترداد "الكامل" (Full) أولاً في سجل المعاملات قبل تطبيقه على ملفات البيانات. تلتقط النسخ الاحتياطية الدورية لسجل المعاملات هذا التدفق من التغييرات بشكل مستمر، بدلاً من مجرد لقطة للبيانات في لحظة واحدة. ونظرًا لأن السجل يحتوي على سجل كامل ومرتب لكل تغيير ومتى حدث بدقة، يمكن لـ SQL Server إعادة تشغيل هذا السجل حتى — والتوقف عند — أي نقطة دقيقة تحددها.

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

6. الأخطاء التي تعطل الاسترداد في نقطة زمنية معينة بصمت

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

• تشغيل قاعدة بيانات في نموذج الاسترداد البسيط (Simple recovery model)، والذي يقوم تلقائيًا باقتطاع سجل المعاملات ويجعل الاسترداد العشوائي في نقطة زمنية معينة مستحيلاً — تظل نقاط النسخ الاحتياطي الكاملة والتفاضلية فقط قابلة للاسترداد.
• ثغرات في سلسلة النسخ الاحتياطي لسجل المعاملات — إذا فشل نسخ احتياطي مجدول واحد للسجل بصمت ولم يلاحظ أحد، فإن كل عملية استرداد في نقطة زمنية معينة بعد تلك الفجوة تصبح مستحيلة حتى تقوم نسخة احتياطية كاملة جديدة بإعادة تشغيل السلسلة.
• افتراض أن جدول نسخ الظل (shadow copy) على مستوى الملفات يوفر نفس الضمان الذي توفره سلسلة سجلات قاعدة البيانات، في حين أنه يوفر فقط استردادًا إلى لحظات لقطات منفصلة.
• عدم اختبار الاسترداد على الإطلاق — النسخة الاحتياطية أو سلسلة السجلات التي لم يتم استردادها عمليًا هي افتراض، وليست قدرة تم التحقق منها.
• سياسات الاحتفاظ (Retention policies) التي تقوم بحذف النسخ الاحتياطية للسجلات بشكل أسرع مما قد يحتاجه أي شخص بشكل واقعي للرجوع إليها، مما يقضي على نافذة الاسترداد قبل حتى أن يتم اكتشاف وقوع الحادث.

7. بناء الاسترداد في نقطة زمنية معينة في بيئة ويندوز بشكل صحيح

• حدد الأنظمة التي تحتاج حقًا إلى دقة استرداد على مستوى الثانية — عادةً قواعد البيانات القائمة على المعاملات — مقابل الأنظمة التي تخدمها بشكل كافٍ لقطات مجدولة على مستوى الملفات.
• لقواعد بيانات خادم SQL التي تتطلب PITR، تأكد من ضبط نموذج الاسترداد على "الكامل" (Full) (أو "المسجل المجمع" حيثما يكون ذلك مناسبًا)، وليس "البسيط" (Simple).
• قم بجدولة النسخ الاحتياطية لسجل المعاملات بشكل متكرر بما يكفي بحيث تتطابق نافذة فقدان البيانات المقبولة لديك مع متطلبات العمل — الفترة الزمنية بين النسخ الاحتياطية للسجلات تحدد أسوأ فجوة استرداد متوقعة.
• راقب سلسلة النسخ الاحتياطي بنشاط، واضبط التنبيهات لأي فشل أو تخطي لعملية نسخ السجل احتياطيًا بدلاً من مراقبة نجاح النسخ الاحتياطي الكامل فقط.
• قم بإجراء عمليات استرداد تجريبية بشكل دوري للوصول إلى طابع زمني محدد، وليس فقط للتحقق من وجود ملف نسخة احتياطية.
• احتفظ بالاسترداد على مستوى الملفات المستند إلى VSS (نسخ الظل، محفوظات الملفات) كطبقة تكميلية لفقدان الملفات العرضي، مع فهم واضح بأنها ليست بديلاً عن PITR على مستوى قاعدة البيانات.
• وثّق هدف نقطة الاسترداد (RPO) وهدف وقت الاسترداد (RTO) الفعلي الخاص بك بشكل صريح، وتحقق من أن إعدادك الحالي يلبي هذه الأهداف فعليًا بدلاً من افتراض أنه يفعل ذلك.

الخلاصة

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

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