Ankhamax
2016 年 4 月 11 日午前 6:31
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?
Is it possible?
If yes, where do discourse save or store the backups that I executed from the admin panel?
Is there any guide on how to restore the site from backup?
Thanks
「いいね！」 2
Ankhamax:
Is it possible?
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
pfaffman
2016 年 10 月 14 日午後 5:53
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
fefrei
2016 年 10 月 15 日午後 8:00
8
There’s a way to log in: Visit /users/admin-login, which can be used to log in via email
「いいね！」 6
srchip
2016 年 12 月 20 日午後 5:03
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
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:
the tarball to restore has to be placed exactly in /var/www/discourse/public/backups/default/
the /var/www/discourse/script/discourse restore tarball-name did not work due to some single sign-on known issue
the version of thor installed by gem install thor was too recent and then incompatible with the rest.
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
pfaffman
2017 年 10 月 16 日午後 5:00
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
The goal was to automate it without any entering container with the launcher.
「いいね！」 3
mrded
2018 年 8 月 15 日午前 11:33
13
You can also do it directly to Postgres:
dropdb dbname
createdb dbname
gunzip -c filename.gz | psql dbname
deargle
2019 年 2 月 1 日午前 5:29
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
lyseoy
2020 年 8 月 14 日午前 6:42
15
試行しましたが、この行の場合：
discourse restore <filename.of.the.backup.tar.gz>
以下のように実行しました：
discourse restore root@droplet-01:/test/MyBackup.tar.gz
「アプリの外からアプリ内でファイルにアクセスする」正しい方法かどうか確信が持てませんでしたが、バックアップファイルが見つかり、リストアが開始されたように見えました。リストアはあいまいなメッセージで終了しました：
Finished!
再度フォーラムにアクセスしようとしましたが、まだ動作しないため、リストアは失敗したのでしょうか？
「いいね！」 1
gerhard
2020 年 8 月 14 日午前 10:05
16
lyseoy:
アプリ内から「アプリ外のファイルにアクセスする」
できません。バックアップファイルを正しいディレクトリにコピーする必要があります。コマンドラインから復元したい場合は、Restore a backup from the command line の手順に従ってください。
「いいね！」 3
これは、本番環境を開発およびテスト環境に復元するために使用する正常に動作するスクリプトです。
#!/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からの復元が妨げられていました。
なお、launcherスクリプトの出力は、特に表示されるCI/CDジョブで実行される場合、機密情報が含まれるため、編集する必要がありました。
pfaffman
2025 年 8 月 15 日午後 7:02
18
解決策が見つかってよかったですね。他の人がより簡単にできるように、いくつか提案があります。
app.yml で DISCOURSE_ALLOW_RESTORE: 'true' を使用すると、リストアを有効にする手順をスキップできます。（同様に、Google認証情報を環境変数に設定し、データベースから完全に除外することもできます。）
ステージングと本番で同じS3バケットを使用している場合は、最新のバックアップを次のようにリストアできます。
docker exec ${CONTAINER_NAME} bash -c '$(discourse restore|grep gz|head -1)'
ローカルで読み取る必要がある場合は、同様にサイト設定を環境変数で上書きすると、ローカルストアから最新のバックアップを読み取ることができます。
「いいね！」 2
