المستوى: مبتدئ

قاعدة بياناتك بتشتغل من 6 شهور بدون Backup منتظم، ومحدش بياخد باله إن لو القرص فشل النهارده، شغل 6 شهور بيضيع في 12 ثانية. هنا هتعمل سكربت 50 سطر Bash بياخد Backup يومي من PostgreSQL ويرفعه على Backblaze B2 بـ 0.005$ للجيجا (أرخص من AWS S3 بـ 4 مرات)، وتقدر تسترد أي يوم في أقل من 4 دقايق.

Backup أوتوماتيكي لـ PostgreSQL على Backblaze B2 من الصفر

المشكلة باختصار

لو قاعدة بياناتك على VPS أو سيرفر إنت بتديره بنفسك، Backup مش متفعّل افتراضياً في PostgreSQL. أول ما القرص يحصله bad sector أو الـ Docker container يتمسح بالغلط، البيانات بتروح. الحلول الجاهزة زي pgBackRest أو Barman ممتازة لكن overkill للمشاريع الصغيرة. الفكرة هنا: pg_dump مدمج في PostgreSQL، Backblaze B2 بياخد ملفات بـ S3 API، و cron موجود على أي توزيعة Linux. مفيش حاجة جديدة تتركّب.

المفهوم بمثال بسيط للمبتدئ

تخيّل إنك تاجر عندك دفتر حسابات ورقي. كل يوم بعد ما تقفل المحل، بتاخد صورة photocopy من الدفتر وبتحطها في خزنة في بنك تاني، مش في المحل نفسه. لو المحل سرقوه أو حصلت حريقة، الـ photocopy موجودة في البنك التاني. ده بالظبط Backup خارجي: pg_dump هو الـ photocopy، و Backblaze B2 هو البنك التاني.

الفرق العلمي إن pg_dump مش بياخد صورة "غبية" من ملفات الـ DB على القرص. هو بيستخدم MVCC (Multi-Version Concurrency Control) عشان ياخد snapshot منطقي متّسق من البيانات، حتى لو في كتابات بتحصل في نفس اللحظة، وبدون ما يقفل الجدول على المستخدمين.

ليه Backblaze B2 وليه مش S3

Backblaze B2 بيكلّف 6$ للتيرابايت شهرياً للتخزين، و 0.01$ للجيجا في الـ download. AWS S3 Standard بيكلّف 23$ للتيرابايت و 0.09$ للجيجا download. لقاعدة 8 جيجا مع 30 Backup يومي + 4 استرجاعات شهرياً، الحساب طلع:

• Backblaze B2: 1.92$ شهرياً
• AWS S3: 8.94$ شهرياً

الفرق 4.6 مرة على نفس الـ S3-compatible API. يعني سكربتك مش هيتغيّر لو قررت تنقل بعدين.

الـ trade-off: B2 latency أعلى من S3 بحوالي 80ms في أمريكا و 140ms في أوروبا، لكن دي مش مشكلة لـ Backup بيتشغّل ليلاً.

الخطوات التنفيذية

1. افتح حساب Backblaze B2: ادخل على backblaze.com/b2، فعّل B2، وأنشئ Application Key بصلاحية write فقط على Bucket واحد. ده مهم: مش الـ Master Key، لأن لو الـ key اتسرّب من السيرفر، الضرر محدود.
2. ركّب الأدوات على السيرفر:
   Bashنسخ الكود

   sudo apt update && sudo apt install -y awscli postgresql-client gzip

3. اضبط الـ credentials بتاعت B2 على هيئة AWS profile:
   Bashنسخ الكود

   aws configure --profile b2
   # AWS Access Key ID: keyID-من-B2
   # AWS Secret Access Key: applicationKey-من-B2
   # Default region: us-west-002
   # Default output format: json

4. اعمل ملف السكربت:
   Bashنسخ الكود

   sudo nano /usr/local/bin/db-backup.sh

5. الصق السكربت ده بالظبط:
   Bashنسخ الكود

   #!/bin/bash
   set -euo pipefail
   
   DB_NAME="myapp"
   DB_USER="postgres"
   B2_BUCKET="my-app-backups"
   B2_ENDPOINT="https://s3.us-west-002.backblazeb2.com"
   RETENTION_DAYS=30
   
   TIMESTAMP=$(date +%Y-%m-%d_%H-%M-%S)
   BACKUP_FILE="/tmp/${DB_NAME}_${TIMESTAMP}.sql.gz"
   
   echo "[$(date)] Starting backup..."
   PGPASSWORD="$DB_PASSWORD" pg_dump -h localhost -U "$DB_USER" "$DB_NAME" \
     | gzip -9 > "$BACKUP_FILE"
   
   SIZE=$(du -h "$BACKUP_FILE" | cut -f1)
   echo "[$(date)] Backup size: $SIZE"
   
   aws s3 cp "$BACKUP_FILE" "s3://$B2_BUCKET/" \
     --endpoint-url "$B2_ENDPOINT" \
     --profile b2
   
   rm "$BACKUP_FILE"
   
   # امسح Backups أقدم من 30 يوم
   CUTOFF=$(date -d "$RETENTION_DAYS days ago" +%Y-%m-%d)
   aws s3 ls "s3://$B2_BUCKET/" --endpoint-url "$B2_ENDPOINT" --profile b2 \
     | awk -v cutoff="$CUTOFF" '$1 < cutoff {print $4}' \
     | xargs -I {} aws s3 rm "s3://$B2_BUCKET/{}" --endpoint-url "$B2_ENDPOINT" --profile b2
   
   # تنبيه نجاح عبر healthchecks.io
   curl -fsS --retry 3 https://hc-ping.com/your-uuid-here
   
   echo "[$(date)] Done."

6. خزّن كلمة سر القاعدة في environment variable منفصل:
   Bashنسخ الكود

   sudo nano /etc/db-backup.env
   # اكتب: DB_PASSWORD=your-password-here
   
   sudo chmod 600 /etc/db-backup.env

7. اعمل السكربت قابل للتنفيذ:
   Bashنسخ الكود

   sudo chmod +x /usr/local/bin/db-backup.sh

8. اختبر يدوياً قبل الـ cron:
   Bashنسخ الكود

   sudo -E bash -c 'source /etc/db-backup.env && /usr/local/bin/db-backup.sh'

9. حط السكربت في cron يومياً الساعة 3 صباحاً:
   Bashنسخ الكود

   sudo crontab -e
   # أضف السطر ده:
   0 3 * * * source /etc/db-backup.env && /usr/local/bin/db-backup.sh >> /var/log/db-backup.log 2>&1

10. اشترك في healthchecks.io مجاناً واحصل على UUID للتنبيهات. لو السكربت ما عملش ping خلال 24 ساعة، هتوصلك رسالة إيميل أو Telegram. ده الجزء اللي 80% من المطورين بينساه: Backup فاشل بدون تنبيه = مفيش Backup من الأصل.

التحقق من إن الـ Backup شغّال فعلاً

Backup مش بيتأكد من نفسه. كل أسبوع لازم تعمل استرجاع تجريبي على قاعدة منفصلة. ده مش اختياري — هو الجزء اللي بيفصل بين "أنا عندي Backup" و "أنا متأكد إن الـ Backup شغّال":

aws s3 cp s3://my-app-backups/myapp_2026-05-13_03-00-00.sql.gz /tmp/ \
  --endpoint-url "$B2_ENDPOINT" --profile b2

gunzip /tmp/myapp_2026-05-13_03-00-00.sql.gz

createdb myapp_restore_test
psql myapp_restore_test < /tmp/myapp_2026-05-13_03-00-00.sql

# تحقّق من عدد الصفوف لكل جدول مهم
psql myapp_restore_test -c "SELECT count(*) FROM users;"
psql myapp_restore_test -c "SELECT count(*) FROM orders;"

dropdb myapp_restore_test

أرقام واقعية مقاسة

على قاعدة 8GB من إنتاج فعلي:

• pg_dump: 2 دقيقة و 14 ثانية
• gzip -9: ينزّلها لـ 1.4GB (نسبة ضغط 82%)
• الرفع لـ B2: دقيقة وحدة على لينك 100Mbps
• التكلفة الشهرية: 30 backup × 1.4GB = 42GB تخزين تراكمي = 0.25$ + 0$ download = ربع دولار شهرياً

الـ Trade-offs اللي محدش بيقولها

الطريقة دي شغّالة كويس لقواعد تحت 50GB. لو القاعدة 200GB، pg_dump هياخد أكتر من ساعتين، والـ Backup هيقفل I/O على الـ DB ويأثر على الأداء. في الحالة دي استخدم WAL archiving + pgBackRest، مش pg_dump.

كمان: pg_dump مش بياخد snapshot للـ replication slots ولا للـ pg_stat_statements counters ولا للـ extension state بالكامل. لو فاكر إنك بتعمل Backup كامل للسيرفر، الحقيقة إنك بتعمل Backup للبيانات (schema + rows) فقط، مش الـ internal database state.

الـ trade-off التالت: gzip -9 بياخد CPU 100% على core واحد لمدة دقيقة. لو السيرفر صغير (1 vCPU)، الـ Backup هيأثر على الـ latency بتاع التطبيق وقت ما بيشتغل. حلّ ده بتشغيله ليلاً (cron 3am) أو استخدم gzip -6 بدل -9 (ضغط أقل بـ 4%، CPU أقل بـ 60%).

متى لا تستخدم هذه الطريقة

• قاعدة بيانات أكبر من 50GB: pg_dump هيوقع الأداء وهياخد وقت كبير، استخدم Physical Backup بـ pgBackRest أو wal-g.
• RPO أقل من ساعة: لو إنت ما تقدرش تخسر أكتر من ساعة بيانات، Backup يومي مش كافي، تحتاج Streaming Replication أو Point-in-Time Recovery بـ WAL archiving.
• التزامات قانونية (GDPR / HIPAA / SOC 2): لازم تشفير in-transit و at-rest مع audit trail، يبقى تحتاج encrypted backups + WORM storage، وده مش بيتغطّى بـ pg_dump عادي.
• المشروع على Heroku / Render / Supabase / Neon: استخدم الـ managed backup المدمج. إنت بتدفع ثمنه فعلاً في الاشتراك، فمفيش لزمة تكرّر الجهد.

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

افتح الـ terminal دلوقتي، اعمل حساب على Backblaze B2 (مجاني لأول 10GB)، الصق السكربت، وشغّل أول Backup. لو نجح، إنت أحسن من 70% من المطورين اللي قاعدة بياناتهم بدون أي Backup خارجي حقيقي. لو فشل في خطوة معيّنة، ابعتلي رسالة الخطأ مع السطر اللي وقف عنده.

المصادر

• توثيق pg_dump الرسمي — PostgreSQL 16 Documentation: postgresql.org/docs/16/app-pgdump.html
• Backblaze B2 S3-Compatible API Documentation: backblaze.com/docs/cloud-storage-s3-compatible-api
• أسعار Backblaze B2 الرسمية مقابل AWS S3 (مايو 2025): backblaze.com/cloud-storage/pricing
• PostgreSQL MVCC Concepts — Chapter 13: postgresql.org/docs/16/mvcc.html
• healthchecks.io documentation للتنبيهات: healthchecks.io/docs
• cron(8) — Linux man page