أتمتة Backup PostgreSQL بـ WAL-G و S3 — استرجاع Point-in-Time في 5 دقائق

الخطوة 2: إعدادات البيئة

أنشئ ملف /etc/wal-g.d/env.sh بصلاحيات 600 للمستخدم postgres:

الـ WALG_DELTA_MAX_STEPS=6 معناه إن WAL-G ياخد full backup مرة كل 7 أيام، والبقية delta backups. ده بيوفّر 60-70% من حجم التخزين على S3.

الخطوة 3: تعديل postgresql.conf

الـ archive_timeout = 60 بيجبر PostgreSQL يقفل الـ WAL segment كل 60 ثانية حتى لو مش متلي. ده بيضمن إن RPO الأقصى = 60 ثانية، مش 16MB من الكتابة.

اعمل sudo systemctl restart postgresql.

الخطوة 4: أول base backup

المخرج المتوقّع: سطر فيه FINISHED: backup-push مع اسم الـ backup (مثلاً base_000000010000000000000005).

الخطوة 5: أتمتة الجدولة و التنظيف

أنشئ /etc/cron.d/wal-g-backup:

سيناريو حقيقي: الاسترجاع لما الكارثة تحصل

الساعة 11:43 صباحًا، مطوّر شغّل DELETE FROM orders WHERE status = 'pending' بدون WHERE customer_id =. مسح 12,400 طلب. هتعمل إيه؟

خطوات الاسترجاع لـ سيرفر منفصل

القاعدة الذهبية: متعملش restore فوق قاعدة الإنتاج. ركّب Postgres نضيف على سيرفر تاني وارجع له، ثم انقل البيانات الناقصة.

أضف لـ postgresql.conf:

هتشوف رسائل زي recovery stopping before commit of transaction .... PostgreSQL هيقف عند الثانية اللي طلبتها بالظبط.

الأرقام الفعلية والـ Trade-offs

قياسات من قاعدة إنتاج 47GB، 800 transaction/min:

• وقت الـ base backup الكامل: 8 دقايق و 21 ثانية مع brotli compression.
• حجم الـ backup المضغوط: 14.2GB (نسبة ضغط 70%).
• تكلفة S3 شهريًا (eu-central-1, 30 يوم retention): 4.80$ تخزين + 1.20$ requests = ~6 دولار.
• وقت الاسترجاع لـ نقطة قبل ساعتين: 4 دقايق و 47 ثانية (fetch + replay).
• الـ overhead على سيرفر الإنتاج: أقل من 2% CPU عند الـ archive_push (قياس على c6i.xlarge).

الـ trade-off الأساسي: WAL-G بيكتب على S3 كل دقيقة، يعني فاتورة Cloudflare R2 أو Backblaze B2 هتكون أرخص بـ 60-80% من S3 العادي لو كتاباتك كثيرة. R2 مفيهاش egress fees، فلو هتسترجع كثير في dev/staging، اختار R2.

متى لا تستخدم WAL-G

WAL-G ممتاز لأغلب السيناريوهات، لكن مش الأنسب في:

• قواعد بيانات أكبر من 1TB: هنا pgBackRest بيتفوّق بسبب الـ block-level incremental backup الأكثر كفاءة.
• إدارة backup مركزية لأكثر من 10 سيرفرات: Barman بيوفّر dashboard مركزي و Barman-to-Barman replication.
• مشاريع شخصية صغيرة (<1GB): pg_dump يومي + رفع على S3 كافي ومجاني تقريبًا.
• لو محتاج Logical replication targeted (نسخة جزئية لجداول معينة): WAL-G physical-only.

اختبر إن النظام شغّال فعلًا — مش افتراضًا

الـ backup اللي ما اتجرّبش = مفيش backup. اعمل drill شهري:

شغّله من cron أول كل شهر، وابعت النتيجة على Discord/Slack. لو فشل، انت عرفت قبل ما الكارثة تحصل.

الخطوة التالية

افتح postgresql.conf النهارده وغيّر archive_mode = on. ركّب WAL-G في 30 دقيقة باتّباع الخطوات أعلاه، وعمل أول backup-push يدوي. لو الـ archive_command فشل، شوف /var/log/wal-g.log أول حاجة — 90% من المشاكل سببها صلاحيات S3 ناقصة (محتاج s3:PutObject و s3:ListBucket على الـ prefix بالظبط).

المصادر

• WAL-G PostgreSQL Documentation (Read the Docs)
• WAL-G GitHub Repository
• PostgreSQL 18 — Continuous Archiving and Point-in-Time Recovery (PITR)
• Postgres WAL Archiving: A Complete Walkthrough — Fusionbox
• Top Open-Source Postgres Backup Solutions in 2026 — Bytebase
• Automating Backups and Disaster Recovery in PostgreSQL at Scale — Severalnines