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

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

هذا الدليل يغطي بنية النسخ الاحتياطي واستعادة البيانات التي نستخدمها لقواعد بيانات PostgreSQL في الإنتاج لمنتجات SaaS، بما في ذلك أرشفة WAL، واستعادة النقطة الزمنية، واستراتيجية RDS.

لماذا pg_dump وحده غير كافٍ

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

لا توجد استعادة نقطة زمنية. إذا حذف مستخدم 50,000 صف في الساعة 14:30 وآخر نسخة احتياطية كانت في الساعة 02:00، تخسر 12.5 ساعة من البيانات.

النسخ الاحتياطية المتكررة تُبطئ الإنتاج. تشغيل pg_dump على قاعدة بيانات حجمها 100 جيجابايت كل ساعة يُثقل الخادم.

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

الحل هو دمج pg_dump مع أرشفة WAL لتحقيق استعادة النقطة الزمنية.

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

PostgreSQL يكتب كل التغييرات في Write-Ahead Log (WAL) قبل تطبيقها. إذا أرشفت هذه الملفات باستمرار، يمكنك:

1. البدء من نسخة احتياطية أساسية كاملة
2. إعادة تطبيق ملفات WAL حتى نقطة زمنية محددة

هذا يمنحك دقة استعادة لثانية واحدة.

لإعداد أرشفة WAL، أضف إلى postgresql.conf:

wal_level = replica
archive_mode = on
archive_command = 'aws s3 cp %p s3://your-backup-bucket/wal/%f'
archive_timeout = 300

استراتيجية RDS على AWS

إذا كنت تستخدم Amazon RDS أو Aurora PostgreSQL، الكثير من هذا مُدار تلقائياً:

النسخ الاحتياطية الآلية: RDS يأخذ لقطات يومية ويُرشف WAL، يمنحك استعادة نقطة زمنية.

اللقطات اليدوية: لا تنتهي صلاحيتها تلقائياً. استخدمها قبل ترقيات كبرى.

الإعداد الموصى به:

فترة الاحتفاظ: 14 يوماً
نسخ متعددة المناطق: مفعلة
تشفير البيانات: مفعل

اختبار الاستعادة: الخطوة التي يتخطاها الجميع

اختبر الاستعادة شهرياً في بيئة اختبار:

aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-identifier prod-database \
    --target-db-instance-identifier restore-test-$(date +%Y%m%d) \
    --restore-time $(date -u -d '2 hours ago' --iso-8601=seconds)

قس RTO الفعلي. إذا استغرقت قاعدة بيانات 100 جيجابايت ساعتين للاستعادة وعقدك مع العملاء يتطلب SLA بوقت تشغيل 99.9%، أنت خارج SLA خلال عمليات الاستعادة.

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

أضف تنبيهاً إذا لم تنجح أي نسخة احتياطية خلال 25 ساعة. هذا يمنحك نافذة ساعة واحدة بعد النسخة المجدولة للكشف عن الفشل.