إذا كنت تستضيف النظام بنفسك، فيجب أن تحتفظ بنسخ احتياطية خارج الموقع في حال حدوث مشكلة كارثية في الخادم الخاص بك. تخيل أن <موفر الخادم الخاص بك> أفلست يومًا ما دون أي تحذير، أو أنك تمكنت بطريقة ما من حذف /var/discourse، مما يمحو تثبيتك بالكامل.
الحد الأدنى المطلوب
تأكد من تفعيل النسخ الاحتياطي.
إعدادات الموقع التي يُنظر فيها:
enable backups: تشغيل (افتراضي: تشغيل)backup frequency: كم من البيانات أنت مستعد لخسارتها؟ (افتراضي: 7 أيام). يُوصي @pfaffman بيوم واحدbackup time of day: متى تريد أن يكون المنتدى في وضع “للقراءة فقط” أثناء أخذ النسخة الاحتياطية؟backup with uploads: تشغيل ما لم تكن تخزن الملفات المرفقة في مكان آخر أو تقوم بنسخها احتياطيًا بطريقة أخرى. (افتراضي: تشغيل)maxiumum backups: إلى أي مدى أنت متشكك؟ كم من مساحة القرص لديك؟ (افتراضي: 5)
هذا سيتيح لك الاستعادة من نسخة احتياطية حديثة في حال تلف قاعدة بياناتك بطريقة ما، لكنه لن يحميك إذا اختفى خادم Discourse الخاص بك.
النسخ الاحتياطي عن بُعد
لاستعادة موقعك على خادم جديد، فأنت بحاجة على الأقل إلى النسخة الاحتياطية التي ينشئها Discourse. سيكون إعداد خادم جديد أسهل بكثير إذا كان لديك الحاويات (containers) في /var/discourse//containers.
كيفية الاحتفاظ بنسخ احتياطية خارج الموقع بالضبط تتجاوز إلى حد ما نطاق هذا المستند، لكن إحدى الطرق هي استخدام أداة مثل rsync لنسخ البيانات إلى خادم بعيد. توجد عشرات الأدلة للقيام بذلك؛ ابحث عن دليل يبدو منطقيًا بالنسبة لك.
تتغير ملفات /var/discourse/containers نادرًا، لذا فإن نسخها احتياطيًا يدويًا فقط عند إجراء تغييرات ليس أمرًا مرهقًا. تحتوي عادةً على إعدادات SMTP والإضافات الخاصة بك، والتي يمكن إعادة بنائها بسهولة نسبيًا من الذاكرة، لكنك تفضل عدم القيام بذلك في حالة الطوارئ. إذا حدث ذلك، يمكنك استئناف العمل مع فقدان بعض الإضافات وتعطل البريد، ثم استكمال الباقي بينما يعمل الموقع بشكل محدود.
النسخ الاحتياطي إلى S3
الطريقة الأكثر ملاءمة للاحتفاظ بنسخ احتياطية خارج الموقع هي دفعها إلى S3 كما هو موضح في Set up file and image uploads to S3. إذا قمت بذلك واحتفظت بإعدادات S3 الخاصة بك في مكان يمكنك العثور عليه (أو في ملف app.yml الخاص بتطبيقك)، فيمكنك استعادة موقعك مباشرة من S3 عند إعداد الخادم الجديد.
من الممكن تضمين الإعدادات في ملف app.yml الخاص بك. إذا قمت بتضمين شيء مثل هذا في قسم env من ملف app.yml، فستختفي هذه الإعدادات من واجهة الويب، وستتمكن من Restore a backup from the command line دون الحاجة إلى إنشاء حساب مسؤول وتسجيل الدخول.
DISCOURSE_S3_ACCESS_KEY_ID: 'key'
DISCOURSE_S3_SECRET_ACCESS_KEY: 'secret'
DISCOURSE_BACKUP_LOCATION: 's3'
DISCOURSE_ENABLE_S3_UPLOADS: true
DISCOURSE_S3_BACKUP_BUCKET: 'my-backup-bucket'
DISCOURSE_S3_REGION: 'us-west-1'
إذا كان لديك أيضًا ملفات مرفقة في S3 وتثق في استقرار موفر خدمة S3، فيمكنك جعل Discourse ينسخ احتياطيًا لقاعدة البيانات فقط (انظر الإعداد أعلاه). هذا سيمنعك من تخزين نسخ متعددة من جميع الملفات المرفقة. إذا اخترت هذا المسار، فيجب عليك إجراء استعادة تجريبية للتأكد من أن جميع ملفاتك المرفقة موجودة بالفعل في S3.
الممارسة تصنع الكمال
في حين أن امتلاك نسخة من أحدث نسخة احتياطية فقط هو الحد الأدنى الذي ستحتاجه للاستعادة في حالة الأزمات، فإنك إذا كنت تريد أن تكون متيقنًا حقًا من أن نسخك الاحتياطية تعمل، فيجب أن تختبرها مرة واحدة على الأقل، إن لم يكن بشكل دوري. قم بتشغيل خادم جديد جديد وراجع ما إذا كان بإمكانك الاستعادة من نسخة احتياطية.