أليس مجرد نسخة احتياطية واحدة في اليوم محفوفًا بالمخاطر؟ إذا حدث شيء للخادم وحدثت النسخة الاحتياطية الأخيرة بالأمس، فماذا أفعل؟ المستخدمون المسجلون بين الأمس واليوم، هل لم يعودوا مسجلين؟ أعتقد أنه من الأفضل جعل النسخ الاحتياطية أكثر تكرارًا، ربما كل ساعة. ولكن في هذه الحالة، هل يجب عليك وضع الموقع في وضع القراءة فقط قبل إجراء نسخة احتياطية؟ شكرًا مقدمًا!
3 إعجابات
+1 لهذا، مرة أخرى. Discourse هو النظام الديناميكي الوحيد الذي يمكن للمرء من خلاله أتمتة النسخ الاحتياطي لقاعدة البيانات مرة واحدة فقط في اليوم.
لا أتوقع أن يتغير هذا في النواة في أي وقت قريب. لقد أجريت محادثات حول تغيير الإعداد الافتراضي إلى أكثر من مرة واحدة في الأسبوع وهذا لن يحدث.
أعتقد أن ما قد يكون جيدًا هو إضافة مكون إضافي يضيف إعدادًا للموقع لإجراء نسخ احتياطي لقاعدة البيانات فقط خلال عدد معين من الساعات (لا يوجد سبب للاحتفاظ بالكثير من النسخ غير القابلة للضغط للملفات التي تم تحميلها في كل تلك النسخ الاحتياطية الكاملة). إذا كنت مهتمًا، أرسل لي رسالة خاصة أو اسأل في السوق.
إعجابَين (2)
إذا كنت بحاجة إلى استعادة أفضل للكوارث، فإنني أوصي باتباع تشغيل Discourse مع خادم PostgreSQL منفصل وتشغيل PostgreSQL بنفسك حيث يمكنك التحكم في التوفر العالي الدقيق الذي تحتاجه، مثل النسخ المتماثلة المتزامنة المباشرة، والاستعادة في نقطة زمنية، والنسخ الاحتياطي الأكثر تكرارًا.
3 إعجابات
هل يمكنني معرفة سبب هذه السياسة، هل هي تقنية أم ترجع إلى الرغبة في فئة معينة؟ الفجوة البالغة 24 ساعة بين النسخ الاحتياطي تمثل مشكلة حرجة جدًا في المنتديات ذات حركة المرور العالية. أم أن هذا شيء تقدمونه فقط للعملاء الذين يدفعون؟
إعجاب واحد (1)
هل يؤدي تشغيل Discourse مع خادم PostgreSQL منفصل إلى تقليل السرعة بسبب وجوده على خادم مختلف؟
إعجاب واحد (1)
بالتأكيد، هذا أحد الحلول. حل نادر جدًا بين التطبيقات، مع ذلك. في عالم PHP/MySQL، سيكون عمل نسخة احتياطية من قاعدة البيانات باستخدام cron سهلاً للغاية، ولكن مرة أخرى - في هذا العالم يمكن لكل تطبيق القيام بذلك بنفسه، مع أو بدون أي إضافة.
نعم، أنا أكثر بقليل من مجرد مستخدم عادي 
ولكن لدي فهم ضئيل جدًا لكيفية عمل docker و rails وما إلى ذلك، وبالنسبة لي فإن الوضع الذي تكون فيه المهام الشائعة شبه مستحيلة أمر صعب الفهم حقًا. بالتأكيد، ربما يكون ذلك بسبب قيودي، ولكني لست الوحيد الذي يتساءل عن هذا، مع ذلك.
حسنًا. لن نحصل على نسخ احتياطية لقاعدة البيانات بسهولة في المستقبل القريب أو المتوسط، لقد فهمت ذلك.
إعجاب واحد (1)
يمكنك إعداد نسخ PostgreSQL احتياطيًا باستخدام cron أيضًا. لا يوجد شيء مختلف هنا.
ليس بأي طريقة ذات صلة. كل مثيل Discourse نستضيفه، مثل هذا المثيل هنا، يستخدم قاعدة بيانات على خادم مخصص.
إعجابَين (2)
أنا أسألك سؤالين فقط لفهم أفضل.
- هل قاعدة البيانات هي الشيء الوحيد الذي تحتاجه لاستعادة كل شيء؟ هل النسخة الاحتياطية التي تتم يوميًا من خلال الإعدادات، هل هي نسخة احتياطية لقاعدة البيانات فقط؟
- هل يجب أن يكون المنتدى في وضع القراءة فقط عند عمل نسخة احتياطية لقاعدة البيانات؟ أم يمكن القيام بذلك دون أي مشكلة، في أي وقت؟
شكراً جزيلاً مقدماً!
إعجابَين (2)
الإعدادات موجودة في قاعدة البيانات.
من الناحية الفنية، تريد أيضًا عمل نسخة احتياطية من مجلد التحميلات وتعريف موقع app.yml. ومع ذلك، يتم التعامل مع ذلك عادةً عن طريق وجود app.yml في التحكم بالمصادر والتحميلات في خدمة تخزين الكائنات.
لا حاجة لوضع القراءة فقط.
4 إعجابات
إذن بافتراض أن لدي قاعدة البيانات على خادم منفصل وأقوم بعمل نسخ احتياطية لتلك القاعدة كل ساعة. إذا قمت أيضًا بعمل نسخة احتياطية، من الإعدادات في لوحة المسؤول، فقط الملفات بما في ذلك ملف app.yml ومجلد uploads سيتم تضمينها في النسخة الاحتياطية، ولكن ليس قاعدة البيانات، صحيح؟ @Falco
إعجاب واحد (1)
سيشمل النسخ الاحتياطي قاعدة البيانات وملفات التحميل (إذا لم تكن على S3). لا يتم تضمين ملف app.yml في النسخ الاحتياطي، حيث لا يمكن لـ Discourse قراءته.
ما أوصي به لمعظم الأشخاص هو الاحتفاظ بالنسخ الاحتياطية على S3 وملف app.yml في مكان يمكنك الوصول إليه في حالة الطوارئ. بعد ذلك، يمكنك إنشاء حاوية جديدة باستخدام ملف app.yml واستعادتها من سطر الأوامر. ولكن إذا كانت لديك المهارات التقنية لعمل نسخة احتياطية/استعادة postgres باستخدام أداة أخرى، والصور على S3 (أو ربما لديك نسخ احتياطية منها بطريقة أخرى أيضًا)، فيمكنك ببساطة إعادة بناء الحاوية وستعود للعمل.
أو ربما ترغب في الحصول على خوادم postgres متعددة متطابقة باستمرار ثم ترتيب التبديل تلقائيًا إلى النسخة الاحتياطية إذا تعطل الخادم الأساسي.
هناك عدد لا يحصى من الطرق لتوفير نسخ احتياطية أكثر تكرارًا مما توفره Discourse. إذا كنت بحاجة إلى نسخ احتياطية أكثر تكرارًا، فستحتاج إلى القيام بها بطريقة أخرى.
إعجابَين (2)
نقطة أخرى هنا هي المخاطر والصيانة: إذا استخدمت الحل اليومي الجاهز، فمن المحتمل أن يكون أكثر قوة وموثوقية كحل احتياطي مما لو قمت بتكوين حلك الخاص. ماذا لو حدث خطأ ما في حلك الخاص واكتشفت ذلك في وقت متأخر جدًا؟ على الأقل مع الحل القياسي لديك مئات المواقع تختبره يوميًا.
نظرًا لأنني لم أواجه أي تجربة تلف عبر عدة مواقع في 4 سنوات، فإن خطر الحاجة فعليًا إلى النسخ الاحتياطي في المقام الأول هو أيضًا منخفض …
ربما يمكن للآخرين ذكر مخاطر أكبر، ولكن ربما تكون أكبر المخاطر هي المشاكل بسبب امتلاء الخادم؟ لذا راقب المساحة؟ قم بإعداد تنبيه؟
3 إعجابات
إذًا، حسب فهمي، فإن أفضل طريقة هي الاحتفاظ بكل شيء بشكل منفصل.
خادم رئيسي لتشغيل Discourse. ثم خادم لـ PostgreSQL و S3 (أو أي خدمة تخزين كائنات أخرى) للملفات.
يبدو لي أن ملف app.yml لا يتغير كثيرًا، لذا تحتاج فقط إلى حفظه مرة واحدة. أو على الأكثر بضع مرات خلال الشهر.
هذا يسمح لك بعمل نسخ احتياطية لملفاتك، حتى بطريقة أكثر تنظيمًا.
إذا كان الأمر كذلك، أجد أن اختيارهم لعدم تنفيذ نسخ احتياطية متعددة يوميًا في النواة منطقي. من ناحية أخرى، فإن أولئك الذين لديهم احتياجات معقدة سيقومون بالتأكيد بتكوينات معينة مثل ذلك. وفي النهاية، تحتاج فقط إلى إعادة تثبيت (مع حفظ app.yml في مكان ما) ثم إعادة توصيله بقاعدة البيانات و S3 لتحميل البيانات. النسخ الاحتياطية موجودة في هذين الخادمين بشكل منفصل، لذا من السهل إدارتها بالنسبة لي. أجد أنها حل عادل جدًا.
شكرًا للجميع على الشرح.
3 إعجابات
يوجد موضوع آخر هنا: Configure automatic backups for Discourse - #113 by Tris20
قدم @pfaffman بعض التوصيات هناك مع روابط. هذا قادني إلى سطر الأوامر كوسيلة لجدولة نسخ احتياطية أكثر تكرارًا، وهو ما يعتبر حلاً معقولًا جدًا بالنسبة لي:
لاحظ أنه مع هذا الحل، يمكنك دمج كل شيء في نص برمجي بايثون لجدولة نسخة من ملف yaml وما إلى ذلك في نفس الوقت.
إعجابَين (2)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.