لدي موقع يقوم بنسخ احتياطي بحجم 20 جيجابايت إلى Wasabi S3. يعمل الأمر. في معظم الأوقات.
ولكن في بعض الأحيان يفشل الرفع إلى S3 ويحتفظ بملف .tar.gz المحلي. ثم يمتلئ القرص في النهاية، وأصبح أمامي قرص ممتلئ، وملف .tar غير مضغوط (لأنه لم يكن هناك مساحة كافية للنسخة المضغوطة)، وسرعان ما يتعطل الموقع بسبب امتلاء القرص.
قبل أن أتخلى عن Wasabi، أود أن أحاول معرفة ما إذا كانت هناك أي أدلة.
لقد تفحصت ملفات production.log و production.errors وسجلات sidekiq و unicorn ولم أجد كلمة “acku” في أي مكان، سواء في اليوم الذي فشل فيه النسخ الاحتياطي أو في اليوم الذي نجح فيه. ألا يجب أن يكون هناك سجل في مكان ما؟
يجب أن تتلقى رسالة خاصة (PM) تحتوي على مخرجات السجل إذا فشل الأمر. تُرسل هذه الرسالة مباشرة إليك إذا كانت نسخة احتياطية يدوية من خلال واجهة المستخدم، أو إلى مجموعة المشرفين إذا كانت نسخة احتياطية تلقائية.
كما يجب أن تظهر أي استثناء يحدث أثناء عملية النسخ الاحتياطي في /logs، وأعتقد أنها تظهر أيضًا في أحد ملفات السجل. حاول البحث عن EXCEPTION:
لكن، حقيقة أن النظام يحتفظ بالملفات المؤقتة تدفعني للتساؤل عما إذا كان Sidekiq أو حتى Docker أو المضيف قد أعيد تشغيله أثناء النسخ الاحتياطي. وهذا قد يفسر سبب عدم تنفيذ عملية التنظيف وسبب عدم تلقيك لرسالة خاصة (PM).
صحيح. هذا غريب جداً. لم أتلق إشعار فشل، حتى في الحالة التي كان فيها هناك ملف .tar واحد فقط وقرص شبه ممتلئ (إنه موقع محدث على tests-passed).
كأن backup location قد تغيرت في تلك الأيام فقط، لكن لا يوجد شيء في السجلات. أرى إشعارات “ناجحة” في رسائل المسؤول للنسخ الاحتياطي الذي تم بدؤه من واجهة الويب، لكن لا توجد إشعارات فشل. لقد نقلت backup_location إلى إعداد متغير بيئة (ENV).