استعادة نسخة احتياطية من سطر الأوامر

:bookmark: This guide explains how to restore a Discourse backup from the command line without using the Discourse web UI.

:person_raising_hand: Required user level: Administrator

:wrench: Console access required

Here’s how to restore a Discourse backup from the command line, without ever booting the Discourse web UI. This is handy when you’re moving servers.

Prerequisites

Before you start, make sure you complete the following steps:

  1. Download the latest backup file from the source Discourse instance.
  2. Bootstrap the destination Discourse instance by running ./discourse-setup or copying your existing app.yml.
  3. Ensure the destination Discourse instance is on the latest version. Update it if necessary.

Transfer the backup

  1. SSH into the destination server, or otherwise create the backup folder there:

mkdir -p /var/discourse/shared/standalone/backups/default

  1. Upload your backup file to the destination server.

scp /path/to/backup/backup.tar.gz root@192.168.1.1:/var/discourse/shared/standalone/backups/default

Be sure to replace the paths, filenames, and server names with the ones you are using – but you do want the backup file to end up in:

/var/discourse/shared/standalone/backups/default

:mega: You can also upload and download your Discourse backup file from popular web storage sites such as Google Drive, Dropbox, OneDrive, etc – you’ll need to look up the specific command line instructions based on your preferred web storage provider.

:warning: DO NOT CHANGE THE FILENAME OF THE BACKUP! Discourse treats the backup filename as metadata, so if you change the filename, restoring will not work. Stick with the original file name.

Replace /path/to/backup/discourse-xyz.tar.gz with the local path of your backup file, and replace <server_ip_address> with the IP address of destination server.

:bulb: If Nginx is used as reverse proxy make sure all paths to the backup are readable by the container and Nginx can read the .sock file.

Restore the backup

  1. Access your destination server and navigate to the Discourse folder:
cd /var/discourse
  1. Enter the Discourse Docker app container:
./launcher enter app
  1. Enable restore functionality:
discourse enable_restore
  1. Restore the backup file:
discourse restore sitename-2019-02-03-042252-v20190130013015.tar.gz
  1. Exit the Discourse Docker app container:
exit

Rebuild

After restoring the backup, you may choose to rebuild the destination instance to ensure all settings and configurations are applied correctly.

:mega: Now is a good time to update /var/discourse/containers/app.yml with full HTTPS, additional plugins or CDN configuration. Compare the app.yml configuration of both instances to make sure!

cd /var/discourse
./launcher rebuild app

Enable Email

When a backup is restored, outgoing mail for non-staff is disabled. You don’t want your test server, new server, or server that you just restored a backup for some other reason to start emailing your users! Change site setting “disable_emails” to re-enable email.

:tada: That’s it. Your Discourse server is successfully restored.

Last edited by @pfaffman 2025-05-18T19:32:40Z

Check documentPerform check on document:
78 إعجابًا

نجحت هذه التعليمات في استعادة النسخة الاحتياطية لدينا، ولكن كان علينا تعديل أمر discourse restore إلى:

discourse restore --location local sitename-2019-02-03-042252-v20190130013015.tar.gz

(يستخدم مثالي اسم الملف من المثال أعلاه) للحصول على استعادة للعثور على النسخ الاحتياطية التي وضعناها في الدليل /var/discourse/shared/standalone/backups/default (على عكس النسخ الاحتياطية التي تم تخزينها على s3).

إعجابَين (2)

هل إعادة البناء بعد الاستعادة ضرورية؟

أيضًا، لقد استعدت إلى خادم جديد حيث يوجد وكيل عكسي لـ NGINX ثم يمرر إلى خادم ديسكورس. لذلك قمت بتعطيل SSL على ديسكورس، لكنني لاحظت أثناء الاستعادة:

إعادة تعيين 'https://example.com' إلى 'http://example.com'

هل تعيد هذه العملية تعيين جميع الروابط الداخلية؟ وهل التراجع عن هذا بسيط مثل discourse remap http://example.com https://example.com؟

لا.

يبدو كذلك. نعم، يمكنك إعادة تعيينها.

يجب عليك تعيين متغير force_https.

إعجاب واحد (1)

إذا كان النسخ الاحتياطي بحجم 15 جيجابايت، فما هي المساحة المطلوبة للاستعادة؟

إعجاب واحد (1)

هل هذه قاعدة البيانات فقط أم التحميلات أيضاً؟

من المحتمل أن يكون ذلك 3-5 أضعاف هذا القدر.

إعجاب واحد (1)

إنها قاعدة بيانات + تحميل 15 جيجابايت، لدي مساحة 20 جيجابايت على قرص صلب بسعة 60 جيجابايت ولكن الاستعادة تفشل في كل مرة، هل أحتاج إلى مساحة 50-60 جيجابايت على الأقل للاستعادة؟

إعجاب واحد (1)

تحتاج إلى مساحة كافية للنسخ الاحتياطي، والتحميلات، وقاعدة البيانات غير المضغوطة.

قد تحاول استعادة نسخة احتياطية لقاعدة البيانات فقط أولاً ثم نسخ التحميلات يدويًا باستخدام rsync.

إعجابَين (2)

لقد قمت بالتحقق من حساب المسؤول الخاص بي على الاستضافة الذاتية، وقمت بتحميل نسخة احتياطية بصيغة .sql.gz، وليس .tar.gz.

استعادة النسخة الاحتياطية من خلال واجهة المستخدم ليست مجدية، لذلك قمت بإجرائها من “استعادة النسخة الاحتياطية” من سطر الأوامر، وظهرت رسالة [FAILED] في نهاية عملية discourse restore. هل يمكن أن يكون الملف المدخل من استضافة رسمية بصيغة .tar.gz هو سبب فشل العملية؟

استضافة الرسمية الخاصة بي عمرها بضعة أيام، واستضافتي الذاتية بدأت تعمل بشكل صحيح اليوم بعد تغيير قيم SMTP في container.yml.

إعجاب واحد (1)

ستحتاج إلى تضمين الخطأ الذي تلقيته. يحتوي اسم الملف على معلومات الإصدار فيه، لذا إذا قمت بإعادة تسمية الملف، فمن المحتمل أن تحتاج إلى تسميته مرة أخرى، مع تغيير الكلمات في بداية اسم الملف فقط.

إعجاب واحد (1)

هل هناك وثائق لـ discourse restore في مكان ما؟ حيث يبدو أن هناك نفسر خيار --location local، أفترض أنه سيكون هناك أيضًا واحد لـ S3؟

أنا أبحث عن استعادة النسخ الاحتياطية المخزنة على S3 وتجنب الحاجة لتنزيلها يدويًا مسبقًا.

تعديل: لا يهم. لقد اكتشفت أن الأمر discourse restore --location s3 $filename يبدو أنه يعمل بشكل جيد.

إعجابَين (2)

لأنني قمت بتمكين S3 في ملف app.yml، عمل الأمر discourse restore <اسم الملف> بشكل جيد فقط.

أعتقد أنه إذا بحثت عن backup restore s3 فستجد المنشور الصحيح.

إعجابَين (2)

مرحباً، لقد أكملت هذه العملية باستخدام s3(-cli) كـ scp الخاص بي وتغيير في مزود البريد الصادر من MailGun إلى Brevo

منذ الاستعادة، لم أتمكن من العثور على طريقة لإزالة اللافتة؟

أسهل طريقة لإزالة الشعار هي تمكين رسائل البريد الإلكتروني في إعدادات الموقع

3 إعجابات

صحيح. يمكنك أيضًا إخفاؤها باستخدام CSS! :joy:

إعجاب واحد (1)

صحيح. كنت حذرًا بعض الشيء في التوصية بهذا لأنني اضطررت للتفكير في Air theme hides "outgoing email disabled" warning

إعجاب واحد (1)

في كل مرة تقوم فيها باستعادة نسخة احتياطية، يتم تعطيل البريد الإلكتروني تلقائيًا للموظفين غير الرسميين. أتخيل أنه تم إضافة هذا إلى التعليمات البرمجية عدة مرات بعد إجراء استعادة إلى خادم اختبار بدأ في إغراق مستخدميه بالإشعارات لخادم لم يكن من المفترض أن يعرفوا بوجوده.

لقد قمت بتحديث OP وفقًا لذلك:

إعجابَين (2)

ملاحظة للدليل الإرشادي:

إذا كنت تقوم باستعادة النسخ الاحتياطية بانتظام لأغراض الاختبار وكان خادم الاختبار الخاص بك مُعدًا بشكل صحيح لإرسال رسائل البريد الإلكتروني إلى خدمة بريد إلكتروني تصحيحية (مثل GitHub - maildev/maildev: 📫 SMTP Server + Web Interface for viewing and testing emails during development.)، فقد ترغب في تمكين رسائل البريد الإلكتروني عبر البرمجة النصية:

docker exec -it app /bin/bash --login \
-c "rails runner 'SiteSetting.disable_emails=\"no\";'"

في هذه الحالة، قد ترغب في تعيين DISCOURSE_DISABLE_EMAILS إلى لا في ملف app.yml الخاص بك. (وأيضًا DISCOURSE_ENABLE_RESTORE لتسهيل عملية الاستعادة)

إعجاب واحد (1)