SQL Server 2019: النسخ الكامل والتفاضلي وسجل المعاملات وخطة الاستعادة

حدد ما تستطيع خسارته ووقت العودة المطلوب

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

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

ثلاثة أنواع من النسخ لا تؤدي المهمة نفسها

النسخة التفاضلية تراكمية بالنسبة إلى قاعدة النسخ الكامل، وليست مجرد تغييرات منذ آخر نسخة تفاضلية. لذلك لا تخلطها مع مفهوم نسخ تزايدي عام. كما أن نوع Copy-only له دور خاص لا يغير قاعدة التفاضلي بالطريقة المعتادة؛ إذا كانت أدوات مختلفة تنشئ نسخاً إضافية، يجب أن يفهم المسؤول أثرها على السلسلة قبل الاعتماد عليها.

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

نموذج الاسترداد يغير ما يمكنك إعادته

نموذج الاسترداد خاصية لقاعدة البيانات تتحكم في تسجيل المعاملات ومتطلبات النسخ وأنواع الاستعادة الممكنة. يدعم Simple نسخ البيانات لكنه لا يدعم نسخ سجل المعاملات أو الاستعادة إلى نقطة زمنية عبرها. أما Full فيحتاج خطة نسخ للسجل، مع اكتمال السلسلة المطلوبة للوصول إلى النقطة المقصودة. ويوجد أيضاً Bulk-logged لحالات لها اعتبارات إضافية يراجعها المسؤول.

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

حوّل الجدول إلى مسؤوليات قابلة للمتابعة

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

1. اكتب RPO وRTO المتفق عليهما، وحدد قواعد البيانات التي يشملها الهدف.
2. راجع نموذج الاسترداد والنسخ الحالية مع المسؤول، بدلاً من افتراض الإعداد الافتراضي.
3. صمم علاقة الكامل والتفاضلي والسجل وفق الحجم ومعدل التغيير ووقت الاستعادة.
4. حدد التخزين والاحتفاظ وحقوق الوصول ومن يتلقى تنبيه الفشل ويتابعه.
5. دوّن ما يلزم للاستعادة، بما في ذلك الاعتمادات والمفاتيح المطلوبة إن كان التشفير مستخدماً.
6. اختبر الجدول عملياً وحدثه بعد تغير حجم القاعدة أو التطبيق أو متطلبات العمل.

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

فحص النسخة لا يعادل استعادة التطبيق

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

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

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

SQL Server 2019 في المتجر ودورة الحياة

يمكن مراجعة SQL Server 2019 Standard في KeyProTech لمطابقة المنتج مع تطبيقك وبيئتك. شراء الترخيص لا ينشئ خطة نسخ، ولا يثبت أن العرض يتضمن جميع حقوق الوصول أو خدمات التنفيذ أو التخزين. اسأل عن مواصفات العرض وحقوقه الفعلية، وافصلها عن تصميم التشغيل الذي يحتاجه تطبيقك.

تضع Microsoft SQL Server 2019 حالياً في مرحلة الدعم الممتد بعد انتهاء الدعم الأساسي في 2025، مع نهاية ممتدة في يناير 2030 وفق صفحة دورة الحياة. راجع الصفحة والتحديثات وتوافق التطبيق عند تخطيط استخدام جديد أو انتقال، ولا تعتبر نجاح التفعيل بديلاً عن متابعة الدعم. احتفظ بالفاتورة والجرد ونتيجة تجربة الاستعادة في ملف المشروع.

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