النسخ الاحتياطي والتعافي من الكوارث

النسخ الاحتياطي لـ PostgreSQL: pg_dump وpg_basebackup والاستعادة إلى نقطة زمنية عبر أرشفة WAL

تصدير منطقي عبر pg_dump، ونسخ فيزيائية عبر pg_basebackup مع pg_verifybackup، وأرشفة WAL للاستعادة إلى لحظة محددة على Debian وUbuntu.

تاريخ النشر
مدة القراءة
6 دقائق
الكاتب
SKYLINE Engineering

يوفّر PostgreSQL ثلاث طرق للنسخ الاحتياطي يشرحها دليله الرسمي: تصدير SQL، والنسخ على مستوى نظام الملفات (النسخة الأساسية base backup)، والأرشفة المستمرة لسجل الكتابة المسبقة (WAL). تبدأ أغلب البيئات الصغيرة والمتوسطة بالتصدير، ثم تضيف النسخ الأساسية مع نمو البيانات، ثم أرشفة WAL حين يصبح فقدان يوم من التغييرات غير مقبول. يغطي هذا الدليل الطرق الثلاث بأوامر تعمل على خوادم Debian وUbuntu.

تحقق من الإصدار أولاً

يدعم مشروع PostgreSQL كل إصدار رئيسي مدة خمس سنوات. وحتى أواخر أكتوبر 2026 فإن الإصدارات المدعومة هي 18 و17 و16 و15 و14، ويصدر آخر تحديث للإصدار 14 في نوفمبر 2026. وتحزم Debian 13 (trixie) الإصدار 17، وDebian 12 (bookworm) الإصدار 15. وفي Debian يحتفظ كل عنقود (cluster) بإعداداته في /etc/postgresql/<version>/<cluster>/ وبياناته في /var/lib/postgresql/<version>/<cluster>.

pg_lsclusters
sudo -u postgres psql -c 'SELECT version();'

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

النسخ المنطقي عبر pg_dump

يصدّر pg_dump نسخة متسقة حتى أثناء استخدام قاعدة البيانات، ولا يعطّل القرّاء ولا الكتّاب. والأفضل استخدام الصيغة المخصصة (-Fc) المضغوطة افتراضياً والتي تتيح لأداة pg_restore اختيار العناصر وإعادة ترتيبها، أو صيغة المجلد (-Fd) التي تدعم التصدير المتوازي عبر -j.

sudo install -d -o postgres -g postgres -m 700 /var/backups/pg
sudo -u postgres pg_dump -Fc -f /var/backups/pg/shop-$(date +%F).dump shop
# large database: directory format with 4 parallel jobs
sudo -u postgres pg_dump -Fd -j 4 -f /var/backups/pg/shop-dir shop

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

sudo -u postgres pg_dumpall --globals-only -f /var/backups/pg/globals-$(date +%F).sql

وللاستعادة أنشئ الأدوار أولاً، ثم حمّل الأرشيف عبر pg_restore. ويمكنك عرض محتويات الأرشيف دون استعادة أي شيء، وهو فحص أولي رخيص يؤكد أن الملف قابل للقراءة:

sudo -u postgres pg_restore -l /var/backups/pg/shop-2026-10-31.dump | head
sudo -u postgres psql -f /var/backups/pg/globals-2026-10-31.sql
sudo -u postgres createdb shop_restored
sudo -u postgres pg_restore -d shop_restored -j 4 /var/backups/pg/shop-2026-10-31.dump

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

النسخ الفيزيائي عبر pg_basebackup

تنسخ أداة pg_basebackup العنقود كاملاً عبر اتصال نسخ متماثل (replication) والخادم يعمل، وتحتاج دوراً يملك الخاصية REPLICATION (والمستخدم الأعلى postgres يملكها). وافتراضياً تبث الأداة سجلات WAL المتولدة أثناء النسخ إلى جانب البيانات، فيمكن تشغيل النسخة وحدها:

sudo -u postgres pg_basebackup -D /var/backups/pg/base-$(date +%F) -P
sudo -u postgres pg_verifybackup /var/backups/pg/base-2026-10-31

ويكتب الخادم أيضاً ملف backup_manifest يصف كل ملف، وتتحقق أداة pg_verifybackup (من الإصدار 13 فصاعداً) من النسخة مقابله، بما في ذلك وجود ملفات WAL اللازمة للاستعادة. يستخدم المثال الصيغة العادية (plain) الافتراضية لأنها ما تقرؤه الأداة في كل الإصدارات المدعومة. أما صيغة tar (-Ft -z) فتوفّر المساحة، لكن حتى الإصدار 17 يجب فكّ نسخة tar قبل التحقق منها، بينما يستطيع الإصدار 18 فحصها مباشرة دون خطوة WAL (-n).

ويؤكد الدليل أن التحقق لا يشمل كل الفحوص التي يجريها خادم عامل، فلا بد من الاستعادة التجريبية مع ذلك. كما يستطيع الإصدار 17 وما بعده أخذ نسخ أساسية تزايدية عبر pg_basebackup --incremental ودمجها عبر pg_combinebackup، معتمداً على ملخصات WAL التي يحتفظ بها الخادم.

الاستعادة إلى نقطة زمنية عبر أرشفة WAL

نسخة أساسية ومعها كل ملفات WAL المكتوبة بعدها تتيح لك إعادة قاعدة البيانات إلى أي لحظة، كالدقيقة التي سبقت حذف جدول مثلاً. فعّل الأرشفة في postgresql.conf وأعد تشغيل العنقود:

wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'

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

وتتبع الاستعادة الإجراء الوارد في الدليل:

  1. أوقف الخادم، وإن سمحت المساحة فانسخ مجلد البيانات الحالي إلى مكان آمن.
  2. أفرغ مجلد البيانات واستعد فيه النسخة الأساسية بالملكية الصحيحة.
  3. احذف الملفات الموجودة في pg_wal/ والقادمة من النسخة.
  4. اضبط restore_command وهدفاً مثل recovery_target_time في postgresql.conf، وأنشئ ملفاً فارغاً باسم recovery.signal في مجلد البيانات.
  5. شغّل الخادم ودعه يعيد تنفيذ الأرشيف، وافحص البيانات، ثم اسمح للمستخدمين بالدخول.
restore_command = 'cp /mnt/server/archivedir/%f %p'
recovery_target_time = '2026-10-31 15:59:00+03'

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

اختبر الاستعادة لا النسخ وحده

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

ما الذي ينبغي فعله

  1. تأكد من أن إصدارك الرئيسي مدعوم، واستخدم أدوات عميل بالإصدار نفسه أو أحدث.
  2. خذ تصديراً ليلياً بالأمر pg_dump -Fc لكل قاعدة بيانات مع pg_dumpall --globals-only، وانسخ الملفات خارج الخادم.
  3. أضف pg_basebackup مع pg_verifybackup حين تصبح الاستعادة من التصدير بطيئة.
  4. إن احتجت الاستعادة إلى نقطة زمنية فجهّز أرشفة WAL إلى تخزين خارج الخادم، وتأكد من أن أمر الأرشفة يفشل بوضوح.
  5. تدرّب على الاستعادة وفق جدول ثابت، ودوّن الزمن الذي استغرقته كل مرة.

المصادر

SKYLINE Engineering

@skyline

The engineering team at SKYLINE Industrial Solutions. We publish field-tested guides drawn from real KSA and GCC deployments.

صفحة الكاتب
SKYLINE engineering services

Need this implemented for you?

Reading is free — building it right takes a team. SKYLINE engineers ship Backup & Disaster Recovery for Aramco vendors, banks, hospitals and government agencies across Saudi Arabia. Talk to us before you start.

Aramco Approved Contractor ISO 9001 · ISO 27001 SAMA CSF aligned NCA ECC ready 247+ KSA clients

Comments

0 total · 0 threads
Be the first to leave a comment.