النسخ الاحتياطي والاستعادة في PostgreSQL: دليل عملي للفرق الإنتاجية

كل نشر لـ PostgreSQL يحتوي على نسخة احتياطية. لكن القليل منها فقط لديه عملية استعادة تم قياس زمنها.

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

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

قرّر الرقمين قبل اختيار أداة

هدف نقطة الاسترداد (RPO) هو مقدار البيانات التي يمكنك تحمّل خسارتها، ويُقاس بالزمن. خمس دقائق، ساعة واحدة، أو يوم واحد.

هدف زمن الاسترداد (RTO) هو المدة التي يمكن أن تبقى فيها الخدمة متوقفة أثناء استعادتها.

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

الفرق التي تتخطى هذه الخطوة تميل إلى شراء أداة أولاً واكتشاف المتطلب الحقيقي أثناء حادث.

النسخ الاحتياطي المنطقي: pg_dump و pg_dumpall

تصدّر pg_dump قاعدة بيانات واحدة إلى نص SQL أو أرشيف مضغوط. تقرأ من لقطة متسقة ولا تمنع الكتّاب، وتنتج أكثر مخرجات PostgreSQL قابلية للنقل: يمكن استعادة النتيجة إلى إصدار مختلف، أو بنية معمارية مختلفة، أو عنقود مختلف.

ما يتعامل معه بشكل جيد:

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

أين يتوقف عن كونه كافياً:

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

توسّع pg_dumpall هذا النطاق ليشمل كائنات مستوى العنقود مثل الأدوار ومساحات الأسماء، لكنها تكتب نص SQL عادي، مما يجعلها غير مناسبة للعناقيد الكبيرة.

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

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

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

الجزء المثير للاهتمام هو ما يحدث عند دمج النسخ الاحتياطي المادي مع أرشفة WAL المستمرة. كل تغيير مُلتزم يصل إلى سجل الكتابة المسبقة (write-ahead log)، وعندما تُرشَف تلك المقاطع إلى موقع منفصل، يمكنك استعادة النسخة الاحتياطية الأساسية وإعادة تشغيل السجل حتى طابع زمني محدد. هذا هو الاسترداد في نقطة زمنية محددة، ويُختصر عادةً إلى PITR.

يجيب PITR عن السؤال المهم في الحادث الحقيقي: هل يمكننا العودة إلى الساعة 14:32، قبل تشغيل ذلك السكربت مباشرة؟

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

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

طبقة الأدوات: pgBackRest و WAL-G و pg_probackup

تشغيل النسخ الاحتياطي الأساسي، وأرشفة WAL، والاحتفاظ، والضغط، وأهداف التخزين يدوياً لا يتوسع، لذا تستخدم معظم الفرق الإنتاجية أداة مخصصة. الأدوات الثلاث للنسخ الاحتياطي المدعومة من أتمتة النشر لدى Worlber هي pgBackRest و WAL-G و pg_probackup.

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

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

أين تعيش النسخ

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

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

التوجيه طويل الأمد المتمثل في ثلاث نسخ، على نوعين من الوسائط، مع نسخة واحدة خارج الموقع، لا يزال صالحاً. ما تغيّر هو مدى رخص تكلفة النسخة خارج الموقع.

التشفير، المفاتيح، وبيانات غير الإنتاج

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

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

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

الخطوة التي تتخطاها معظم الفرق

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

يجب أن تجيب محاكاة الاستعادة على خمسة أسئلة، ويجب توقيتها:

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

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

أنماط فشل تستحق الفحص هذا الأسبوع

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

ما تفعله Worlber بهذا الشأن

Worlber شركة استشارات قواعد بيانات مقرها الرياض، تعمل عبر ممتلكات PostgreSQL وSQL Server. عادةً ما تصل النسخ الاحتياطية كجزء من محادثة أوسع حول التوفر والأمان والتكلفة.

عمليًا، تغطي تلك الأعمال:

تصميم ومراجعة استراتيجية النسخ الاحتياطي والاستعادة، بما في ذلك أهداف RPO وRTO التي وافقت عليها الأعمال فعليًا.
بنية العناقيد للتوفر العالي على Patroni مع تحويل تلقائي، بحيث يتم تصميم التوفر والنسخ الاحتياطي معًا بدلاً من إضافتهما بشكل منفصل.
تنفيذ pgBackRest أو WAL-G أو pg_probackup للنسخ الاحتياطي المادي وأرشفة WAL، مع تهيئة فترة الاحتفاظ والتخزين خارج الموقع.
ميزات الأمان في PGEE حيث تتطلبها الأحمال الخاضعة للتنظيم، بما في ذلك تشفير البيانات الشفاف والنسخ المُخفَية للاستعادة في البيئات غير الإنتاجية.
الرعاية بعد الإطلاق بمجرد تشغيل النظام: ضبط الأداء وحل المشكلات.
دعم يتضمن دعم الاستعادة الطارئ، على مستويات تتراوح من التغطية خلال ساعات العمل حتى 24x7، مع اتفاقيات مستوى خدمة لأوقات الاستجابة تختلف حسب المستوى.

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

النسخة المختصرة

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

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

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