Is there any way to restore your site from backup in the terminal?

支持
1

I did a backup of my site before I upgraded to the latest version of the discourse however I can’t even access my site any more even though the upgrade appears to be successful as no error is displayed. Is there anyway that I can restore my site from the backup that I created earlier from terminal app as I can’t access the site?

  1. Is it possible?

  2. If yes, where do discourse save or store the backups that I executed from the admin panel?

  3. Is there any guide on how to restore the site from backup?

Thanks

2 个赞
2

Yes.

They’re stored in public/backups/default/.

Just run the following command (in the discourse directory)

script/discourse restore <filename.of.the.backup.tar.gz>
19 个赞
3

Thank you. :slight_smile:

7

This seems like a handy thing to be able to do since if you screw up configuring SSO you can’t get back into your site. I spent a week one day trying to get SSO configured, and now that it is configured correctly it seems that my account on the SSO (which I don’t control) is gone, so I can’t get in.

So, script/discourse restore fails because thor isn’t installed.

gem install thor fixes that, but then I’m still denied because:

URGENT: FATAL:  Peer authentication failed for user "discourse"

Solving my immediate problem, I suppose I could turn off SSO from the Rails console. . .

edit: to disable SSO from the rails console:

cd /var/discourse
./launcher enter app
rails c
SiteSetting.enable_sso=false
exit
exit
2 个赞
8

There’s a way to log in: Visit /users/admin-login, which can be used to log in via email :slight_smile:

6 个赞
9

It worked for me by first getting into the app

./launcher enter app

then

discourse enable_restore
discourse restore <filename.of.the.backup.tar.gz>
discourse disable_restore

Using the script/discourse didn’t work

17 个赞
10

restoring from a app.yml and an external tar.gz file was mixing up some of the items I found along this thread:

TARBALL_PATH=$(ls local/backups/-*.tar.gz | tail -n 1)
TARBALL_NAME=$(basename ${TARBALL_PATH})
cat ${TARBALL_PATH} | docker exec -i app sh -c "cat - > /var/www/discourse/public/backups/default/${TARBALL_NAME}"
docker exec -i app sh -x << EOF
discourse enable_restore
discourse restore ${TARBALL_NAME}
discourse disable_restore
EOF

I had several pitfalls:

  1. the tarball to restore has to be placed exactly in /var/www/discourse/public/backups/default/
  2. the /var/www/discourse/script/discourse restore tarball-name did not work due to some single sign-on known issue
  3. the version of thor installed by gem install thor was too recent and then incompatible with the rest.
  4. finally one of the tarball I tried to restore from did not contain the “meta.json” file…

Hope this helps other in their restore journey.

2 个赞
11

Rather than try to restore from app.yml it’s much easier to just ./launcher enter app and restore it from the command line.

3 个赞
12

The goal was to automate it without any entering container with the launcher.
Imagine your instance got lost for any reason. The only files you stored in git was your containers/app.yml and luckily you have a daily tarball backup.

3 个赞
13

You can also do it directly to Postgres:

dropdb dbname
createdb dbname
gunzip -c filename.gz | psql dbname
14

discourse is script/discourse – executed via bundle exec and with rails_env=production. Look at /usr/local/bin/discourse.

Running bundle exec script/discourse takes care of the thor mismatched gem version, too. Or just using the discourse convenience script.

3 个赞
15

I tried this, and for this line:

discourse restore <filename.of.the.backup.tar.gz>

I used:

discourse restore root@droplet-01:/test/MyBackup.tar.gz

I wasn’t sure if that was the correct way to access a file “outside the app from within the app”, but it seemed to find the backup file and start the restore. The restore finished with the ambiguous messages:

Finished!
[FAILED]
Restore done.

Tried to access my forum again, but it’s still not working, so I guess the restore didn’t work?

1 个赞
16

You can’t. You need to copy the backup file into the correct directory. Please follow the instructions at Restore a backup from the command line if you want to restore from the command line.

3 个赞
17

这是我用于将生产环境恢复到开发和测试环境的工作脚本：

#!/bin/sh
set +x
set -e
# This script restore the latest productive backup to the test/dev environment
CONTAINER_NAME=app-test
LATEST_BACKUP=$(mc ls s3/backup-prod/default | tail -n 1 | cut -d ' ' -f 5)
mc cp s3/backup-prod/default/${LATEST_BACKUP} /tmp
# ensure /var/www/discourse/public/backups/default/ exists with the proper ownership
docker exec -i ${CONTAINER_NAME} sh -c "mkdir -p /var/www/discourse/public/backups/default/ && chown -R discourse:www-data /var/www/discourse/public/backups/default/"
cat /tmp/${LATEST_BACKUP} | docker exec -i ${CONTAINER_NAME} sh -c "cat - > /var/www/discourse/public/backups/default/${LATEST_BACKUP}"
docker exec -i ${CONTAINER_NAME} sh -x << EOF
discourse enable_restore
rails runner "SiteSetting.set('backup_location', 'local')"
discourse restore ${LATEST_BACKUP}
discourse disable_restore
rm -f /var/www/discourse/public/backups/default/${LATEST_BACKUP}
EOF
# rebuild container
cd /var/lib/discourse/discourse_docker
stdbuf -oL -eL ./launcher rebuild ${CONTAINER_NAME} 2>&1 | sed 's/DISCOURSE_google_oauth2_client_secret=[^ ]*/DISCOURSE_google_oauth2_client_secret=***REDACTED***/g'
cd -
rm -f /tmp/${LATEST_BACKUP}

缺少 rails runner "SiteSetting.set('backup_location', 'local')" 阻止了从备份 tarball 进行恢复。

请注意，由于启动器脚本的输出可能会在可见的 CI/CD 作业中泄露秘密，因此必须对其进行编辑。

18

很高兴您找到了解决方案。以下是一些能让其他人更容易操作的建议：

如果您在 app.yml 中使用 DISCOURSE_ALLOW_RESTORE: 'true'，则可以跳过启用恢复。 （同样，您可以将 Google 身份验证放入环境变量中，完全避免将其保存在数据库中。）

如果您同时使用暂存和生产环境，并且它们使用同一个 S3 存储桶，您可以使用以下命令恢复最新的备份：

docker exec ${CONTAINER_NAME} bash -c '$(discourse restore|grep gz|head -1)'

如果您需要本地读取，您也可以类似地使用环境变量覆盖站点设置，它将从本地存储中读取最新的备份。

2 个赞