通过命令行还原备份

: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 反向代理的新服务器,该代理随后转发到上游的 discourse。因此,我在 discourse 中禁用了 SSL,但我注意到在恢复过程中:

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

这是在重新映射所有内部链接吗?是否可以通过 discourse remap http://example.com https://example.com 来撤销此操作?

不需要。

看起来是这样。是的,你可以重新映射它们。

你应该设置 force_https 变量。

1 个赞

如果备份是 15 GB,恢复需要多少空间?

1 个赞

是数据库还是上传文件也有?

可能要多 3-5 倍。

1 个赞

它是数据库+上传 15GB,我的 60GB 硬盘上有 20GB 空间,但每次还原都失败,我需要至少 50-60GB 的空间才能还原?

1 个赞

您需要足够的空间来存放备份、上传内容和未压缩的数据库。

您可以尝试先恢复仅包含数据库的备份,然后手动使用 rsync 复制上传内容。

2 个赞

我已经验证了我的管理员帐户在自托管上,并上传了 .sql.gz 备份,而不是 .tar.gz

在 UI 中恢复没有成功,所以我从命令行执行了“恢复备份”,在 discourse restore 过程结束时显示 [FAILED],官方托管的输入文件是 .tar.gz 是否会导致进程通过?

我的官方托管是几天前建立的,我的自托管在 更改 container.yml 中的 SMTP 值 后于今天开始正常工作。

1 个赞

您需要包含您收到的错误信息。文件名中包含版本信息,因此,如果您重命名了文件,则很可能需要将其重命名回原来的名称,只更改文件名开头的单词。

1 个赞

关于 discourse restore 是否有文档?因为似乎有 --location local 选项,我猜想也会有一个用于 S3 的选项?

我希望从存放在 S3 的备份中还原,避免事先手动下载。

编辑:算了,我刚刚发现 discourse restore --location s3 $filename 似乎可以正常工作。

2 个赞

因为我在app.yml中启用了S3,所以仅仅使用纯粹的discourse restore <filename>就能正常工作。

我认为如果你搜索backup restore s3,就能找到正确的帖子。

2 个赞

您好,我已完成此过程,使用了 s3(-cli) 作为我的 scp,并将发件邮件提供商从 MailGun 更改为 Brevo。

恢复后,我找不到移除横幅的方法?

移除横幅最简单的方法是在站点设置中启用电子邮件

3 个赞

对了。你也可以用 CSS 隐藏它!:joy:

1 个赞

是的。我有点犹豫推荐这个,因为我不得不考虑 Air theme hides "outgoing email disabled" warning

1 个赞

每次恢复备份时,非员工的电子邮件都会被自动禁用。 我猜想这是在恢复到测试服务器后,为了防止服务器向用户发送通知(这些用户本不该知道该服务器的存在),代码中添加的。

我已相应更新了 OP:

2 个赞

操作指南中的注意事项:

如果您定期为测试目的恢复备份,并且您的测试服务器配置正确,可以通过脚本启用电子邮件,以发送电子邮件到调试电子邮件服务(例如 https://github.com/maildev/maildev):

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

在这种情况下,您可能想要在您的 app.yml 中将 DISCOURSE_DISABLE_EMAILS 设置为 no。(同时也将 DISCOURSE_ENABLE_RESTORE 设置为以简化还原)

1 个赞