Share via

الاحتفاظ على المدى الطويل - قاعدة بياناتazure SQL والمثيل المدار لـ SQL Azure

  • مقالة

العديد من التطبيقات لها أغراض تنظيمية أو امتثال أو أعمال أخرى تتطلب منك الاحتفاظ بنسخ احتياطية لقاعدة البيانات بعد 7-35 يوماً التي توفرها قاعدة بيانات Azure SQL والنسخ الاحتياطي التلقائي لمثيل Azure SQL المدار. باستخدام ميزة الاستبقاء (LTR) على المدى الطويل، يمكنك تخزين قاعدة بيانات SQL المحددة والنسخ الاحتياطي الكامل للمثيل المدار SQL في موقع تخزين Azure Blob مع التكرار المكون لمدة تصل إلى 10 سنوات. يمكن استعادة النسخ الاحتياطية LTR بعد ذلك كقاعدة بيانات جديدة.

يمكن تمكين الاحتفاظ طويل الأمد لـAzure SQL Database ومثيل Azure SQL المُدار. توفر هذه المقالة نظرة عامة تصورية للاحتفاظ على المدى الطويل. لتكوين الاحتفاظ على المدى الطويل، راجع تكوين نسخ طويلة الأجل لقاعدة بيانات Azure SQLوتكوين نسخ طويلة الأجل للمثيل المدار Azure SQL.

ملاحظة

يمكنك استخدام مهام عامل SQL لجدولة النسخ الاحتياطية لقاعدة البيانات النسخ فقط كبديل للنسخ طويلة الأجل بعد 35 يوماً.

كيف يعمل الاحتفاظ على المدى الطويل

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

لتمكين LTR، يمكنك تعريف النهج باستخدام مجموعة من أربعة معلمات: الاحتفاظ بالنسخ الاحتياطي الأسبوعي (W)، والاحتفاظ بالنسخ الاحتياطي الشهري(M)، والاحتفاظ بالنسخ الاحتياطي السنوي(Y)، وأسبوع في السنة (WeekOfYear). إذا قمت بتحديد W، سيتم نسخ نسخة احتياطية واحدة كل أسبوع إلى التخزين طويل الأجل. إذا قمت بتحديد M، سيتم نسخ النسخ الاحتياطي الأول من كل شهر إلى التخزين على المدى الطويل. إذا قمت بتحديد Y، سيتم نسخ نسخة احتياطية واحدة خلال الأسبوع المحدد عن طريق WeekOfYear إلى التخزين طويل الأجل. إذا كان WeekOfYear المحدد في الماضي عند تكوين النهج، سيتم إنشاء أول نسخة احتياطية من LTR في السنة التالية. سيتم الاحتفاظ بكل نسخة احتياطية في التخزين طويل الأجل وفقاً لمعلمات النهج التي تم تكوينها عند إنشاء النسخة الاحتياطية لـ LTR.

ملاحظة

أي تغيير في نهج LTR ينطبق فقط على النسخ الاحتياطية المستقبلية. على سبيل المثال، إذا تم تعديل استبقاء النسخ الاحتياطية الأسبوعية (W) أو استبقاء النسخ الاحتياطية الشهرية (M) أو استبقاء النسخ الاحتياطية السنوية (Y)، فإن إعداد الاستبقاء الجديد سيطبق فقط على النسخ الاحتياطية الجديدة. لن يتم تعديل استبقاء النسخ الاحتياطية الموجودة. إذا كنت تنوي حذف النسخ الاحتياطية LTR القديمة قبل انتهاء فترة الاستبقاء، ستحتاج إلى حذف النسخ الاحتياطية يدوياً.

أمثلة على نهج LTR:

  • W = 0، M = 0، Y = 5، WeekOfYear = 3

    سيتم الاحتفاظ بالدعم الكامل الثالث من كل عام لمدة خمس سنوات.

  • W = 0، M = 3، Y = 0

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

  • W=12, M=0, Y=0

    سيتم الاحتفاظ بكل نسخة احتياطية أسبوعية كاملة لمدة 12 أسبوعاً.

  • W=6, M=12, Y=10, WeekOfYear=20

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

يوضح الجدول التالي إيقاع وانتهاء مدة النسخ الاحتياطية طويلة الأجل للنهج التالي:

W = 12 أسبوعاً (84 يوماً)، M = 12 شهراً (365 يوماً)، Y = 10 سنوات (3650 يوماً)، WeekOfYear = 20 (الأسبوع بعد 13 مايو)

ltr example

إذا قمت بتعديل النهج أعلاه وقمت بتعيين W = 0 (دون نسخ احتياطية أسبوعية)، فإن Azure تحتفظ فقط بالنسخ الاحتياطية الشهرية والسنوية. لا يتم تخزين نسخ احتياطية أسبوعية بموجب نهج LTR. كمية التخزين اللازمة للاحتفاظ بهذه النسخ الاحتياطية تقل وفقاً لذلك.

هام

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

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

النسخ الجغرافي والنسخ الاحتياطي على المدى الطويل

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

ملاحظة

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

تكوين استبقاء النسخ الاحتياطية على المدى الطويل

يمكنك تكوين الاستبقاء بالنسخ الاحتياطي على المدى الطويل باستخدام مدخل Microsoft Azure وPowerShell لقاعدة بيانات Azure SQL والمثيل المدار لـ Azure SQL. لاستعادة قاعدة بيانات من موقع تخزين LTR، يمكنك تحديد نسخة احتياطية محددة استناداً إلى الطابع الزمني. يمكن استعادة قاعدة البيانات إلى أي خادم موجود أو المثيل المدار ضمن نفس الاشتراك كقاعدة بيانات أصلية.

لمعرفة كيفية تكوين الاستبقاء على المدى الطويل أو استعادة قاعدة بيانات من النسخ الاحتياطي لقاعدة بيانات SQL باستخدام مدخل Azure أو PowerShell، راجع إدارة استبقاء النسخ الاحتياطي على المدى الطويل لقاعدة بيانات Azure SQL.

لمعرفة كيفية تكوين الاستبقاء على المدى الطويل أو استعادة قاعدة بيانات من النسخ الاحتياطي SQL للمثيل المدار باستخدام مدخل Azure أو PowerShell، راجع إدارة استبقاء النسخ الاحتياطي على المدى الطويل للمثيل المدار لـ Azure SQL.

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

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