أتمتة النسخ الاحتياطي كخط دفاع أول

النسخة الاحتياطية اللي محدش بيتحقق منها = مفيش نسخة احتياطية. الهدف هنا مش بس تشغّل pg_dump، الهدف تبني دورة مغلقة: تنفيذ، تحقق، تنبيه. لو الـ backup فشل الساعة 3 الصبح، لازم تعرف قبل ما توصل الشغل.

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

الفرق المبتدئة غالباً بتبدأ بواحد من تلات أنماط فاشلة: نسخة محلية بس على نفس السيرفر، أو pg_dump بدون retention policy فبيتراكم لساعة ما يملا الـ disk، أو cron job بيشتغل لكن مفيش حد بيتابع logs. النتيجة واحدة في التلاتة: لما بتحصل كارثة (drop table بالغلط أو corruption) بتكتشف إن آخر backup شغال من شهرين.

مثال بسيط قبل ما ندخل في التقني: تخيل إن عندك خزنة فيها فلوسك، وبتحط فيها كوبي من مفتاح شقتك كل يوم. لكن الخزنة دي جوا نفس الشقة. لو حصل حريق، راح المفتاح راحت الخزنة. النسخة الاحتياطية المحلية نفس الفكرة بالظبط — لازم تكون في مكان تاني فعلي.

المفهوم بشكل علمي: قاعدة الـ 3-2-1 في صناعة التخزين بتقول: 3 نسخ من البيانات، على 2 أنواع تخزين مختلفة، 1 منهم off-site (خارج الموقع الأصلي). الـ workflow اللي هنا بيحقق الـ 1 off-site من خلال S3، وبيخلي الـ cron + Telegram يضمنوا التحقق اليومي.

المكوّنات اللي هنستخدمها

• pg_dump — أداة PostgreSQL الرسمية لتصدير قاعدة البيانات.
• aws-cli — لرفع الملف على S3 bucket.
• cron — لجدولة التشغيل اليومي.
• Telegram Bot API — لإرسال إشعار التأكيد.
• gzip — لضغط الملف قبل الرفع (بيوفر من 60% إلى 80% من الحجم في أغلب الحالات).

الافتراضات قبل ما نبدأ

الشرح ده مبني على فرضية إن قاعدة بياناتك حجمها أقل من 50GB، وبتشتغل على Ubuntu أو Debian، وعندك حساب AWS مع IAM user ليه صلاحية s3:PutObject على bucket محدد. لو القاعدة أكبر من كده، الأسلوب ده هيشتغل لكن زمن الـ dump هيتخطى 15 دقيقة وهتحتاج تفكر في pg_basebackup أو WAL archiving بدل الـ logical dump.

السكربت الكامل

احفظ الملف ده في /opt/scripts/pg_backup.sh واعمله chmod +x.

#!/usr/bin/env bash
set -euo pipefail

DB_NAME="production_db"
DB_USER="postgres"
BUCKET="s3://my-backups-bucket/postgres"
TELEGRAM_TOKEN="123456:ABC-DEF..."
TELEGRAM_CHAT_ID="987654321"

TIMESTAMP=$(date +%Y-%m-%d_%H-%M)
FILENAME="${DB_NAME}_${TIMESTAMP}.sql.gz"
TMP_PATH="/tmp/${FILENAME}"

START=$(date +%s)

notify() {
  local msg="$1"
  curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage" \
    -d "chat_id=${TELEGRAM_CHAT_ID}" \
    -d "text=${msg}" > /dev/null
}

trap 'notify "❌ Backup فشل لـ ${DB_NAME} على $(hostname)"' ERR

pg_dump -U "$DB_USER" -d "$DB_NAME" -F p | gzip -9 > "$TMP_PATH"

SIZE_MB=$(du -m "$TMP_PATH" | cut -f1)

aws s3 cp "$TMP_PATH" "${BUCKET}/${FILENAME}" --storage-class STANDARD_IA

DURATION=$(( $(date +%s) - START ))

rm -f "$TMP_PATH"

notify "✅ Backup ناجح — ${DB_NAME} — ${SIZE_MB}MB — ${DURATION}s"

ركز في حاجة مهمة: set -euo pipefail و trap ... ERR بيضمنوا إن أي خطوة تفشل، الـ script يوقف ويبعت تنبيه فشل. بدون الجزء ده، ممكن pg_dump يرجّع ملف فاضي لو فيه مشكلة صلاحيات، والـ aws s3 cp يرفعه عادي، وأنت تفتكر إن كل حاجة تمام.

جدولة الـ cron

sudo crontab -e
# أضف السطر التالي
0 3 * * * /opt/scripts/pg_backup.sh >> /var/log/pg_backup.log 2>&1

الساعة 3 صباحاً اختيار مدروس: في أغلب التطبيقات العربية التحميل بيكون في الحد الأدنى بين 2 و 5 صباحاً. pg_dump بياخد lock خفيف فقط (مش exclusive)، لكن ضغط gzip -9 بياكل CPU. تشغيله وقت الذروة هيأثر على زمن الاستجابة للمستخدمين.

إعداد Telegram Bot في 3 خطوات

1. افتح محادثة مع @BotFather على Telegram واكتب /newbot، هيديك token شكله 123456:ABC-DEF....
2. ابعت أي رسالة للـ bot الجديد، بعدين افتح https://api.telegram.org/bot<TOKEN>/getUpdates في المتصفح وخد chat.id من الـ JSON.
3. حط القيمتين في السكربت فوق.

Retention policy — متتجاهلهاش

بدون سياسة حذف، الـ bucket هيتحول لمدفن ملفات. أضف lifecycle rule على S3 تحذف النسخ الأقدم من 30 يوم، أو انقلها لـ Glacier لو محتاج تحتفظ بيها أطول بتكلفة أقل. التكلفة التقديرية: 50GB × $0.0125/GB في STANDARD_IA = حوالي 62 سنت شهرياً لـ 30 يوم retention. انتقال لـ Glacier بيخفضها لـ 20 سنت.

الـ trade-offs

الطريقة دي بتكسب بساطة التركيب (أقل من ساعة شغل)، وتكلفة منخفضة، وإشعار فوري. بتخسر نقطتين:

• RPO (Recovery Point Objective) = 24 ساعة. أي بيانات دخلت بعد آخر backup هتضيع لو حصل loss. لو ده غير مقبول، تحتاج streaming replication أو continuous WAL archiving.
• Restore time ممكن يكون طويل. لـ قاعدة 30GB، تنزيل من S3 + psql restore ممكن ياخد 40-60 دقيقة. استعد للرقم ده في الـ incident plan.

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

لو عندك نظام financial transactions أو healthcare records، أو قاعدة بيانات أكبر من 100GB، أو بتحتاج RPO أقل من ساعة، مش كفاية. في الحالات دي استخدم pgBackRest مع incremental backups، أو managed service زي Amazon RDS اللي بياخد snapshots كل 5 دقائق. كمان لو الفريق بتاعك مش بيتابع Telegram، ابعت لـ PagerDuty أو Opsgenie بدل.

التحقق من أنه يعمل — خطوة مهمة بيتهربوا منها

كل أسبوع، نزّل آخر backup فعلياً واعمله restore على قاعدة test. لو الـ restore فشل، الـ backup عديم القيمة. اعمل cron تاني يشغّل الاختبار ده كل يوم جمعة ويبعت نتيجة على Telegram. معظم كوارث البيانات في الصناعة حصلت لفرق كان عندها backup "شغال" بس ما اتجربش من شهور.

المصادر

• PostgreSQL Documentation — pg_dump reference: postgresql.org/docs/current/app-pgdump.html
• AWS S3 Storage Classes pricing: aws.amazon.com/s3/pricing
• Telegram Bot API — sendMessage: core.telegram.org/bots/api
• 3-2-1 Backup Rule (US-CERT publication): cisa.gov/news-events/news/data-backup-options
• pgBackRest للحالات الأكبر: pgbackrest.org

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

خد السكربت فوق، عدّل المتغيرات الخمسة في الأول، جربه يدوي مرة واحدة بـ bash /opt/scripts/pg_backup.sh. لو وصلك إشعار Telegram بالحجم والمدة، ضيف سطر الـ cron. لو فشل، اقرا /var/log/pg_backup.log وابدأ من أول error. الخطوة اللي بعدها (بعد ما يستقر أسبوع): اكتب سكربت restore test وشغّله كل جمعة.