النسخ الاحتياطية المؤتمتة – قاعدة بيانات Azure SQL & مثيل Azure SQL المُدار

ينطبق على: قاعدة بيانات Azure SQL مثيل Azure SQL المدار

ملاحظة

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

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

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

أساسيات النسخ الاحتياطي والاستعادة

تستخدم قواعد البيانات في قواعد بيانات Azure SQL المُدارة وقواعد البيانات غير Hyperscale في Azure SQL Database تقنية محرك SQL Server لنسخ البيانات احتياطياً واستعادتها. قواعد بيانات Hyperscale لها بنية فريدة من نوعها والاستفادة من تقنية مختلفة للنسخ الاحتياطي والاستعادة. لمعرفة المزيد، راجع النُسخ الاحتياطية وتكرار تخزين Hyperscale.

تردد النسخ الاحتياطي

تستخدم كل من Azure SQL Database وAzure SQL المُدارة تقنية Microsoft SQL Server لإنشاء نسخ احتياطية كاملة كل أسبوع، ونسخ احتياطية تفاضلية كل 12-24 ساعة، ونسخ احتياطية لسجل العمليات كل 5 إلى 10 دقائق. يعتمد تكرار النسخ الاحتياطي للسجل على حجم الحساب ومقدار نشاط قاعدة البيانات.

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

تستخدم قواعد البيانات Hyperscale تقنية النسخ الاحتياطي للقطات.

تكرار تخزين النسخ الاحتياطية

بشكل افتراضي؛ تقوم Azure SQL Database وAzure SQL المُدار بتخزين البيانات في كتل تخزين كبيرة جغرافية مكررة يتم نسخها إلى منطقة مقترنة. يساعد التكرار الجغرافي في الحماية من الانقطاعات التي تؤثر على تخزين النسخ الاحتياطي في المنطقة الأساسية ويسمح لك باستعادة الخادم الخاص بك إلى منطقة مختلفة في حالة وقوع كارثة.

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

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

هام

لا تتوفر مساحة التخزين الزائدة عن الحاجة حالياً إلا في مناطق معينة.

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

يمكنك استخدام هذه النسخ الاحتياطية لإجراء ما يلي:

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

    هام

    الاستعادة الجغرافية متاحة فقط لقواعد البيانات في Azure SQL Database أو المثيلات المدارة التي تم تكوينها مع تخزين النسخ الاحتياطي الجغرافي المكرر. إذا كنت لا تستخدم حالياً نُسخاً احتياطية منسوخة في مواقع جغرافية مختلفة لقاعدة بيانات، يمكنك تغيير ذلك عن طريق تكوين التكرار لتخزين النسخ الاحتياطي.

  • استعادة من نسخة احتياطية طويلة المدى - استعادة قاعدة بيانات من نسخة احتياطية طويلة الأجل محددة لقاعدة بيانات واحدة أو قاعدة بيانات مجمعة، إذا تم تكوين قاعدة البيانات باستخدام قاعدة بيانات طويلة المدى سياسة الاحتفاظ (LTR). يسمح لك LTR باستعادة إصدار قديم من قاعدة البيانات باستخدام مدخل Microsoft Azure أو Azure CLI أو Azure PowerShell لتلبية طلب الامتثال أو لتشغيل إصدار قديم من التطبيق. للحصول على مزيدٍ من المعلومات، راجع الاستبقاء طويل الأمد.

ملاحظة

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

استعادة إمكانيات وميزات قاعدة بيانات Azure SQL ومثيل Azure SQL المُدار

يلخص هذا الجدول إمكانات وميزات استرداد في نقطة زمنية (PITR) والاسترداد الجغرافي و النسخ الاحتياطية للاستبقاء طويل المدى.

خصائص النسخ الاحتياطي  استرداد في نقطة زمنية (PITR) الاستعادة الجغرافية استعادة النسخ الاحتياطي على المدى الطويل
أنواع النسخ الاحتياطي لـ SQL سجل تفاضلي كامل نسخ من النسخ الاحتياطية PITR النسخ الاحتياطي الكامل فقط
هدف نقطة الاسترداد (RPO)   5 -10 دقائق، استنادا إلى حجم الحساب ومقدار نشاط قاعدة البيانات.   حتى ساعة واحدة، استنادًا إلى النسخ المتماثل للموقع الجغرافي.*   أسبوع واحد (أو سياسة المستخدم).
هدف وقت الاسترداد (RTO) عادة ما تستغرق عملية الاستعادة <12 ساعة، ولكن قد تستغرق وقتًا أطول على حسب الحجم والنشاط. راجع الاسترداد عادة ما تستغرق عملية الاستعادة <12 ساعة، ولكن قد تستغرق وقتًا أطول على حسب الحجم والنشاط. راجع الاسترداد. عادة ما تستغرق عملية الاستعادة <12 ساعة، ولكن قد تستغرق وقتًا أطول على حسب الحجم والنشاط. راجع الاسترداد.
الاحتفاظ 7 أيام بشكل افتراضي، حتى 35 يوما   مُمَكَّن بشكل افتراضي، مثل المصدر.** غير ممكن افتراضيا، استبقاء البيانات حتى 10 سنوات.
موقع تخزين Azure   زائدة عن الحاجة جغرافيا بشكل افتراضي. يمكن تكوين المنطقة اختيارياً أو التخزين الزائد محلياً. متاح عندما يتم تعيين التكرار في تخزين النسخ الاحتياطي لـ PITR على Geo-redundant. غير متاح عندما يكون مخزن النسخ الاحتياطي لـ PITR منطقة أو تخزيناً زائداً محلياً.  زائدة عن الحاجة جغرافيا بشكل افتراضي. يمكن تكوين المنطقة أو التخزين الزائد محلياً.
يُستخدم لإنشاء قاعدة بيانات جديدة في نفس المنطقة مدعوم مدعوم  مدعوم
استخدم لإنشاء قاعدة بيانات جديدة في منطقة أخرى غير مدعومة مدعوم في أي منطقة أزور مدعوم في أي منطقة أزور
تستخدم لإنشاء قاعدة بيانات جديدة في اشتراك آخر غير مدعومة غير مدعوم*** غير مدعوم***
استعادة عبر مدخل Microsoft Azure نعم نعم نعم
استعادة عبر PowerShell نعم نعم نعم
استعادة عبر Azure CLI نعم نعم نعم

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

** يتم تخزين جميع نسخ PITR الاحتياطية على مساحة تخزين زائدة عن الحاجة جغرافياً بشكل افتراضي. ومن ثم، يتم تمكين الاستعادة الجغرافية افتراضياً.

*** الحل البديل هو الاستعادة إلى خادم جديد واستخدام «Resource Move» لنقل الخادم إلى اشتراك آخر.

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

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

‏‏التشغيل مدخل Azure Azure CLI Azure PowerShell
تغيير استبقاء النسخة الاحتياطية قاعدة بيانات SQL
مثيل SQL المدار
قاعدة بيانات SQL
مثيل SQL المدار
قاعدة بيانات SQL
مثيل SQL المدار
تغيير الاحتفاظ بالنسخ الاحتياطي طويل المدى قاعدة بيانات SQL
مثيل SQL المدار
قاعدة بيانات SQL
مثيل SQL المدار
قاعدة بيانات SQL
مثيل SQL المدار
استعادة قاعدة بيانات من نقطة زمنية قاعدة بيانات SQL
مثيل SQL المدار
قاعدة بيانات SQL
مثيل SQL المدار
قاعدة بيانات SQL
مثيل SQL المدار
استعادة قاعدة بيانات محذوفة قاعدة بيانات SQL
مثيل SQL المدار
قاعدة بيانات SQL
مثيل SQL المدار
قاعدة بيانات SQL
مثيل SQL المدار
استعادة قاعدة بيانات من موقع تخزين كائن ثنائي كبير الحجم من Azure
مثيل SQL المدار

جدولة النسخ الاحتياطي

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

هام

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

استهلاك التخزين الاحتياطي

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

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

ملاحظة

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

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

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

تقوم Azure SQL Database وAzure SQL المُدارة بحساب إجمالي تخزين النسخ الاحتياطي المستخدم كقيمة تراكمية. كل ساعة، يتم الإبلاغ عن هذه القيمة إلى مسار فوترة Azure، المسؤول عن تجميع هذا الاستخدام لكل ساعة لحساب استهلاكك في نهاية كل شهر. بعد حذف قاعدة البيانات، يقل الاستهلاك مع انقضاء عمر النسخ الاحتياطية ويتم حذفها. بمجرد حذف جميع النسخ الاحتياطية ولم يعد PITR ممكناً، وتتوقف الفوترة.

هام

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

مراقبة الاستهلاك

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

Monitor database backup consumption in the Azure portal

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

ضبط استهلاك تخزين النسخ الاحتياطي بدقة

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

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

استبقاء النسخ الاحتياطية

توفر قاعدة بيانات Azure SQL ومثيل Azure SQL المُدار الاحتفاظ بالنسخ الاحتياطية على المدى القصير والطويل. تسمح النسخ الاحتياطية للاحتفاظ قصيرة المدى باستعادة Point-In-Time-Restore (PITR) خلال فترة الاحتفاظ لقاعدة البيانات، بينما يوفر الاحتفاظ طويل الأجل نسخاً احتياطية لمتطلبات الامتثال المختلفة.

الاستبقاء على المدى القصير

لجميع قواعد البيانات الجديدة والمستعادة والمنسوخة، تستبقي قاعدة بيانات Azure SQL وAzure SQL المُدار بالنسخ الاحتياطية الكافية للسماح لـ PITR خلال الأيام السبعة الأخيرة بشكل افتراضي. يتم أخذ النسخ الاحتياطية الكاملة والتفاضلية والسجلات بانتظام لضمان إمكانية استعادة قواعد البيانات إلى أي نقطة زمنية خلال فترة الاحتفاظ المحددة لقاعدة البيانات أو المثيل المُدار. بالإضافة إلى ذلك، بالنسبة لقواعد بيانات Azure SQL، يمكن تكوين النسخ الاحتياطية التفاضلية لتكرار 12 ساعة أو 24 ساعة.

ملاحظة

قد يؤدي تكرار النسخ الاحتياطي التفاضلي على مدار 24 ساعة إلى زيادة الوقت المطلوب لاستعادة قاعدة البيانات.

باستثناء قواعد بيانات المستوى Basic، يمكنك تغيير فترة الاستبقاء بالنسخ الاحتياطي لكل قاعدة بيانات نشطة في نطاق 1-35 يوماً. كما هو موضح في استهلاك تخزين النسخ الاحتياطي ، قد تكون النسخ الاحتياطية المخزنة لتمكين PITR أقدم من فترة الاحتفاظ. بالنسبة لمثيل Azure SQL المُدار فقط، من الممكن تعيين معدل الاحتفاظ بالنسخ الاحتياطي لـ PITR بمجرد حذف قاعدة البيانات في نطاق 0-35 يوماً.

ملاحظة

استبقاء النسخ الاحتياطي على المدى القصير لمدة 1-35 يوماً لقواعد بيانات Hyperscale قيد المعاينة الآن. لمعرفة المزيد، راجع إدارة استبقاء النسخ الاحتياطي في Hyperscale.

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

هام

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

أحياناً ما يسمى الاحتفاظ بالنسخ الاحتياطي لأغراض PITR خلال الأيام 1-35 الأخيرة بالاحتفاظ بالنسخ الاحتياطي قصير المدى. إذا كنت بحاجة إلى الاحتفاظ بنسخ احتياطية لمدة أطول من الحد الأقصى لفترة الاحتفاظ قصيرة المدى البالغة 35 يوماً، فيمكنك تمكين الاحتفاظ طويل المدى .

الاحتفاظ طويل الأجل بالبيانات

بالنسبة لكل من قاعدة بيانات SQL ومثيل SQL المُدار، يمكنك تكوين الاحتفاظ بنسخة احتياطية كاملة طويلة المدى (LTR) لمدة تصل إلى 10 سنوات في تخزين Azure Blob. بعد تكوين سياسة LTR، يتم نسخ النسخ الاحتياطية الكاملة تلقائياً إلى حاوية تخزين مختلفة أسبوعياً. لتلبية متطلبات الامتثال المختلفة، يمكنك تحديد فترات احتفاظ مختلفة للنسخ الاحتياطية الكاملة الأسبوعية والشهرية و/ أو السنوية. يعتمد استهلاك التخزين على التردد المحدد وفترات الاحتفاظ بالنسخ الاحتياطية من LTR. يمكنك استخدام حاسبة تسعير LTR لتقدير تكلفة تخزين LTR.

هام

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

لمزيد من المعلومات حول LTR، راجع الاحتفاظ بالنسخ الاحتياطي طويل المدى.

تكاليف التخزين الاحتياطي

يختلف سعر التخزين الاحتياطي ويعتمد على نموذج الشراء (DTU أو vCore)، وخيار التكرار المختار لتخزين النسخ الاحتياطي، وكذلك على منطقتك. يتم احتساب تكلفة تخزين النسخ الاحتياطي لكل جيجابايت / شهر مستهلك، للتسعير، راجع صفحة تسعير قاعدة بيانات Azure SQL وصفحة تسعير مثيل Azure SQL المُدار .

لمزيد من المعلومات حول شراء النماذج، راجع الاختيار بين نموذجي الشراء vCore وDTU.

ملاحظة

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

نموذج DTU

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

نموذج vCore

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

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

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

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

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

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

Total billable backup storage size = (total size of full backups + total size of differential backups + total size of log backups) – maximum instance data storage

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

يمكن العثور على الصيغ المستخدمة لحساب تكاليف تخزين النسخ الاحتياطي لقواعد بيانات Hyperscale في تكاليف تخزين النسخ الاحتياطي Hyperscale.

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

كمثال مبسط، افترض أن قاعدة البيانات جمعت 744 جيجا بايت من تخزين النسخ الاحتياطي وأن هذا المقدار يظل ثابتاً طوال شهر كامل لأن قاعدة البيانات معطلة تماماً. لتحويل استهلاك التخزين التراكمي هذا إلى الاستخدام بالساعة، قسّمه على 744.0 (31 يوماً في الشهر * 24 ساعة في اليوم). ستقوم قاعدة بيانات SQL بإبلاغ مسار فوترة Azure بأن قاعدة البيانات استهلكت 1 غيغابايت من النسخ الاحتياطي لـ PITR كل ساعة، بمعدل ثابت. ستعمل فوترة Azure على تجميع هذا الاستهلاك وإظهار استخدام 744 غيغابايت للشهر بأكمله. ستعتمد التكلفة على المبلغ / جيجابايت / شهر في منطقتك.

الآن، مثال أكثر تعقيداً. لنفترض أن قاعدة البيانات الخاملة نفسها قد تمت زيادة الاحتفاظ بها من سبعة أيام إلى 14 يوماً في منتصف الشهر. تؤدي هذه الزيادة إلى مضاعفة إجمالي مساحة تخزين النسخ الاحتياطي إلى 1،488 جيجا بايت. ستقوم قاعدة بيانات SQL بالإبلاغ عن 1 غيغابايت من الاستخدام للساعات من 1 إلى 372 (النصف الأول من الشهر). سيُعلن عن استخدام 2 غيغابايت للساعات من 373 إلى 744 (النصف الثاني من الشهر). سيتم تجميع هذا الاستخدام في فاتورة نهائية قدرها 1116 جيجابايت / شهر.

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

يمكنك مراقبة إجمالي استهلاك تخزين النسخ الاحتياطي لكل نوع نسخة احتياطية (كامل، تفاضلي، سجل معاملات) بمرور الوقت كما هو موضح في مراقبة الاستهلاك .

تكرار تخزين النسخ الاحتياطية

يؤثر التكرار في تخزين النسخ الاحتياطي على تكاليف النسخ الاحتياطي بالطريقة التالية:

  • سعر زائد عن الحاجة محليا = x
  • سعر المنطقة الزائدة عن الحاجة = 1.25x
  • السعر الزائد جغرافياً = 2x

لمزيد من التفاصيل حول تسعير التخزين الاحتياطي، تفضل بزيارة صفحة تسعير قاعدة بيانات Azure SQL و صفحة تسعير مثيل Azure SQL المُدار .

هام

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

مراقبة التكاليف

لفهم تكاليف التخزين الاحتياطي، انتقل إلى إدارة التكلفة + الفوترة في مدخل Microsoft Azure، وحدد إدارة التكلفة، ثم حدد تحليل التكلفة. حدد الاشتراك المطلوب باعتباره النطاق، ثم قم بالتصفية حسب الفترة الزمنية والخدمة التي تهتم بها على النحو التالي:

  1. قم بإضافة عامل تصفية لـ اسم الخدمة.
  2. في القائمة المنسدلة، حدد قاعدة بيانات SQL لقاعدة بيانات أحادية أو تجمع قاعدة بيانات مرنة، أو حدد مثيل SQL المدار للمثيل المدار.
  3. قم بإضافة عامل تصفية آخر لـ فئة فرعية قياسية.
  4. لمراقبة تكاليف النسخ الاحتياطي لـ PITR، في القائمة المنسدلة، حدد تخزين النسخ الاحتياطي لـ pitr لتجمع أحادي / مرن لقاعدة بيانات أحادية أو تجمع قاعدة بيانات مرنة، أو حدد تخزين النسخ الاحتياطي pitr للمثيل المُدار للمثيل المُدار. ستظهر العدادات فقط إذا كان هناك استهلاك.
  5. لمراقبة تكاليف النسخ الاحتياطي LTR، في القائمة المنسدلة، حدد تخزين النسخ الاحتياطي ltr لقاعدة بيانات أحادية أو تجمع قاعدة بيانات مرنة، أو حدد مثيل SQL المُدار - تخزين النسخ الاحتياطي ltr للمثيل المُدار. ستظهر العدادات فقط إذا كان هناك استهلاك.

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

Backup storage cost analysis

هام

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

للحصول على مزيدٍ من المعلومات، راجع إدارة تكلفة قاعدة بيانات Azure SQL.

النسخ الاحتياطية المشفرة

إذا كانت قاعدة البيانات الخاصة بك مشفرة باستخدام TDE، فسيتم تشفير النسخ الاحتياطية تلقائياً في حالة عدم التشغيل، بما في ذلك النسخ الاحتياطية LTR. يتم تكوين جميع قواعد البيانات الجديدة في Azure SQL مع تمكين TDE افتراضياً. لمزيد من المعلومات حول TDE، راجع تشفير البيانات الشفاف باستخدام قاعدة بيانات SQL & مثيل SQL المُدار.

تكامل النسخ الاحتياطي

بشكل مستمر، يقوم الفريق الهندسي في Azure SQL باختبار استعادة النسخ الاحتياطية التلقائية لقاعدة البيانات تلقائياً. (هذا الاختبار غير متوفر حالياً في SQL Managed Instance. يجب عليك جدولة DBCC CHECKDB على قواعد البيانات الخاصة بك في SQL Managed Instance، المجدولة في حمل العمل الخاص بك.)

عند الاستعادة في الوقت المناسب، تتلقى قواعد البيانات أيضاً فحوصات تكامل CHECKDB DBCC.

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

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

التوافق

عندما تقوم بترحيل قاعدة البيانات الخاصة بك من طبقة الخدمة المستندة إلى DTU إلى طبقة الخدمة المستندة إلى vCore، يتم الاحتفاظ بالاحتفاظ بـ PITR لضمان عدم تعرض سياسة استرداد البيانات للتطبيق الخاص بك للخطر. إذا كان الاحتفاظ الافتراضي لا يفي بمتطلبات الامتثال الخاصة بك، فيمكنك تغيير فترة الاحتفاظ بـ PITR. للحصول على مزيدٍ من المعلومات، راجع تغيير فترة الاحتفاظ بنسخة احتياطية PITR.

ملاحظة

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

قم بتغيير سياسة الاحتفاظ قصيرة المدى

يمكنك تغيير فترة الاحتفاظ الافتراضية للنسخ الاحتياطي لـ PITR وتكرار النسخ الاحتياطي التفاضلي باستخدام مدخل Microsoft Azure أو PowerShell أو واجهة برمجة تطبيقات REST. توضح الأمثلة التالية كيفية تغيير الاحتفاظ بـ PITR إلى 28 يوماً والنسخ الاحتياطية التفاضلية إلى فاصل زمني 24 ساعة.

تحذير

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

ملاحظة

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

قم بتغيير نهج الاستبقاء قصير المدى باستخدام مدخل Microsoft Azure

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

تغيير نهج الاستبقاء قصير الأجل باستخدام Azure CLI

قم بتحضير بيئتك لـ Azure CLI.

قم بتغيير الاحتفاظ بالنسخ الاحتياطي لـ PITR وتكرار النسخ الاحتياطي التفاضلي لقواعد بيانات Azure SQL النشطة باستخدام المثال التالي.

# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be between 1 and 35 days
# Valid differential backup frequency must be ether 12 or 24
az sql db str-policy set \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --retention-days 28 \
    --diffbackup-hours 24

تغيير نهج الاستبقاء قصير الأجل باستخدام PowerShell

ملاحظة

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

هام

لا تزال الوحدة النمطية PowerShell AzureRM مدعومة بواسطة قاعدة بيانات SQL والمثيل المُدار من SQL، ولكن كل التطوير المستقبلي مخصص للوحدة النمطية Az.Sql. للحصول على مزيدٍ من المعلومات، راجع AzureRM.Sql . تتطابق الوسائط الخاصة بالأوامر الموجودة في الوحدة النمطية Az إلى حد كبير مع تلك الموجودة في وحدات AzureRm النمطية.

لتغيير الاحتفاظ بالنسخ الاحتياطي لـ PITR وتكرار النسخ الاحتياطي التفاضلي لقواعد بيانات Azure SQL النشطة، استخدم مثال PowerShell التالي.

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28
# SET new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24. 
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24

قم بتغيير سياسة الاحتفاظ قصيرة المدى باستخدام واجهة برمجة تطبيقات REST

يقوم الطلب أدناه بتحديث فترة الاستبقاء إلى 28 يوماً، كما يقوم بتعيين تردد النسخ الاحتياطي التفاضلي على 24 ساعة.

طلب عينة

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2021-02-01-preview

نص الطلب

{ 
    "properties":{
        "retentionDays":28,
        "diffBackupIntervalInHours":24
  }
}

استجابة النموذج:

{ 
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28,
    "diffBackupIntervalInHours":24
  }
}

لمزيد من المعلومات، راجع واجهة برمجة تطبيقات REST.

النسخ الاحتياطية المفرطة والتخزين الاحتياطي

تستخدم قواعد البيانات Hyperscale في Azure SQL Database بنية فريدة مع تخزين قابل للتوسع بدرجة كبيرة وطبقات أداء حسابية.

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

أداء النسخ الاحتياطي والاستعادة لـ Hyperscale

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

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

Hyperscale الاحتفاظ بالنسخ الاحتياطي

الاستبقاء الافتراضي بالنسخ الاحتياطي قصير الأجل (STR) لقواعد بيانات Hyperscale هو 7 أيام؛ نهج الاستبقاء على المدى الطويل (LTR) غير مدعوم حالياً.

ملاحظة

استبقاء النسخ الاحتياطي على المدى القصير لمدة 35 يوماً لقواعد بيانات Hyperscale قيد المعاينة الآن.

جدولة النسخ الاحتياطي Hyperscale

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

تكاليف تخزين النسخ الاحتياطي Hyperscale

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

بالنسبة إلى Hyperscale، يتم حساب تخزين النسخ الاحتياطي القابل للفوترة على النحو التالي:

Total billable backup storage size = (Data backup storage size + Log backup storage size)

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

تتحمل قواعد بيانات Hyperscale المحذوفة تكاليف النسخ الاحتياطي لدعم الاسترداد إلى نقطة زمنية قبل الحذف. بالنسبة لقاعدة بيانات Hyperscale المحذوفة، يتم حساب تخزين النسخ الاحتياطي القابل للفوترة على النحو التالي:

Total billable backup storage size for deleted Hyperscale database = (Data storage size + Data backup size + Log backup storage size) * (remaining backup retention period after deletion/configured backup retention period)

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

استهلاك النسخ الاحتياطي لمراقبة Hyperscale

في Hyperscale، يتم الإبلاغ عن حجم تخزين النسخ الاحتياطي للبيانات (حجم النسخ الاحتياطي للقطة) وحجم تخزين البيانات (حجم قاعدة البيانات) وحجم تخزين النسخ الاحتياطي للسجل (حجم النسخ الاحتياطي لسجل المعاملات) عبر قياسات Azure Monitor.

لعرض قياسات النسخ الاحتياطي وتخزين البيانات في مدخل Azure، اتبع الخطوات التالية:

  1. انتقل إلى قاعدة بيانات Hyperscale التي ترغب في مراقبة قياسات النسخ الاحتياطي وتخزين البيانات لها.
  2. حدد صفحة "القياسات" في قسم المراقبة.

Screenshot of the Azure portal showing the Hyperscale Backup storage metrics

  1. من القائمة المنسدلة "قياسات"، حدد قياسات تخزين النسخ الاحتياطي للبيانات و سجل تخزين النسخ الاحتياطي بقاعدة تجميع مناسبة.

تقليل استهلاك تخزين النسخ الاحتياطي

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

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

ينطبق التكرار التخزيني المفرط على كل من تخزين البيانات وتخزين النسخ الاحتياطي

يدعم Hyperscale التكرار التخزيني القابل للتكوين. عند إنشاء قاعدة بيانات Hyperscale، يمكنك اختيار نوع التخزين المفضل لديك: تخزين احتياطي جغرافي قابل للقراءة (RA-GRS)، أو تخزين زائدة عن الحاجة (ZRS)، أو التخزين المحلي الزائد (LRS) تخزين Azure القياسي. يُستخدم خيار تكرار التخزين المُحدد طوال مدة بقاء قاعدة البيانات لكل من تكرار تخزين البيانات وتكرار تخزين النسخ الاحتياطي.

ضع في اعتبارك التكرار في التخزين بعناية عند إنشاء قاعدة بيانات Hyperscale

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

هام

لا تتوفر مساحة التخزين الزائدة عن الحاجة حالياً إلا في مناطق معينة.

استعادة قاعدة بيانات Hyperscale إلى منطقة مختلفة

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

  1. أنشئ خادماً في المنطقة المستهدفة إذا لم يكن لديك بالفعل خادم مناسب هناك. يجب أن يكون هذا الخادم مملوكاً لنفس الاشتراك مثل الخادم الأصلي (المصدر).
  2. اتبع الإرشادات الواردة في قسم الاستعادة الجغرافية من الصفحة عن استعادة قاعدة بيانات في Azure SQL Database من النسخ الاحتياطية التلقائية.

ملاحظة

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

إذا كنت تفضل ذلك، يمكنك نسخ قاعدة البيانات إلى منطقة مختلفة أيضاً. تعرف على معلومات عن Database Copy for Hyperscale.

تكوين التكرار لتخزين النسخ الاحتياطي

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

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

قم بتكوين النسخ الاحتياطي باستخدام مدخل Microsoft Azure

في مدخل Microsoft Azure الإلكترونية، يمكنك تكوين التكرار لتخزين النسخ الاحتياطي في جزء إنشاء قاعدة بيانات SQL. يتوفر الخيار ضمن قسم التكرار الزائد للتخزين الاحتياطي.

Open Create SQL Database pane

قم بتكوين النسخ الاحتياطي الزائد باستخدام Azure CLI

لتكوين تكرار تخزين النسخ الاحتياطي عند إنشاء قاعدة بيانات جديدة، يمكنك تحديد المعامل --backup-storage-redundancy باستخدام الأمر az sql db create. القيم المحتملة هي Geo وZone وLocal. بشكل افتراضي، تستخدم جميع قواعد البيانات في Azure SQL Database تخزيناً متكرراً جغرافياً للنسخ الاحتياطية. يتم تعطيل الاستعادة الجغرافية إذا تم إنشاء قاعدة بيانات أو تحديثها مع تخزين النسخ الاحتياطي المحلي أو المنطقة.

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

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier GeneralPurpose \
    --backup-storage-redundancy Local

ضع في اعتبارك بعناية خيار التكوين لـ--backup-storage-redundancy عند إنشاء قاعدة بيانات Hyperscale. لا يمكن تحديد التكرار في التخزين إلا أثناء عملية إنشاء قاعدة البيانات لقواعد بيانات Hyperscale. سيتم استخدام خيار التكرار التخزيني المحدد طوال عمر قاعدة البيانات لكل من تكرار تخزين البيانات وتكرار تخزين النسخ الاحتياطي. تعرف على المزيد في النسخ الاحتياطية Hyperscale وتكرار التخزين.

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

ينشئ هذا المثال قاعدة بيانات في طبقة الخدمة Hyperscale مع تكرار المنطقة:

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier Hyperscale \
    --backup-storage-redundancy Zone

لمزيد من المعلومات، راجع az sql db create وaz sql db update.

باستثناء قواعد بيانات الطبقة الأساسية وHyperscale، يمكنك تحديث إعداد التكرار لتخزين النسخ الاحتياطي لقاعدة بيانات موجودة باستخدام المعلمة --backup-storage-redundancy والأمر az sql db update. قد يستغرق تطبيق التغييرات على قاعدة البيانات ما يصل إلى 48 ساعة. يؤدي التبديل من تخزين النسخ الاحتياطي الجغرافي المكرر إلى التخزين المحلي أو التخزين الزائد في المنطقة إلى تعطيل الاستعادة الجغرافية.

يغير رمز المثال هذا التكرار لتخزين النسخ الاحتياطي إلى Local.

az sql db update \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --backup-storage-redundancy Local

لا يمكنك تحديث التكرار لتخزين النسخ الاحتياطي لقاعدة بيانات Hyperscale مباشرة. ومع ذلك، يمكنك تغييره باستخدام أمر نسخ قاعدة البيانات مع المعلمة --backup-storage-redundancy. ينسخ هذا المثال قاعدة بيانات Hyperscale إلى قاعدة بيانات جديدة باستخدام أجهزة Gen5 واثنين من vCores. قاعدة البيانات الجديدة تحتوي على النسخ الاحتياطي المعين على Zone.

az sql db copy \
    --resource-group myresourcegroup \ 
    --server myserver 
    --name myHSdb 
    --dest-resource-group mydestresourcegroup 
    --dest-server destdb 
    --dest-name myHSdb 
    --service-objective HS_Gen5_2 
    --read-replicas 0 
    --backup-storage-redundancy Zone

للحصول على تفاصيل بناء الجملة، راجع نسخة az sql db. للحصول على نظرة عامة عن نسخة قاعدة البيانات، تفضل بزيارة نسخ نسخة متسقة من قاعدة البيانات في Azure SQL Database.

قم بتكوين التكرار لتخزين النسخ الاحتياطي باستخدام PowerShell

لتكوين تكرار تخزين النسخ الاحتياطي عند إنشاء قاعدة بيانات جديدة، يمكنك تحديد المعامل -BackupStorageRedundancy باستخدام الأمر cmdlet New-AzSqlDatabase. القيم المحتملة هي Geo وZone وLocal. بشكل افتراضي، تستخدم جميع قواعد البيانات في Azure SQL Database تخزيناً متكرراً جغرافياً للنسخ الاحتياطية. يتم تعطيل الاستعادة الجغرافية إذا تم إنشاء قاعدة بيانات مع تخزين نسخ احتياطي محلي أو منطقة احتياطية.

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

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Local

ضع في اعتبارك بعناية خيار التكوين لـ--backup-storage-redundancy عند إنشاء قاعدة بيانات Hyperscale. لا يمكن تحديد التكرار في التخزين إلا أثناء عملية إنشاء قاعدة البيانات لقواعد بيانات Hyperscale. سيتم استخدام خيار التكرار التخزيني المحدد طوال عمر قاعدة البيانات لكل من تكرار تخزين البيانات وتكرار تخزين النسخ الاحتياطي. تعرف على المزيد في النسخ الاحتياطية Hyperscale وتكرار التخزين.

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

ينشئ هذا المثال قاعدة بيانات في طبقة الخدمة Hyperscale مع تكرار المنطقة:

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "Hyperscale" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Zone

للحصول على تفاصيل بناء الجملة، تفضل بزيارة New-AzSqlDatabase.

باستثناء قواعد بيانات الطبقة Hyperscale وBasic، يمكنك استخدام المعلمة -BackupStorageRedundancy مع الأمر Set-AzSqlDatabase لتحديث إعداد التكرار لتخزين النسخ الاحتياطي لقاعدة بيانات موجودة. القيم المحتملة هي قيم الموقع الجغرافي والمنطقة والقيمة المحلية. قد يستغرق تطبيق التغييرات على قاعدة البيانات ما يصل إلى 48 ساعة. يؤدي التبديل من تخزين النسخ الاحتياطي الجغرافي المكرر إلى التخزين المحلي أو التخزين الزائد في المنطقة إلى تعطيل الاستعادة الجغرافية.

يغير رمز المثال هذا التكرار لتخزين النسخ الاحتياطي إلى Local.

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Local

للحصول على مزيدٍ من التفاصيل، تفضل بزيارة Set-AzSqlDatabase

لا يمكن تحديث التكرار لتخزين النسخ الاحتياطي لقاعدة بيانات Hyperscale موجودة. ومع ذلك، يمكنك استخدام أمر نسخ قاعدة البيانات لإنشاء نسخة من قاعدة البيانات واستخدام المعلمة -BackupStorageRedundancy لتحديث التكرار في تخزين النسخ الاحتياطي. ينسخ هذا المثال قاعدة بيانات Hyperscale إلى قاعدة بيانات جديدة باستخدام أجهزة Gen5 واثنين من vCores. قاعدة البيانات الجديدة تحتوي على النسخ الاحتياطي المعين على Zone.

# Change the backup storage redundancy for Database01 to zone-redundant. 
New-AzSqlDatabaseCopy -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "HSSourceDB" -CopyResourceGroupName "DestResourceGroup" -CopyServerName "DestServer" -CopyDatabaseName "HSDestDB" -Vcore 2 -ComputeGeneration "Gen5" -ComputeModel Provisioned -BackupStorageRedundancy Zone

للحصول على تفاصيل بناء الجملة، تفضل بزيارة New-AzSqlDatabaseCopy.

للحصول على نظرة عامة عن نسخة قاعدة البيانات، تفضل بزيارة نسخ نسخة متسقة من قاعدة البيانات في Azure SQL Database.

ملاحظة

لاستخدام معلمة BackupStorageRedundancy مع استعادة قاعدة البيانات أو نسخ قاعدة البيانات أو إنشاء عمليات ثانوية، استخدم إصدار Azure PowerShell Az.Sql 2.11.0.

استخدم نهج Azure لفرض التكرار في تخزين النسخ الاحتياطي

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

نهج التكرار لتخزين النسخ الاحتياطي المضمنة

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

يجب أن تتجنب SQL Database استخدام التكرار الاحتياطي لـ GRS

يجب أن تتجنب SQL Managed Instance استخدام التكرار الاحتياطي لـ GRS

يمكن العثور على قائمة كاملة بتعريفات السياسة المضمنة لقاعدة بيانات SQL والمثيل المُدار هنا.

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

هام

لا يتم فرض نهج Azure عند إنشاء قاعدة بيانات عبر T-SQL. لفرض وجود البيانات عند إنشاء قاعدة بيانات باستخدام T-SQL، استخدم "محلي" أو "منطقة" كمدخل إلى معلمة BACKUP_STORAGE_REDUNDANCY في عبارة إنشاء قاعدة بيانات.

التعرف على كيفية تعيين النهج باستخدام مدخل Microsoft Azure أو Azure PowerShell

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