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 리버스 프록시를 통해 업스트림 discourse로 요청을 전달하도록 설정된 새 서버로 복원했습니다. 그래서 discourse의 SSL을 비활성화했는데, 복원 중에 다음과 같은 로그를 확인했습니다:

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)]

백업 파일이 15GB라면, 복원에 필요한 용량은 얼마인가요?

[pfaffman (Jay Pfaffman)]

데이터베이스만 그런 건가요, 업로드 파일도 포함인가요?

아마도 그 양의 3~5배 정도일 겁니다.

[pinder99 (Raza shield)]

데이터베이스와 업로드 파일이 15GB인데, 60GB 하드디스크에 20GB의 여유 공간이 있음에도 불구하고 복구가 매번 실패합니다. 복구를 위해 최소 50~60GB의 공간이 필요한 건가요?

[pfaffman (Jay Pfaffman)]

백업, 업로드 및 압축 해제된 데이터베이스를 저장하는 데 충분한 공간이 필요합니다.

먼저 데이터베이스 백업만 복원한 다음, rsync를 사용하여 업로드 파일을 수동으로 복사해 볼 수 있습니다.

[Ethsim2 (Ethan)]

셀프 호스트에서 관리자 계정을 인증했고, .tar.gz가 아닌 .sql.gz 백업을 업로드했습니다.

UI에서 복원해도 성공하지 못해서, 커맨드 라인에서 “Restore the backup”을 실행했는데, discourse restore 과정의 마지막에 [FAILED]가 표시되었습니다. 공식 호스팅에서 가져온 입력 파일이 .tar.gz 형식이라면 프로세스가 통과할 수 있을까요?

제 공식 호스팅은 며칠 전부터 사용 중이며, 셀프 호스트는 오늘 container.yml의 SMTP 값을 변경한 후에 정상적으로 작동하기 시작했습니다.

[pfaffman (Jay Pfaffman)]

어떤 오류가 발생했는지 포함해야 합니다. 파일 이름에는 버전 정보가 포함되어 있으므로, 파일을 이름 변경한 경우 파일 이름의 앞부분 단어만 수정하여 원래 이름으로 되돌려야 할 가능성이 높습니다.

[helmi]

discourse restore에 대한 문서가 어딘가에 있나요? --location local 스위치가 있는 것 같으니, S3를 위한 옵션도 있을 것 같아서요.

S3에 저장된 백업에서 복원하고 싶고, 그 전에 수동으로 다운로드하는 과정은 피하고 싶습니다.

수정: 아니, 그냥 알아냈네요. discourse restore --location s3 $filename이 정상적으로 작동하는 것 같습니다.

[Jagster (Jakke Flemming)]

app.yml에서 S3를 활성화했기 때문에, 단순히 discourse restore <filename>만 실행해도 문제가 없었습니다.

backup restore s3를 검색하면 적절한 게시물을 찾을 수 있을 것입니다.

[Ethsim2 (Ethan)]

안녕하세요, 저는 s3(-cli)를 scp로 사용하고 메일 발송 제공업체를 MailGun에서 Brevo로 변경하여 이 과정을 완료했습니다.

복원 이후 배너를 제거하는 방법을 찾을 수 없어요?

[Moin]

@Discourse

복원 프로세스는 disable emails 설정을 자동으로 “non-staff”로 설정하므로, 준비가 될 때까지 사이트 사용자에게 이메일이 전송되지 않습니다.

배너를 제거하는 가장 쉬운 방법은 사이트 설정에서 이메일을 활성화하는 것입니다.

[pfaffman (Jay Pfaffman)]

@Moin

배너를 제거하는 가장 쉬운 방법은 사이트 설정에서 이메일을 활성화하는 것입니다.

맞아요. css로 숨기는 것도 가능하죠!

[Moin]

맞아요. 이 링크를 생각해야 했기 때문에 이 추천을 할 때 약간 신중했어요: Air theme hides "outgoing email disabled" warning

[pfaffman (Jay Pfaffman)]

@Moin

이 추천을 할 때 조금 신중했습니다. Air 테마가 “발신 이메일 비활성화” 경고를 숨기는 문제를 떠올려야 했기 때문입니다.

백업을 복원할 때마다 비스태프(비관리자) 사용자를 위한 발신 이메일이 자동으로 비활성화됩니다. 이 기능이 코드에 추가된 이유는, 백업이 테스트 서버로 복원된 후 해당 서버가 존재한다는 것을 알지 못해야 하는 사용자들에게 알림을 대량으로 발송하게 되는 상황이 몇 번 발생했기 때문일 것으로 추측됩니다.

OP(첫 게시물)을 이에 맞게 업데이트했습니다:

@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)]

그 경우 app.yml에서 DISCOURSE_DISABLE_EMAILS를 no로 설정하는 것이 좋습니다. (또한 복구를 더 쉽게 하기 위해 DISCOURSE_ENABLE_RESTORE도 설정하세요)