لا أحب جدول النسخ الاحتياطي الأكثر شيوعًا الذي يتم مرة واحدة فقط يوميًا. يبدو ذلك وكأنه قد يتسبب في ضياع الكثير من الكتابات الدقيقة التي يقوم بها الناس في حال حدوث كارثة. ومع ذلك، لا أريد إعداد مجموعة (cluster) مع التوفر العالي (HA)؛ فهذا يستهلك موارد أكثر مما يتطلبه استخدامي. كل ما أريده هو درجة عالية من الثقة في قدرتي على استعادة تقريبًا كل ما تم كتابته على Discourse الخاص بي، حتى لو استغرق الأمر بعض الوقت. هذا الموقع على Discourse مورد مجاني لمجتمع غير مدفوع، لذا أنا حساس للقيمة التي يضعها المجتمع فيه، وأيضًا حساس للتكاليف الإضافية. فترات التوقف مقبولة أكثر من فقدان البيانات.
في موقع Discourse واحد أساعد في إدارته، قمت بإعداد صور تُخدم محليًا (نقل الصور إلى S3 هو طريق ذو اتجاه واحد، كما اكتشفت بالطريقة الصعبة) تستخدم minio-client لبث التحميلات إلى S3 في الوقت الفعلي تقريبًا، باستخدام ميزة --watch. أفعل ذلك من المضيف (host). (هذا لا يعمل مع Digital Ocean Spaces، ومع ذلك؛ فقد اكتشفت بالطريقة الصعبة أن قيود Ceph تتسبب في فشل هذا.) يجعل هذا الاستعادة بسيطة، باستخدام minio-client لنسخ جميع الملفات مرة أخرى. أمر واحد فقط والكل يعود، حتى اللحظة الحالية، حتى لو كان نسخ قاعدة البيانات الاحتياطي قديمًا بحوالي يوم… أعجبني هذا النموذج حقًا.
يبدو لي أنه من الممكن فعل الشيء نفسه لـ أرشفة WAL التدفقية لقاعدة البيانات دون استخدام watch، بل باستخدام أمر archive_command يستدعي minio-client في كل مرة يتم فيها إكمال ملف WAL، فقط لذلك الملف. ومع ذلك، في هذه الحالة، يجب أن يعيش minio داخل الحاوية مع postgres، وليس على المضيف.
هذا جعلني أفكر…
في حين يمكنني استخدام exec: في ملفات yaml الخاصة بحاوياتي لإضافة minio-client وفعل كل هذا بنفسي، فما رأيكم هنا في أن يتضمن discourse/discourse_docker صورة/أساس/install-minio-client وقالبًا قياسيًا لوضع .mc/config.json، وإضافة ملف runit، والسماح بنسخ احتياطي واستعادة تدفقية سهلة نسبيًا بناءً على تكوين الحاوية؟ سيكون هذا بالطبع إعدادًا متقدمًا يأتي مع 
في التوثيق ولا يتم تفعيله افتراضيًا، ولكن بما أنني سأقوم على الأرجح بهذا العمل في مكان ما في وقت ما، فإن القيام به في discourse/discourse_docker سيجعله أكثر سهولة من مجرد تعديل ملف data.yml الخاص بي. التكلفة ستكون وجود minio-client في الصورة الأساسية، بحجم حوالي 21 ميجابايت؛ أي حوالي ضعف حجم ملف تنفيذ redis-server.
ليست وعدًا بالقيام بذلك، بل مجرد فضول لمعرفة ما إذا كان قد يتم قبوله في حال قمت فعليًا بالعمل. 
تعديل: بديل آخر هو وجود دليل منفصل لنسخ الملفات إليه، ثم استخدام أي أداة مثل minio-client خارج الحاوية لبث البيانات إلى الموقع البعيد، أو تركيب نظام ملفات بعيد مثل s3fs على الموقع الذي تُنسخ إليه الملفات. قد يكون هذا أبسط، وأكثر مرونة في التكوين، مع نفس النتيجة النهائية، ودون حمل minio-client في كل صورة من صور Discourse.