في الشهر الماضي، قمنا بإجراء عدد لا يحصى من اختبارات الترحيل في سيناريوهات مختلفة وحاويات Docker. بالإضافة إلى ذلك، قمت بإجراء المزيد من عمليات استعادة قاعدة بيانات Discourse من خادم إلى آخر.
بناءً على اختبارات الاستعادة الشاملة، تُعد عملية استعادة Discourse رائعة وقد عملت بشكل مثالي في كل حالة من سطر الأوامر.
على سبيل المثال، نستخدم سكريبتًا بدائيًا جدًا لهذا الغرض، والذي أحفظه في الدليل /shared/neo/bin:
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community-2020-03-27-033157-v20200320193612.tar.gz
echo "discourse disable_restore"
discourse disable_restore
بالطبع، هذا السكريبت البسيط في Bash ليس ضروريًا ولا أنيقًا؛ لكن سكريبتًا صغيرًا مثل هذا يجعل الأمر سهلًا وسريعًا حقًا عندما تكون مشغولًا وتريد فقط نسخ أحدث نسخة احتياطية ولصقها في السكريبت وإجراء الاستعادة.
بالنسبة لي، أقوم دائمًا بالاستعادة من سطر الأوامر (في التطبيق، وفي Docker، بالطبع)، ولم تفشل عملية استعادة Discourse أبدًا بعد العديد من سيناريوهات الاختبار. فقط قم بإنشاء تثبيت جديد لـ Discourse على Docker واستعد من سطر الأوامر، و"بوم"، يكون الأمر قد انتهى.
إذا قارنا هذا بـ “أيام الديناصورات الماضية”، قبل Docker، فإن روعة عملية استعادة Discourse في Docker تجعل عملية الاستعادة أسهل وأسرع بكثير.
على سبيل المثال، نقوم أيضًا بنسخ نسخنا الاحتياطية من Discourse إلى موقع خارجي (إلى خادم مختلف عن مثيل Discourse الإنتاجي)، وإذا انفجر هذا الخادم الإنتاجي أو مركز البيانات في كارثة، فيمكننا إعادة بناء مثيل Discourse من الصفر، على أي خادم نختاره، والاستعادة بسهولة (بالطبع نحتاج إلى الحفاظ على قيم TTL الخاصة بـ DNS قصيرة، لكن هذا موضوع مختلف).
تهانينا لفريق Discourse على عملية النسخ الاحتياطي والاستعادة المصممة بعناية وممتازة!
تعمل ببراعة، مرارًا وتكرارًا، دون أي عيوب.