لماذا أداة مخصصة بدل pg_dump في crontab
أكثر طرق النسخ شيوعاً سطر واحد: أمر pg_dump يشغّله cron كل ليلة ويضغطه في مجلد. يعمل حتى اليوم الذي تكتشف فيه أنه كان يفشل منذ ثلاثة أسابيع دون أن يُنبَّه أحد، أو أن القرص امتلأ، أو أن الملف لا يُستعاد لغياب الدور المناسب.
يعالج Databasus هذه النقاط العمياء تحديداً: ينبّه عند كل فشل، ويطبّق سياسة احتفاظ، ويرسل النسخ خارج الجهاز، ويثبت أنها تُستعاد. ومع PostgreSQL يضيف ما لا يستطيعه التفريغ: نسخاً فيزيائية تزايدية وبث WAL للعودة إلى الدقيقة التي سبقت الخطأ.
ما يقدمه Databasus
- PostgreSQL فيزيائي ومنطقي — نسخ كاملة وتزايدية وبث WAL واستعادة إلى لحظة محددة (PITR).
- MySQL وMariaDB وMongoDB — نسخ منطقية مضغوطة من الواجهة نفسها.
- جدولة دقيقة — كل ساعة أو يومياً أو أسبوعياً أو شهرياً أو بتعبير cron.
- استعادة مُتحقَّق منها — استعادة حقيقية في قاعدة مؤقتة وتقرير لكل جدول.
- تخزين متعدد — القرص المحلي وS3 وCloudflare R2 وGoogle Drive وSFTP وRclone.
- تشفير AES-256-GCM — ملفات غير مقروءة حتى على تخزين مشترك.
- الفريق — مساحات عمل وأدوار وسجل تدقيق وتنبيهات البريد وTelegram وSlack وwebhook.
Databasus مقارنة بالطرق المعتادة
مرّر الجدول أفقيًا
| Databasus | pg_dump مع cron | لقطة الخادم | |
|---|---|---|---|
| تنبيه عند الفشل | نعم، عبر عدة قنوات | تكتبه بنفسك | حسب المستضيف |
| الاستعادة إلى لحظة محددة | نعم (بث WAL) | لا | لا، وقت اللقطة فقط |
| نسخة خارج الجهاز | S3 وR2 وSFTP وDrive | تحتاج سكربتاً | لدى المستضيف |
| استعادة مُتحقَّق منها | تلقائية مع تقرير | يدوية | يدوية |
| الدقة | لكل قاعدة | لكل قاعدة | القرص كاملاً |
| الواجهة والفريق | نعم، أدوار وتدقيق | لا | لوحة المستضيف |
المتطلبات
يكفي VPS بنظام Ubuntu 24.04 بذاكرة 1 غيغابايت لإدارة النسخ؛ وخصّص مساحة قرص إن احتفظت بنسخ محلية، أو حاوية S3 أو R2 لإرسالها إلى مكان آخر. تحتاج إلى Docker مع إضافة Compose، وإلى وصول شبكي من الخادم إلى القواعد ومستخدم مخصص للنسخ.
إن كانت قواعدك تعمل على خوادم أخرى، فافتح منفذها لعنوان IP الخاص بخادم Databasus فقط، لا للإنترنت كله: جدار ناري لا يقبل إلا هذا المصدر يحصر التعرض في جهاز واحد تتحكم فيه. أما القاعدة على الخادم نفسه فلا تحتاج إلى فتح أي منفذ نحو الخارج.
تثبيت Databasus باستخدام Docker Compose
إنشاء ملف Compose
أنشئ المجلد
/opt/databasusوضع فيه ملفdocker-compose.ymlالتالي. يُنشر المنفذ على الواجهة المحلية فقط، ويسمحextra_hostsللحاوية بالوصول إلى قاعدة مثبتة على الخادم نفسه عبر الاسمhost.docker.internal.services: databasus: image: databasus/databasus:v3.62.0 restart: unless-stopped ports: - "127.0.0.1:4005:4005" extra_hosts: - "host.docker.internal:host-gateway" volumes: - databasus-data:/databasus-data volumes: databasus-data: {}تشغيل الحاوية
شغّل Databasus وتابع إقلاعه:
docker compose up -d docker compose logs -f databasusعند أول تشغيل تهيّئ الصورة قاعدة بياناتها الوصفية وتطبّق ترحيلاتها في المجلد
databasus-data. يدل السطرhttp server listening on :4005على أنها جاهزة خلال ثوانٍ.فتح الواجهة وإنشاء الحساب
من جهازك افتح نفق SSH نحو الخادم:
ssh -L 4005:127.0.0.1:4005 root@<ip-vps>ثم افتح http://localhost:4005 وأنشئ حسابك: أول حساب يُنشأ يصبح المسؤول. تبقى التسجيلات اللاحقة مفتوحة افتراضياً بدور عضو، لذا عطّل التسجيلات الخارجية من الإعدادات.
تسجيل قاعدة PostgreSQL
أنشئ على خادم PostgreSQL دوراً مخصصاً لا يملك إلا القراءة:
CREATE ROLE databasus WITH LOGIN PASSWORD 'a-long-password'; GRANT pg_read_all_data TO databasus;في Databasus أضف القاعدة بمضيفها (لقاعدة على الخادم نفسه:
host.docker.internal) ومنفذها وهذا الدور وكلمة مروره، ثم وجهة تخزين وجدولة. شغّل أول نسخة يدوياً للتأكد من اكتمالها.
نسخة خارج الخادم دائماً
النسخة المحفوظة على قرص الخادم تحمي من أمر DROP TABLE خاطئ لا من فقدان الجهاز. أضف وجهة خارجية واحدة على الأقل — حاوية S3 أو R2 — وفعّل التشفير، فيصبح الملف عديم الفائدة لمن يصل إليه دون المفتاح.
اختيار سياسة الاحتفاظ
يقدم Databasus أربع طرق لتحديد السجل: مدة (سبعة أيام أو ثلاثة أشهر أو سنة)، وعدد (آخر ثلاثين نسخة)، وتدوير GFS (الجد والأب والابن: نسخ كل ساعة ويومية وأسبوعية وشهرية وسنوية يُحتفظ بها باستقلال)، وحدود الحجم لكل نسخة وللمجموع.
لتطبيق في الإنتاج، نقطة بداية جيدة هي نسخة يومية تُحفظ ثلاثين يوماً، مع تدوير GFS شهري على سنة، وحد إجمالي للحجم يمنع امتلاء التخزين. أضف بث WAL إن كان فقدان يوم من البيانات غير مقبول.
التحقق من أن الاستعادة تعمل
هذه هي الميزة التي تميّز Databasus. بعد كل نسخة أو وفق جدول، يشغّل قاعدة مؤقتة ويستعيد فيها النسخة ويقارن الحجم الناتج بحجم النسخة ويعرض كل جدول بعدد صفوفه. ويمكن أن يُرسَل إليك التقرير، أو حالات الفشل فقط.
جدول على الأقل تحققاً أسبوعياً لأهم قاعدة لديك. يوم الحادث لن تكتشف أن امتداداً أو دوراً كان ناقصاً، فالتحقق سيكون قد أخبرك بذلك قبل أسابيع.
احتفظ أيضاً بسجل لهذه التقارير، فهي دليل مؤرخ على أن خطة الاستعادة قد جُرّبت. وهو غالباً أول سؤال يطرحه عميل أو مدقق بعد حادث، وجواب «نستعيد كل أسبوع، وهذه هي التقارير» يحسم النقاش.
حل المشكلات
يفشل الاتصال بقاعدة على الخادم نفسه. خادم القاعدة يستمع على 127.0.0.1 فقط: أضف واجهة شبكة Docker إلى listen_addresses في PostgreSQL أو bind-address في MySQL، واسمح بشبكة Docker الفرعية في pg_hba.conf، ثم أعد تشغيل الخدمة.
تفشل نسخة نحو S3. تحقق من المنطقة واسم الحاوية وصلاحيات مفتاح الوصول: يجب أن يستطيع الكتابة والسرد وحذف الكائنات تحت البادئة المختارة، وإلا تعذّر على سياسة الاحتفاظ حذف النسخ القديمة.
لا يصل أي تنبيه. اختبر القناة من صفحة إعدادها؛ وللبريد يجب ضبط خادم SMTP في الإعدادات.
الواجهة لا تستجيب. اقرأ السجلات بالأمر docker compose logs --tail 100 databasus: تُسجَّل كل مهمة خلفية عند الإقلاع.
التثبيت بنقرة واحدة من متجر ServOrbit
يثبّت متجر ServOrbit تطبيق Databasus على خادمك دون سطر أوامر: ينشر الحاوية مع الوصول إلى host.docker.internal مُعرّفاً مسبقاً، وينشر المنفذ على الواجهة المحلية، ويعرض في لوحة العميل المنفذ الذي تستخدمه للنفق. ويمكنك أيضاً ربط نطاق للوصول الدائم عبر HTTPS.
