"أوه ، لا يوجد مأوى يمكنه تحمل تأثير النيزك. لكنك ، مثل الجميع ، لديك احتياطي ، لذلك لا تقلق.
ستانيسلاف ليم ، "The Star Diaries of Iyon the Tikhiy"
يشير النسخ الاحتياطي إلى الاحتفاظ بنسخة من بياناتك في مكان ما خارج موقع التخزين الأساسي.
الغرض الرئيسي من النسخ الاحتياطي هو استعادة البيانات بعد فقدها. في هذا الصدد ، نسمع غالبًا أنه إذا كان لديك نسخة طبق الأصل من قاعدة البيانات ، فيمكنك دائمًا استعادة البيانات منها ، ولا تحتاج إلى نسخة احتياطية. في الواقع ، يسمح لك النسخ الاحتياطي بحل ثلاث مهام على الأقل لا يمكن حلها باستخدام نسخة متماثلة ، ولا يمكن تهيئة نسخة متماثلة بدون نسخة احتياطية.
أولاً ، تسمح لك النسخة الاحتياطية باستعادة البيانات بعد حدوث خطأ منطقي. على سبيل المثال ، قام محاسب بحذف مجموعة من المعاملات ، أو قام مسؤول قواعد البيانات بتدمير مساحة جدول. كلتا العمليتين شرعيتان تمامًا من وجهة نظر قاعدة البيانات ، وستقوم عملية النسخ المتماثل بإعادة إنتاجهما في قاعدة بيانات النسخة المتماثلة.
ثانيًا ، تعد نظم إدارة قواعد البيانات الحديثة أنظمة برمجية موثوقة للغاية ، ولكن في بعض الأحيان يحدث تلف للبنى الداخلية لقاعدة البيانات ، وبعد ذلك يتم فقدان الوصول إلى البيانات. ما هو مسيء بشكل خاص ، يحدث مثل هذا الانتهاك عادةً عند التحميل العالي أو عند تثبيت نوع من التحديث. لكن كل من التحميل العالي والتحديثات المنتظمة تشير إلى أن قاعدة البيانات ليست قاعدة بيانات اختبار ، والبيانات المخزنة فيها ذات قيمة.
أخيرًا ، المهمة الثالثة ، التي يتطلب حلها نسخة احتياطية ، هي استنساخ قاعدة البيانات ، على سبيل المثال ، لأغراض الاختبار.
يعتمد النسخ الاحتياطي لقاعدة البيانات بطريقة ما على أحد مبدأين:
- جلب البيانات مع الحفظ اللاحق بتنسيق تعسفي ؛
- لقطة من ملفات قاعدة البيانات وسجلات الحفظ.
دعونا نلقي نظرة فاحصة على هذه المبادئ والأدوات التي تنفذها.
رفع البيانات
يجب أن تحتوي مجموعة الأدوات المساعدة التي تأتي مع أي نظام DBMS على أدوات لتحميل البيانات وتنزيلها. يتم تخزين البيانات إما بتنسيق نصي أو بتنسيق ثنائي خاص بنظام DBMS معين. يسرد الجدول أدناه هذه الأدوات:
| تنسيق ثنائي | تنسيق النص
|
|
|---|---|---|
| وحي | DataPump تصدير / استيراد DataPump
تصدير / استيراد |
SQL * Plus / SQL * Loader |
| PostgreSQL | pg_dump ، pg_dumpall / pg_restore | pg_dump ، pg_dumpall / psql |
| خادم مايكروسوفت SQL | bcp | bcp |
| DB2 | تفريغ / تحميل | تفريغ / تحميل |
| MySQL | mysqldump ، mysqlpump / mysql ، mysqlimport | |
| MongoDB | mongodump / mongorestore | mongoexport / mongoimport |
| كاساندرا | لقطة nodetool / sstableloader | cqlsh |
يعد تنسيق النص جيدًا لأنه يمكن تحريره أو حتى إنشاؤه بواسطة برامج خارجية ، كما أن التنسيق الثنائي ، بدوره ، جيد لأنه يتيح لك تفريغ وتحميل البيانات بسرعة بسبب التحميل المتوازي وتوفير الموارد عند تحويل التنسيق.
على الرغم من بساطة ووضوح فكرة تنزيل البيانات ، نادرًا ما تستخدم هذه الطريقة لعمل نسخة احتياطية من القواعد الصناعية المحملة. فيما يلي الأسباب التي تجعل إلغاء التحميل غير مناسب للنسخ الاحتياطي الكامل:
- تخلق عملية التفريغ عبئًا كبيرًا على نظام المصدر ؛
- يستغرق التفريغ الكثير من الوقت - بحلول الوقت الذي ينتهي فيه التفريغ ، سيصبح غير ذي صلة ؛
- يكاد يكون من المستحيل إجراء تفريغ متسق لقاعدة البيانات بأكملها تحت حمولة عالية ، حيث يضطر نظام إدارة قواعد البيانات (DBMS) للاحتفاظ بلقطة لحالتها في وقت بدء التفريغ. كلما زاد عدد المعاملات التي تم الالتزام بها منذ بداية التحميل ، زاد حجم اللقطات (نسخ غير ذات صلة من البيانات في PostgreSQL ، أو مساحة التراجع في Oracle ، أو tempdb في Microsoft SQL Server ، وما إلى ذلك) ؛
- يحافظ التفريغ على البنية المنطقية للبيانات ، لكنه لا يحافظ على هيكلها المادي - معلمات التخزين المادي للجداول ، والفهارس ، وما إلى ذلك ؛ يمكن أن تستغرق إعادة إنشاء الفهارس في وقت التمهيد وقتًا طويلاً.
ومع ذلك ، فإن التفريغ له مزايا:
- انتقائية عالية: يمكنك تفريغ الجداول الفردية والحقول الفردية وحتى الصفوف الفردية ؛
- يمكن تحميل البيانات التي تم تحميلها في قاعدة بيانات من إصدار آخر ، وإذا تم التحميل بتنسيق نصي ، فعندئذٍ في قاعدة بيانات أخرى.
وبالتالي ، يتم استخدام التفريغ بشكل أساسي في مهام مثل النسخ الاحتياطي للجداول الصغيرة (على سبيل المثال ، الدلائل) أو توزيع مجموعات البيانات مع الإصدار التالي من التطبيق.
الطريقة الأكثر شيوعًا لنسخ قواعد البيانات احتياطيًا هي نسخ ملفات قاعدة البيانات.
حفظ "بارد" لملفات قاعدة البيانات
الفكرة الواضحة هي إيقاف قاعدة البيانات ونسخ جميع ملفاتها. هذا يسمى النسخ الاحتياطي البارد. الطريقة موثوقة وبسيطة للغاية ، ولكن لها عيبان واضحان:
- من نسخة احتياطية باردة ، يمكنك فقط استعادة حالة قاعدة البيانات التي كانت وقت إيقاف التشغيل ؛ لن يتم تضمين المعاملات التي تتم بعد إعادة تشغيل قاعدة البيانات في النسخة الاحتياطية "الباردة" ؛
- لا تحتوي كل قاعدة بيانات على نافذة تكنولوجية عندما يمكن إيقاف قاعدة البيانات.
إذا كنت سعيدًا بالنسخ الاحتياطية الباردة ، فتذكر ذلك
- «» . , «» , . , Oracle online redo, , , . PostgreSQL , , .
- , . , «» .
«»
يتم إجراء معظم النسخ الاحتياطية الحديثة لقاعدة البيانات عن طريق نسخ ملفات قاعدة البيانات دون إيقاف قاعدة البيانات. تظهر العديد من المشاكل هنا:
- في بداية النسخ ، قد لا تتطابق محتويات قاعدة البيانات مع محتويات الملفات ، لأن بعض المعلومات موجودة في ذاكرة التخزين المؤقت ولم تتم كتابتها على القرص بعد.
- أثناء النسخ ، قد تتغير محتويات قاعدة البيانات. إذا تم استخدام هياكل البيانات القابلة للتغيير ، تتغير محتويات الملفات ، وعند استخدام الهياكل الثابتة ، تتغير مجموعة الملفات: تظهر الملفات الجديدة ، ويتم حذف الملفات القديمة.
- نظرًا لأن كتابة البيانات إلى قاعدة البيانات وقراءة ملفات قاعدة البيانات غير متزامنتين بأي شكل من الأشكال ، فقد يقرأ برنامج النسخ الاحتياطي صفحة غير صحيحة ، سيكون نصفها من الإصدار القديم للصفحة والنصف الآخر من الإصدار الجديد.
من أجل أن تكون النسخة الاحتياطية متسقة ، يحتوي كل DBMS على أمر يبلغ أن عملية النسخ الاحتياطي قد بدأت. من الناحية التركيبية ، قد يبدو هذا الأمر مختلفًا:
- في Oracle هو أمر منفصل ALTER DATABASE / TABLESPACE BEGIN BACKUP ؛
- في PostgreSQL ، الدالة pg_start_backup () ؛
- في Microsoft SQL Server و DB2 ، التحضير للنسخة الاحتياطية ضمني أثناء الأمر BACKUP DATABASE؛
- في MySQL Enterprise و Percoba Server و Cassandra و MongoDB ، يتم تنفيذ الإعداد ضمنيًا بواسطة أداة مساعدة خارجية - mysqlbackup و Percona XtraBackup و OpsCenter و Ops Manager على التوالي.
على الرغم من الاختلافات النحوية ، تبدو عملية التحضير للنسخة الاحتياطية كما هي.
هذه هي الطريقة التي يبدو بها التحضير للنسخ الاحتياطي في نظام DBMS بهياكل قرص متغيرة ، أي في جميع أنظمة ارتباط القرص التقليدية:
- تذكر لحظة بدء النسخ الاحتياطي ؛ يجب أن تحتوي النسخة الاحتياطية على سجلات قاعدة البيانات من الآن فصاعدًا.
- يتم تنفيذ نقطة فحص ، أي أن جميع التغييرات التي حدثت في صفحات البيانات حتى النقطة الزمنية يتم مسحها على القرص. يضمن ذلك عدم الحاجة إلى سجلات قبل بدء النسخ الاحتياطي أثناء الاسترداد.
- : , , , . , . , . , , .
- , , . , , .
بعد اكتمال جميع الإجراءات المذكورة أعلاه ، يمكنك نسخ ملفات البيانات باستخدام أدوات نظام التشغيل - cp و rsync وغيرها. يؤدي تمكين وضع النسخ الاحتياطي إلى تقليل أداء قاعدة البيانات: أولاً ، يزداد حجم السجلات ، وثانيًا ، إذا حدث فشل مفاجئ في وضع النسخ الاحتياطي ، سيستغرق الاسترداد وقتًا أطول ، نظرًا لعدم تحديث رؤوس ملفات البيانات. كلما اكتملت عملية النسخ الاحتياطي بشكل أسرع ، كان ذلك أفضل لقاعدة البيانات ، لذلك من المناسب استخدام أدوات مثل لقطة لنظام الملفات أو فاصل متطابق (BCV) في مجموعة أقراص. تترك بعض نظم إدارة قواعد البيانات (Oracle ، PostgreSQL) للمسؤول الفرصة لاختيار طريقة النسخ بشكل مستقل ،يوفر الآخرون (Microsoft SQL Server) واجهة لدمج أدوات النسخ الاحتياطي الأصلية مع نظام الملفات أو محركات التخزين.
عند اكتمال النسخ الاحتياطي ، تحتاج إلى إعادة قاعدة البيانات إلى حالتها الطبيعية. في Oracle ، يتم ذلك باستخدام الأمر ALTER DATABASE / TABLESPACE END BACKUP ، في PostgreSQL ، عن طريق استدعاء دالة pg_stop_backup () ، وفي قواعد البيانات الأخرى ، عن طريق الإجراءات الداخلية للأوامر المقابلة أو الخدمات الخارجية.
إليك ما يبدو عليه الجدول الزمني لعملية النسخ الاحتياطي:
- يستغرق التحضير للنسخ الاحتياطي (بدء النسخ الاحتياطي) وقتًا ، وأحيانًا يستغرق وقتًا طويلاً. حتى إذا تم استخدام وحدات تخزين معكوسة أو أنظمة ملفات لقطة ، فلن تكون عملية النسخ الاحتياطي فورية.
- جنبًا إلى جنب مع ملفات البيانات ، من الضروري حفظ السجلات من لحظة بدء التحضير للنسخ الاحتياطي والانتهاء من لحظة عودة قاعدة البيانات إلى حالتها الطبيعية.
- يمكنك الاسترداد من هذه النسخة الاحتياطية في الوقت الذي تعود فيه قاعدة البيانات إلى حالتها الطبيعية . التعافي إلى لحظة سابقة غير ممكن.
مع قواعد البيانات التي تستخدم هياكل البيانات غير القابلة للتغيير (لقطات ، أشجار LSM) ، يكون الوضع أسهل. يتكون التحضير للنسخ الاحتياطي من الخطوات التالية:
- يتم مسح البيانات من الذاكرة إلى القرص.
- يتم تسجيل قائمة الملفات المضمنة في النسخة الاحتياطية. حتى تنتهي عملية النسخ الاحتياطي ، يُحظر على قاعدة البيانات حذف هذه الملفات ، حتى لو لم تعد هناك حاجة إليها.
عند إصدار إشارة حول نهاية النسخة الاحتياطية ، يمكن لقاعدة البيانات ذات الهياكل الثابتة حذف الملفات غير الضرورية مرة أخرى.
استعادة النقطة
يسمح لك النسخ الاحتياطي باستعادة حالة قاعدة البيانات إلى اللحظة التي اكتمل فيها أمر العودة من وضع النسخ الاحتياطي. ومع ذلك ، يمكن أن تحدث كارثة تتطلب الاسترداد في أي وقت. تسمى مهمة استعادة حالة قاعدة البيانات إلى لحظة عشوائية "استرداد نقطة في الوقت".
لتحقيق ذلك ، يجب عليك حفظ سجلات قاعدة البيانات من وقت انتهاء النسخ الاحتياطي والاستمرار في تطبيق السجلات على النسخة المستعادة أثناء عملية الاستعادة. بعد استعادة قاعدة البيانات من النسخة الاحتياطية في نهاية النسخة ، يتم ضمان صحة حالة قاعدة البيانات (الملفات والصفحات المخبأة) ، لذا لا يلزم وضع تسجيل خاص. من خلال تطبيق السجلات حتى اللحظة المطلوبة ، يمكنك الحصول على حالة قاعدة البيانات في أي وقت.
إذا كانت سرعة استعادة النسخة الاحتياطية محدودة فقط من خلال عرض النطاق الترددي للقرص ، فإن سرعة تطبيق السجلات عادة ما تكون محدودة بأداء المعالج. إذا حدثت تغييرات في قاعدة البيانات الرئيسية بالتوازي ، فعندئذٍ أثناء الاسترداد ، يتم تنفيذ جميع التغييرات بالتتابع - بالترتيب الذي تمت قراءته به من السجل. لذلك ، يعتمد وقت الاسترداد خطيًا على مدى بُعد نقطة الاسترداد عن نقطة نهاية النسخة الاحتياطية. لهذا السبب ، يتعين عليك عمل نسخ احتياطية كاملة في كثير من الأحيان - مرة واحدة على الأقل في الأسبوع لقواعد البيانات ذات الحمل المنخفض للمعاملات وقبل النسخ اليومي لقواعد البيانات المحملة بشكل كبير.
نسخ احتياطي تزايدي
لتسريع الاسترداد من نقطة إلى نقطة ، أود أن أكون قادرًا على إجراء النسخ الاحتياطي قدر الإمكان ، ولكن في نفس الوقت لا تشغل مساحة إضافية على القرص ولا تثقل كاهل قاعدة البيانات بمهام النسخ الاحتياطي.
حل المشكلة هو نسخ احتياطي تزايدي ، أي نسخ صفحات البيانات التي تغيرت منذ النسخ الاحتياطي السابق.
النسخ الاحتياطية المتزايدة تكون منطقية فقط لنظم إدارة قواعد البيانات التي تستخدم هياكل بيانات قابلة للتغيير.
يمكن حساب الزيادة من كل من النسخة الاحتياطية الكاملة (نسخة تراكمية) ومن أي نسخة سابقة (نسخة تفاضلية).
لسوء الحظ ، لا توجد مصطلحات موحدة ، وتستخدم جهات تصنيع مختلفة مصطلحات مختلفة:
| التفاضليه | تراكمي
|
|
|---|---|---|
| وحي | التفاضليه | تراكمي |
| PostgresPro | تدريجي | - |
| خادم مايكروسوفت SQL | - | التفاضليه |
| IBM DB2 | دلتا | تدريجي |
| مشروع MySQL | تدريجي | التفاضليه |
| خادم بيركونا | تدريجي | |
مع النسخ الاحتياطية المتزايدة ، تبدو عملية الاستعادة من نقطة إلى نقطة كما يلي:
- آخر نسخة احتياطية كاملة تم إجراؤها قبل استعادة الاستعادة ؛
- تتم استعادة النسخ المتزايدة على النسخة الكاملة ؛
- لفات السجلات من النقطة التي بدأت عندها النسخ الاحتياطي إلى نقطة الاسترداد.
يؤدي الحصول على نسخة تراكمية إلى تسريع عملية الاسترداد. لذلك ، على سبيل المثال ، لاستعادة الحالة الأساسية إلى نقطة بين T3 و T4 ، من الضروري استعادة نسختين تزايديتين ، والاستعادة إلى نقطة بعد T4 - واحدة فقط.
من الواضح أن حجم نسخة تراكمية واحدة أقل من حجم عدة نسخ تفاضلية ، لأن بعض الصفحات قد تغيرت عدة مرات ، وتحتوي كل نسخة إضافية على نسختها الخاصة من الصفحة.
توجد ثلاث طرق لإنشاء نسخة تزايديّة:
- إنشاء نسخة كاملة وحساب الفرق عن النسخة الكاملة السابقة ؛
- تحليل السجلات وإنشاء قائمة بالصفحات التي تم تغييرها والنسخ الاحتياطي للصفحات المدرجة في القائمة ؛
- طلب تغيير الصفحات في قاعدة البيانات.
الطريقة الأولى توفر مساحة القرص ، لكنها لا تحل مشكلة تقليل الحمل على قاعدة البيانات. علاوة على ذلك ، إذا كان لدينا نسخة احتياطية كاملة ، فإن تحويلها إلى نسخة احتياطية تزايدي لا طائل من ورائه ، لأن استعادة نسخة احتياطية كاملة أسرع من استعادة نسخة كاملة سابقة وزيادة. باستخدام هذا الأسلوب ، من الأفضل تحويل مهمة توفير مساحة القرص إلى مكونات خاصة باستخدام آليات إلغاء البيانات المكررة المضمنة. يمكن أن تكون هذه إما أنظمة تخزين خاصة (EMC DataDomain أو HPE StorageWorks VLS أو خط NetApp بأكمله) أو منتجات برمجية (ZFS أو Veritas NetBackup PureFile أو Windows Server Data Deduplication).
تختلف الطريقة الثانية والثالثة في آلية تحديد قائمة الصفحات التي تم تغييرها. يعد تحليل السجلات أكثر كثافة في استخدام الموارد ، بالإضافة إلى أنك تحتاج إلى معرفة بنية ملفات السجل لتنفيذه. من الأسهل أن تسأل قاعدة البيانات نفسها عن الصفحات التي تغيرت ، ولكن لهذا يجب أن تتمتع نواة DBMS بوظيفة تتبع الكتل التي تم تغييرها (كتلة تتبع التغيير).
تم تقديم وظيفة النسخ الاحتياطي المتزايد لأول مرة مع برنامج Oracle Recovery Manager (RMAN) ، والذي تم تقديمه مع إصدار Oracle 8i. نفذت Oracle على الفور تتبع الكتلة المتغيرة ، لذلك ليست هناك حاجة لتحليل السجلات.
لا تتعقب PostgreSQL الكتل المتغيرة ، لذا فإن الأداة المساعدة pg_probackup ، التي طورتها شركة Postgres Professional الروسية ، تكتشف الصفحات التي تم تغييرها من خلال تحليل السجل. ومع ذلك ، توفر الشركة أيضًا PostgresPro ، والذي يتضمن امتدادًا لملفات المسار الذي يتتبع تغييرات الصفحة. عند استخدام pg_probackup مع PostgresPro ، تستعلم الأداة المساعدة عن قاعدة البيانات نفسها للصفحات المعدلة ، تمامًا كما يفعل RMAN.
يقوم Microsoft SQL Server ، مثل Oracle ، بتتبع الصفحات التي تم تغييرها ، لكن الأمر BACKUP يسمح فقط بالنسخ الاحتياطية الكاملة والتراكمية.
DB2 لديه القدرة على تتبع الصفحات التي تم تغييرها ، ولكن يتم تعطيله افتراضيًا. بمجرد التمكين ، سيسمح DB2 بالنسخ الاحتياطي الكامل والتفاضلي والتراكمي.
يتمثل أحد الاختلافات المهمة بين الأدوات الموضحة في هذا القسم (باستثناء pg_probackup) وأدوات النسخ الاحتياطي المستندة إلى الملفات في أنها تستفسر عن قاعدة البيانات عن صور الصفحة بدلاً من قراءة البيانات من القرص بأنفسهم. عيب هذا النهج هو الحمل الإضافي الصغير على القاعدة. ومع ذلك ، يتم تعويض هذا العيب أكثر من حقيقة أن قراءة الصفحة صحيحة دائمًا ، لذلك ليست هناك حاجة لتمكين وضع دفتر يومية خاص أثناء النسخ الاحتياطي.
لاحظ مرة أخرى أن وجود نُسخ احتياطية تزايدي لا يحل محل متطلبات استعادة السجلات إلى نقطة زمنية عشوائية. لذلك ، في قواعد البيانات الصناعية ، تتم إعادة كتابة السجلات باستمرار إلى وسائط خارجية ، ويتم إنشاء نسخ احتياطية كاملة و / أو تدريجية وفقًا لجدول زمني.
أفضل تطبيق لفكرة النسخ الاحتياطي التزايدي اليوم هو Zero Data Loss Recovery Appliance (في مصطلحات Oracle - النظام الهندسي) - وهو حل Oracle متخصص لعمل نسخة احتياطية من قاعدة البيانات الخاصة به. المجمع عبارة عن مجموعة من الخوادم ذات حجم كبير من الأقراص ، والتي تم تثبيت نسخة معدلة من برنامج Recovery Manager عليها ويمكن أن تعمل مع كل من مجمعات برامج وأجهزة Oracle الأخرى (Database Appliance و Exadata و SPARC Supercluster) ومع قواعد بيانات Oracle على البنية التحتية التقليدية. على عكس RMAN "العادي" ، تطبق ZDLRA مفهوم "التدريجي إلى الأبد". يقوم النظام بإنشاء نسخة كاملة من قاعدة البيانات مرة واحدة فقط ، ثم يقوم بعمل نسخ تدريجية فقط. تسمح لك وحدات RMAN النمطية الإضافية بدمج النسخ ،إنشاء نسخ كاملة جديدة من النسخ الإضافية.
لحساب المطورين الروس ، تجدر الإشارة إلى أن pg_probackup قادر أيضًا على الجمع بين النسخ المتزايدة.
على عكس العديد من الأسئلة المماثلة ، فإن السؤال "ما هي طريقة النسخ الاحتياطي الأفضل" له إجابة لا لبس فيها - الأفضل هو الأداة المساعدة الأصلية لنظام إدارة قواعد البيانات المستخدم التي توفر القدرة على النسخ الاحتياطية المتزايدة.
بالنسبة لـ DBA ، تعد قضايا اختيار استراتيجية النسخ الاحتياطي ودمج النسخ الاحتياطية لقاعدة البيانات في البنية التحتية للشركة أكثر أهمية. لكن هذه الأسئلة خارج نطاق هذا المقال.