PostgreSQL Backup and Point-in-Time Recovery for Production SaaS: What Actually Works

A backup you have never tested is not a backup. Here is the backup and recovery architecture we use for production PostgreSQL databases running SaaS products across the MENA region, including WAL archiving, PITR, and RDS strategy.

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

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

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

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

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

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

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

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

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

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

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

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

استراتيجية العمل:

النسخ الاحتياطية الأساسية: كل يوم في الساعة 02:00
أرشفة WAL: باستمرار إلى S3
الاحتفاظ: 30 يوماً من النسخ الاحتياطية الأساسية، 7 أيام من WAL
هدف نقطة الاسترداد (RPO): أقل من 5 دقائق
هدف وقت الاسترداد (RTO): 30 إلى 60 دقيقة حسب حجم قاعدة البيانات

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

wal_level = replica
archive_mode = on
archive_command = 'aws s3 cp %p s3://your-backup-bucket/wal/%f'
archive_timeout = 300  # أرشف كل 5 دقائق حتى لو لم تمتلئ ملفات WAL

استخدام pgBackRest للنسخ الاحتياطية المدارة

إدارة أرشفة WAL يدوياً ممكنة لكنها معقدة. pgBackRest هي الأداة الأكثر استخداماً في الإنتاج:

# تثبيت pgBackRest
apt-get install pgbackrest

# إعداد pgbackrest.conf
[global]
repo1-type=s3
repo1-s3-bucket=your-backup-bucket
repo1-s3-region=us-east-1
repo1-retention-full=7
repo1-retention-diff=4

[main]
pg1-path=/var/lib/postgresql/14/main

# النسخ الاحتياطي الكامل الأول
pgbackrest --stanza=main backup --type=full

# النسخ الاحتياطية التفاضلية اليومية
pgbackrest --stanza=main backup --type=diff

pgBackRest يدير أرشفة WAL تلقائياً، يضغط الملفات، ويتعامل مع التشفير. كما يوفر استعادة متوازية تُسرع العملية بشكل ملحوظ.

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

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

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

اللقطات اليدوية: لا تنتهي صلاحيتها تلقائياً. استخدمها قبل تشغيل الترقيات أو عمليات البيانات الضخمة.

القواعد القريبة (Read Replicas): ليست نسخاً احتياطية، لكنها تحميك من فشل القاعدة الأساسية وتسمح بالترويج السريع.

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

فترة الاحتفاظ بالنسخ الاحتياطية: 14 يوماً
نسخ احتياطية متعددة المناطق: مفعلة
تشفير البيانات الساكنة: مفعل
تشفير البيانات المتنقلة: مفروض
نافذة الصيانة: أيام الأربعاء في الساعة 03:00-04:00

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

اختبار الاستعادة الدوري ليس اختيارياً. الخطوات:

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

# لـ RDS
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)

# التحقق من اكتمال الاستعادة
psql -h restore-test-db.region.rds.amazonaws.com -U admin -c "SELECT count(*) FROM users;"

# حذف قاعدة الاختبار بعد التحقق
aws rds delete-db-instance --db-instance-identifier restore-test-$(date +%Y%m%d) --skip-final-snapshot

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

اختبار سيناريوهات محددة:

حذف جدول كامل عن طريق الخطأ
تشغيل UPDATE بدون شرط WHERE
فساد بيانات على مستوى التطبيق

النسخ الاحتياطية على مستوى المستأجر

في SaaS متعدد المستأجرين، العملاء أحياناً يطلبون نسخة احتياطية من بياناتهم فقط. إذا كنت تستخدم workspace_id للعزل (وليس قواعد بيانات منفصلة)، يمكنك استخراج بيانات مستأجر واحد:

# تصدير بيانات مستأجر محدد
pg_dump \
    --table=orders \
    --where="workspace_id='uuid-here'" \
    --format=custom \
    production-db > tenant-backup.dump

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

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

لا تكتفي بتشغيل النسخ الاحتياطية، بل راقب نجاحها:

-- آخر نسخة احتياطية ناجحة في RDS
SELECT latest_restorable_time
FROM information_schema.tables
LIMIT 1;
-- أو استخدم AWS CloudWatch

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

الدروس الرئيسية

استخدم pg_dump للنسخ الاحتياطية الكاملة الدورية. أضف أرشفة WAL لتحقيق استعادة النقطة الزمنية. إذا كنت على RDS، فعل النسخ الاحتياطية الآلية مع فترة احتفاظ 14 يوماً. اختبر الاستعادة شهرياً وقس RTO الفعلي. راقب نجاح النسخ الاحتياطية وأضف تنبيهات.

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

هل تريد مراجعة بنية النسخ الاحتياطية لديك؟

Voxire تُراجع وتُحسن بنية PostgreSQL لمنتجات SaaS في لبنان ومنطقة MENA. إذا كنت غير متأكد من موثوقية نظام النسخ الاحتياطي لديك، تواصل معنا.

https://voxire.com/get-a-quote/