لدينا النسخ الاحتياطي التلقائي مُعد. على حد علمي، تعمل دون مشكلة، ولكننا نرغب في مراقبتها باستخدام خدمة بسيطة، مثل https://healthchecks.io، للتأكد.
هل هناك أي طريقة لتكوين استدعاء بسيط لواجهة برمجة التطبيقات الخاصة بهم للتأكد من اكتمال النسخ الاحتياطي؟ شيء مثل هذا:
curl -m 10 --retry 5 https://hc-ping.com/your-uuid-here
أتساءل عما إذا كانت هناك خطافات (hooks) قبل النسخ الاحتياطي و/أو بعد اكتمال النسخ الاحتياطي يمكنني ربط هذا بها؟
شكرًا
يمكنك هندسة واجهة برمجة تطبيقات Discourse العكسية للحصول على قائمة بالنسخ الاحتياطية، وبعد ذلك ستحتاج إلى القيام بشيء ما لمعرفة الأحدث منها ومدة وجودها.\n\nستتلقى إشعارًا إذا فشل النسخ الاحتياطي.\n\nالمشكلة الوحيدة التي واجهتها كانت عندما تم جدولة النسخ الاحتياطية في نفس وقت إعادة تشغيل أنظمة التسويق الآلية المخصصة.
كما أرى هذا، فإنه يعمل عندما يكون هناك جدول نسخ احتياطي خلف الكواليس لقاعدة البيانات (لأن مرة واحدة في اليوم ليست كافية، أليس كذلك؟) ثم يتأخر نظام التحذير المدمج، بحد أقصى 24 ساعة. لكنه سيعمل كنظام إنذار مبكر إذا تعطل Discourse بسبب فشل قاعدة البيانات، ولكن بسبب التخزين المؤقت لا يراه المستخدمون على الفور.
هل أنا مخطئ تمامًا؟ لست قريبًا حتى؟
شكرًا. إذا لم تكن هناك طريقة لتعيين “خطاف” بعد اكتمال النسخ الاحتياطي، فأعتقد أن فكرة الهندسة العكسية لواجهة برمجة تطبيقات Discourse للعثور على أحدث نسخة احتياطية هي الطريقة الأنسب، وبعد ذلك سيكون لدينا تحكم كامل فيما يجب فعله إذا فشل النسخ الاحتياطي… ولكن إذا كان من الممكن إضافة خطاف (أمر ويب أو أمر shell) بعد النسخ الاحتياطي، فسيكون ذلك مثاليًا.
شكرًا لمساعدتك 
إذا كنت ترغب في استدعاء خطاف بعد اكتمال النسخ الاحتياطي، أعتقد أنك ستحتاج إلى إنشاء إضافة.
هل تقترح حقًا أن النسخ الاحتياطي الفاشل هو الطريقة التي تريد أن تعرف بها أن Discourse معطل؟
/srv/status يمنحك فكرة جيدة جدًا، على الرغم من أن Discourse يمكن أن يتعطل بطرق لا تنعكس في ذلك. سيشير إلى ما إذا كانت قاعدة البيانات معطلة.
أنا لا أقترح أي شيء آخر سوى عمل نسخة احتياطية من قاعدة البيانات بشكل متكرر أكثر من مرة واحدة في اليوم. كنت أفكر فقط في إرسال بريد إلكتروني بسبب خطأ في النسخ الاحتياطي ليكون بمثابة جرس إنذار أيضًا.
لا، لا يفعل. يقول “ok” طالما لديك rails و Redis و nginx.
root@testbeta:~# service postgresql stop
root@testbeta:~# curl https://testbeta.*************.***/srv/status & && echo
ok
مثير للاهتمام. ربما إذا كان PostgreSQL معطلاً عند بدء تشغيل Rails، فسيفشل في البدء.