استعادة PostgreSQL: أثبت التعافي باختبارات Restore فعلية

تكون نسخة PostgreSQL الاحتياطية مفيدة فقط عندما يستطيع الفريق استعادة البيانات الصحيحة خلال وقت متفق عليه. تجمع Point-in-Time Recovery أو PITR بين Base Backup فيزيائية وسلسلة متصلة من ملفات Write-Ahead Log أو WAL، ثم تعيد PostgreSQL تشغيل التغييرات وتتوقف عند Recovery Target محدد. الهدف العملي ليس ظهور Backup Job باللون الأخضر، بل وجود دليل أن Base Backup المتاحة وسلسلة WAL تحققان Recovery Point Objective أو RPO وRecovery Time Objective أو RTO.

تعامل مع التعافي في الإنتاج كخدمة محددة الإصدار: عرّف Cluster المحمية ونافذة الاحتفاظ ومقدار فقد البيانات المقبول وموعد استعادة الخدمة والاعتمادات ومواقع التخزين واستعلامات التحقق والمالك. نفّذ الإجراء دوريًا داخل بيئة معزولة. Restore لم يكتمل من قبل يبقى افتراضًا حتى لو كان لكل ملف Checksum صحيح.

يشرح توثيق PostgreSQL الرسمي الآلية الأساسية: استعد Base Backup على مستوى الملفات، ثم أعد تشغيل WAL المؤرشفة. تبقى Logical Dumps مثل `pg_dump` مفيدة للنقل والاستعادة الانتقائية، لكنها ليست Base Backup يمكن استخدام WAL Replay فوقها. اختر الأداة حسب نوع الحادث الذي تريد النجاة منه.

ابدأ بعقد تعافٍ واضح

يجيب RPO عن مقدار البيانات المثبتة التي يستطيع العمل خسارتها، ويجيب RTO عن مدة توقف الخدمة أو عملها بصورة محدودة. هذان قراران للمنتج والتشغيل، وليسا رقمين تخترعهما أداة Backup. قد يحتاج Payment Ledger إلى RPO أصغر من قاعدة Analytics مشتقة، ويمكن أحيانًا إعادة بناء Catalog من System of Record آخر.

حوّل الأهداف إلى إشارات قابلة للقياس. للـRPO، سجّل Timestamp أو LSN لآخر WAL Segment محفوظة بصورة دائمة خارج Failure Domain الأساسية، ثم قارنها بموضع WAL الحالي. ولـRTO، قِس زمن اكتشاف الحادث والموافقة وإنشاء البنية وتنزيل النسخة والاستعادة وWAL Replay والتحقق وتحويل Traffic كلًا على حدة. قد يكون نقل البيانات أو Replay أبطأ من أمر تشغيل PostgreSQL نفسه.

حدد نطاق التعافي أيضًا. تستعيد PITR كامل PostgreSQL Cluster لا جدولًا واحدًا. إذا كان الحادث تحديثًا خاطئًا لعميل واحد، فقد يكون استرجاع Cluster داخل بيئة معزولة ثم تصدير الصفوف الصحيحة أكثر أمانًا من استبدال Production. يجب أن يحدد العقد من يختار Recovery Target ومن يعتمد Promotion وما الدليل المطلوب قبل نقل Traffic.

ابنِ سلسلة تعافٍ مكتملة

تتكون سلسلة PITR من أربعة أجزاء لا تنفصل: Base Backup صالحة، وكل WAL Segments المطلوبة بعدها، وإعدادات وأسرار الوصول إليها، وPostgreSQL Runtime متوافق. فقد Segment واحدة قد يجعل كل التاريخ التالي غير قابل للوصول. Base Backup أحدث تقصر Replay، لكنها لا تصلح سلسلة Archive مكسورة لهدف أقدم.

تحتاج PostgreSQL إلى `wal_level=replica` أو أعلى و`archive_mode=on` للأرشفة المستمرة. يجب أن يعيد Archive Command أو Library النجاح فقط بعد تخزين Segment بصورة دائمة، وأن يرفض الكتابة فوق ملف مختلف له الاسم نفسه. راقب `pg_stat_archiver` وعمر آخر Archive ناجحة ومحاولات الفشل وأخطاء التخزين ونمو `pg_wal`. يحذر التوثيق الرسمي من أن فشل الأرشفة المتكرر يملأ `pg_wal` حتى قد يوقف ضغط القرص قاعدة البيانات.

ضع Repository خارج Failure Domain الخاصة بالقاعدة الأساسية. افصل Write Credentials التي يستخدمها Archiver عن صلاحيات الحذف والاحتفاظ، وشفّر النقل والتخزين، وسجّل الوصول، واختبر القراءة بالهوية المستخدمة في Restore. وجود Object لا يثبت إمكانية قراءته بعد تدوير Credential أو Encryption Key أو Storage Policy.

اختر دورة النسخ وفق زمن Replay

توازن وتيرة Base Backup بين التخزين وحمل النسخ وزمن التعافي. يجب إعادة تشغيل WAL بعد Base Backup المختارة، لذلك قد تحقق نسخة قديمة مدة الاحتفاظ لكنها تفشل RTO. قِس سرعة Restore وReplay ببيانات تشبه الإنتاج، ثم اختر دورة فيها هامش ليوم أبطأ أو ازدحام شبكة أو وقت التحقق.

تدعم PostgreSQL 18 نسخًا فيزيائية Incremental عبر `pg_basebackup --incremental`، لكن Restore تحتاج النسخ السابقة في السلسلة و`pg_combinebackup`. ينبه دليل PITR الرسمي إلى أن PostgreSQL لا يدير Retention Dependencies نيابة عنك. لا تحذف Full Backup ما دامت Incremental Backups محفوظة تعتمد عليها. للـClusters الصغيرة قد تبقى Full Backups أبسط وأقل مخاطرة من سلسلة Incremental عميقة.

يجب أن تغطي Retention Window زمن اكتشاف الحادث لا وقت حدوثه فقط. إذا اكتُشف التلف بعد خمسة أيام بينما الاحتفاظ ثلاثة أيام، فلن تنفع دقة الأداة. احتفظ بأكثر من Backup Generation مستقلة، وتأكد أن سياسة الحذف لا تزيل آخر سلسلة قابلة للاستعادة بعد فشل Run واحدة.

راقب النسخ والأرشفة كمنتج تشغيلي

يجب أن ينتج Backup Pipeline حقائق يستطيع Alert تقييمها: وقت البداية والنهاية والنوع والحجم وSystem Identifier وStart/Stop LSN وأول وآخر WAL مطلوبة وRepository ونتيجة Checksum وعلاقة Expiration. لا تنبه فقط على Exit Code الخاص بالجدولة. أنشئ تنبيهًا عند غياب Backup حديثة صالحة أو تجاوز Archive Lag ميزانية RPO أو اقتراب السعة من حدها أو نقص WAL المطلوبة للنسخة الحالية.

يعرض دليل pgBackRest الرسمي معلومات Repository وWAL Archive بصيغة JSON، ومنها آخر Backup ناجحة وآخر WAL مؤرشفة. يفيد ذلك في المراقبة، لكن يجب مقارنة Freshness مع حالة القاعدة وهدف العمل. لوحة تعرض وقت النسخة بلا WAL Boundary قد تخفي سلسلة تعافٍ مكسورة.

# فحوص توضيحية؛ عدّل stanza والمسارات وحدود التنبيه.
sudo -u postgres pgbackrest --stanza=app --output=json info
sudo -u postgres pgbackrest --stanza=app check

# تحقق من pg_basebackup عادية مقابل manifest.
pg_verifybackup --progress /restore/base

تقارن `pg_verifybackup` الملفات والـChecksums مع Backup Manifest، ويمكنها تحليل WAL المطلوبة للنسخ ذات Plain Format. لكن توثيق PostgreSQL نفسه يوضح أنها لا تستبدل Test Restore؛ لا تستطيع إعادة كل فحوص الخادم العامل أو إثبات صحة بيانات التطبيق بعد الاستعادة. استخدمها كبوابة ضمن المسار، لا تعريفًا نهائيًا لقابلية التعافي.

نفّذ Restore Drill كأنه Deployment

أنشئ شبكة معزولة وتخزينًا جديدًا. ثبّت PostgreSQL Major Version والـExtensions المتوقعة. نزّل Base Backup محددة وسجّل هويتها. اضبط `restore_command` وأنشئ `recovery.signal`، واختر Recovery Target بالوقت أو Named Restore Point أو هدف مدعوم آخر. امنع Traffic العادية حتى ينتهي التحقق.

استعد أولًا إلى وقت يسبق Marker Transaction معروفة، ثم إلى ما بعدها. بذلك تختبر Target Selection بدل Replay إلى أحدث WAL فقط. سجّل متى بدأ Drill، ومتى بدأ الخادم Recovery، ومتى وصل Replay إلى الهدف، ومتى انتهى Validation، ومتى كان يمكن تنفيذ Cutover افتراضي. قارن RPO وRTO المقاسين بالعقد.

لا تنفذ Promotion تلقائيًا لأن PostgreSQL اشتغلت. قد تكون Recovery ناجحة تقنيًا لكنها اختارت Target خاطئًا، أو فقدت Extension، أو أشارت إلى Tablespace غير متاحة، أو احتوت بيانات تخالف توقعات التطبيق. احتفظ بالـLogs وهويات Backup وWAL المختارة حتى يستطيع مشغّل آخر إعادة النتيجة. لا تدمر البيئة قبل تخزين الدليل.

تحقّق من التخزين حتى سلوك المنتج

استخدم طبقات تحقق. ابدأ بـBackup Manifest وملكية الملفات وصلاحياتها وTablespaces وتشغيل PostgreSQL. ثم راجع Recovery Logs وTimeline وآخر Replay Position وTarget Action. شغّل `amcheck` أو فحوص سلامة مناسبة ضمن ميزانية أداء مفهومة. تحقق من Extensions وRoles والإعدادات المطلوبة بصورة منفصلة لأن WAL Archiving لا تحفظ كل ملفات الإعداد الخارجية.

بعد ذلك اختبر Business Invariants: عينات طلبات مهمة ومجاميع Ledger وعزل العملاء وآخر Event مقبول وBackground-job Checkpoints. شغّل Read-only Smoke Tests عبر الاستعلامات التي يستخدمها المنتج نفسه. إذا كان الحادث معروفًا، تأكد أن Transaction الضارة غير موجودة بينما المعاملات الصحيحة السابقة موجودة. Row Count وحده لا يثبت أنك استعدت الحالة الصحيحة.

اجعل Validation حتمية ومحددة الإصدار بجانب التطبيق. عندما يتغير Schema حدّث Restore Assertions في الإصدار نفسه. يجب أن يفشل Drill بصورة مغلقة: Extension مجهولة أو Secret مفقود أو Recovery Target غامض تحتاج تحقيقًا، لا Promotion تلقائيًا إلى الإنتاج.

افصل Backup Recovery عن High Availability

تحل Replica وBackup أعطالًا مختلفة. قد تقلل Streaming Replication زمن Failover عند فقد Host، لكنها تستطيع نسخ Delete خاطئة أو كتابة تالفة بسرعة. توفر PITR تاريخًا يمكن الرجوع إليه إذا بقي Archive مكتملًا. وفي المقابل قد تستغرق PITR وقتًا أطول من Availability Target بالثواني. تحتاج الأنظمة الموثوقة غالبًا الاثنين مع Credentials وFailure Domains منفصلة.

قد تسرّع Volume Snapshot الاستعادة، لكن Crash-consistent Storage وحدها لا تثبت Application-consistent Backup لـPostgreSQL أو WAL Archive مكتملة. راجع Semantics الخاصة بمزود التخزين وإجراء PostgreSQL. لا تصف Snapshot Schedule بأنها PITR ما لم تتوفر Base State وWAL Continuity وRecovery Target تم اختباره.

Anti-patterns ومتى لا تكفي PITR

لا تخزن Backup على القرص أو الحساب نفسه الخاص بالـPrimary. لا تمنح Database Archiver صلاحية حذف كل نسخ التعافي. لا تضبط `archive_timeout` صغيرًا جدًا دون فهم نمو التخزين، ولا تعتبر Replication Lag دليل Archive Durability. تجنب Incremental Chains غير المختبرة وTablespaces غير الموثقة وBackup Objects القابلة للتعديل وRestore Scripts تنزّل “latest” دون تثبيت هوية واضحة.

ليست PITR أفضل جواب لكل استعادة. استخدم Logical Dumps عند الحاجة إلى Objects انتقائية قابلة للنقل أو Cross-version Migration. استخدم PITR Restore معزولة ثم Logical Export لإصلاح جزء من البيانات بعد خطأ تطبيق. واستخدم Replication أو Managed Failover لعطل بنية يحتاج تعافيًا سريعًا. لا يلغي أي منها خطة مختبرة للـCredentials وDNS أو Connection Cutover واتساق التطبيق والمراقبة بعد العودة.

قائمة تنفيذية للتعافي

سمِّ Cluster والمالكين وRPO وRTO وRetention Window. سجّل هويات Base Backup وWAL. راقب آخر Backup صالحة وArchive Lag. احمِ Repository بصلاحيات منفصلة وفق Least Privilege وImmutable Retention عند الحاجة. تحقّق من Manifests، ثم نفّذ Restore في بنية جديدة. اختبر Recovery Target دقيقًا وBusiness Invariants. قِس كل مرحلة واحتفظ بالدليل وحوّل النتيجة إلى Action List.

أقوى مقياس لـPostgreSQL Backup ليس عدد Jobs المكتملة، بل عمر ومدة آخر Recovery تم التحقق منها بصورة مستقلة. عندما يدرّب الفريق هذا المسار، تصبح RPO وRTO خصائص هندسية قابلة للملاحظة بدل وعود لا تُختبر إلا أثناء الحادث.

إعداد: Noor Yasser