Restore a backup from the command line

[Discourse]

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

Required user level: Administrator

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

2. 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

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.

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.

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

2. Enter the Discourse Docker app container:

./launcher enter app

3. Enable restore functionality:

discourse enable_restore

4. Restore the backup file:

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

Tip: If you run discourse restore without a filename, it will list all available backup files.

If your site’s backup_location setting is configured to use S3, but you manually uploaded the backup file to the local filesystem, you need to specify --location local:

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

Similarly, use --location s3 to restore directly from an S3 backup without downloading it first.

5. 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.

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 the disable_emails site setting to “no” to re-enable email.

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

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

Check document

Perform check on document:

[gregcaporaso]

Эти инструкции помогли нам восстановить систему из резервной копии, но нам пришлось изменить команду discourse restore на:

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

(в моём примере используется имя файла из приведённого выше примера), чтобы восстановление нашло резервные копии, которые мы разместили в директории /var/discourse/shared/standalone/backups/default (в отличие от резервных копий, хранящихся в S3).

[Isambard]

Необходима ли пересборка после восстановления?

Также я восстановил систему на новый сервер, где стоит обратный прокси NGINX, который затем пересылает запросы к upstream-серверу Discourse. Поэтому я отключил SSL на Discourse, но заметил, что во время восстановления:

Remapping 'https://example.com' to 'http://example.com'

Эта перенастройка затрагивает все внутренние ссылки? Можно ли отменить это так же просто, как выполнив discourse remap http://example.com https://example.com?

[pfaffman (Jay Pfaffman)]

@Isambard

Необходима ли пересборка после восстановления?

Нет.

@Isambard

Переназначает ли это все внутренние ссылки?

Похоже, что да. Да, вы можете их переназначить.

Вы должны установить переменную force_https.

[pinder99 (Raza shield)]

Если размер резервной копии составляет 15 ГБ, сколько места потребуется для восстановления?

[pfaffman (Jay Pfaffman)]

Это только база данных или тоже загрузок?

Наверное, в 3–5 раз больше.

[pinder99 (Raza shield)]

Это база данных плюс загрузка 15 ГБ. У меня есть 20 ГБ свободного места на жестком диске объемом 60 ГБ, но восстановление каждый раз не удаётся. Мне нужно хотя бы 50–60 ГБ свободного места для восстановления?

[pfaffman (Jay Pfaffman)]

Вам нужно достаточно места для резервной копии, загрузок и распакованной базы данных.

Сначала попробуйте восстановить только резервную копию базы данных, а затем скопируйте загрузки вручную с помощью rsync.

[Ethsim2 (Ethan)]

Я подтвердил свою учетную запись администратора на собственном хостинге и загрузил резервную копию в формате .sql.gz, а не .tar.gz.

Восстановление через интерфейс не дало результата, поэтому я выполнил его через командную строку с помощью команды «Restore the backup». В конце процесса discourse restore появилось сообщение [FAILED]. Возможно ли, что процесс завершился бы успешно, если бы входной файл с официального хостинга был в формате .tar.gz?

Мой официальный хостинг существует всего несколько дней, а мой собственный сервер начал корректно работать сегодня после изменения значений SMTP в файле container.yml.

[pfaffman (Jay Pfaffman)]

Вам нужно указать, какая именно ошибка возникла. Однако в имени файла содержится информация о версии, поэтому, если вы переименовали файл, вам, скорее всего, придется вернуть ему прежнее имя, изменив только слова в начале названия файла.

[helmi]

Где-то есть документация для discourse restore? Так как, похоже, есть переключатель --location local, я предполагаю, что должен быть и аналогичный для S3.

Я ищу возможность восстановления из резервных копий, размещенных в S3, без необходимости предварительно скачивать их вручную.

РЕДАКТИРОВАНИЕ: Неважно. Я только что выяснил, что discourse restore --location s3 $filename работает отлично.

[Jagster (Jakke Flemming)]

Поскольку я включил S3 в app.yml, простая команда discourse restore <filename> сработала без проблем.

Думаю, если вы поищете backup restore s3, то найдёте нужный пост.

[Ethsim2 (Ethan)]

Привет! Я завершил этот процесс, используя s3(-cli) в качестве scp и сменив провайдера исходящей почты с MailGun на Brevo.

После восстановления я не могу найти способ убрать баннер?

[Moin]

@Discourse

Процесс восстановления автоматически устанавливает настройку «Отключить электронную почту» в значение «не для сотрудников», поэтому письма не отправляются пользователям вашего сайта, пока вы не будете готовы.

Самый простой способ убрать баннер — включить отправку электронной почты в настройках сайта

[pfaffman (Jay Pfaffman)]

@Moin

Самый простой способ убрать баннер — включить электронную почту в настройках сайта.

Верно. Также можно скрыть его с помощью CSS!

[Moin]

Верно. Я был немного осторожен, рекомендуя это, потому что мне нужно было подумать о Air theme hides "outgoing email disabled" warning

[pfaffman (Jay Pfaffman)]

@Moin

Я немного опасался рекомендовать это, так как мне пришлось подумать о теме Air, скрывающей предупреждение «исходящая почта отключена»

При каждом восстановлении резервной копии исходящая почта для пользователей, не являющихся сотрудниками, автоматически отключается. Я полагаю, это было добавлено в код всего пару раз после того, как резервная копия была восстановлена на тестовом сервере, который начал заваливать своих пользователей уведомлениями о сервере, о существовании которого они не должны были знать.

Я обновил исходный пост соответственно:

@Discourse

Включение электронной почты

При восстановлении резервной копии исходящая почта для пользователей, не являющихся сотрудниками, отключается. Вы не хотите, чтобы ваш тестовый сервер, новый сервер или сервер, для которого вы только что восстановили резервную копию по какой-то другой причине, начал рассылать письма вашим пользователям! Измените настройку сайта «disable_emails», чтобы снова включить электронную почту.

[thoka (Thomas Kalka)]

Примечание к инструкции:

Если вы регулярно восстанавливаете резервные копии для тестирования и ваш тестовый сервер правильно настроен, чтобы отправлять письма в отладочный почтовый сервис (например, GitHub - maildev/maildev: 📫 SMTP Server + Web Interface for viewing and testing emails during development. · GitHub), вам может потребоваться включить отправку писем через скрипт:

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

[pfaffman (Jay Pfaffman)]

В этом случае, возможно, стоит установить DISCOURSE_DISABLE_EMAILS в значение no в файле app.yml (а также DISCOURSE_ENABLE_RESTORE, чтобы упростить восстановление).