自己ホスト型の場合、サーバーに壊滅的な問題が発生した場合に備えて、オフサイトバックアップを保持しておくべきです。ある日、 が予告なく事業を停止したり、何らかの理由で /var/discourse を削除してインストール全体を消去してしまったと想像してみてください。
最低限必要なこと
バックアップが有効になっているか確認してください。
検討すべきサイト設定:
enable backups: オン（デフォルトはオン）backup frequency: どの程度のデータ損失なら許容できますか？（デフォルト：7 日）。@pfaffman は 1 日をおすすめしています。backup time of day: バックアップ取得中にフォーラムをリードオンリーモードにする時間をいつに設定しますか？backup with uploads: アップロードを別の場所に保存しているか、他の方法でバックアップしている場合を除き、オンにしてください（デフォルト：オン）。maxiumum backups: どれほど慎重に備えていますか？ディスク容量はどれくらいありますか？（デフォルト：5）
これにより、データベースが何らかの原因で破損した場合に最近のバックアップから復元できますが、Discourse サーバー自体が消失した場合は保護されません。
リモートバックアップ
新しいサーバーでサイトを復元するには、少なくとも Discourse が作成するバックアップが必要です。/var/discourse//containers にコンテナがある場合、新しいサーバーのセットアップがはるかに簡単になります。
オフサイトバックアップを維持する具体的な方法は、このドキュメントの範囲を超えていますが、rsync などのツールを使ってデータをリモートサーバーにコピーする方法があります。これを行うガイドは多数ありますので、自分に合ったものを見つけてください。
/var/discourse/containers ファイルは頻繁に変更されないため、変更を加えたときに手動でバックアップしてもそれほど苦痛ではありません。これらには通常、SMTP やプラグインが含まれており、記憶から比較的簡単に再構築できますが、緊急時にそれを行うのは避けたいものです。もしそうなっても、いくつかのプラグインが欠落し、メール機能が動作しない状態でシステムを起動し、残りの部分をシステムが機能不全のまま対応しながら見つけることも可能です。
S3 へのバックアップ
オフサイトバックアップを維持する最も便利な方法は、Set up file and image uploads to S3 で説明されているように、S3 にプッシュすることです。その場合、S3 の設定をいつでも見つけられる場所に保管しておくか（または app.yml に含めておく）、新しいサーバーをセットアップしたら S3 から直接サイトを復元できます。
設定を app.yml ファイルに埋め込むことも可能です。app.yml の env セクションに以下のような記述を含めると、これらの設定は Web インターフェースから表示されなくなります。その場合、管理者アカウントを作成してログインすることなく、Restore a backup from the command line に従ってコマンドラインからバックアップを復元できます。
DISCOURSE_S3_ACCESS_KEY_ID: 'key'
DISCOURSE_S3_SECRET_ACCESS_KEY: 'secret'
DISCOURSE_BACKUP_LOCATION: 's3'
DISCOURSE_ENABLE_S3_UPLOADS: true
DISCOURSE_S3_BACKUP_BUCKET: 'my-backup-bucket'
DISCOURSE_S3_REGION: 'us-west-1'
また、アップロードも S3 にあり、S3 プロバイダーが安定していることを信頼している場合、Discourse にデータベースのみをバックアップさせることも可能です（上記の設定を参照）。これにより、すべてのアップロードの複数のコピーを保存する必要がなくなります。この方法を選択する場合は、実際にすべてのアップロードが S3 に存在することを確認するために、テスト復元を行ってください。
練習あるのみ
最も最近のバックアップのコピーのみを保持することは、危機時に復元するために必要な最低限のものですが、バックアップが実際に機能することを 本当に 確実なものにしたい場合は、少なくとも 1 回、できれば定期的にテストを行うべきです。新しいサーバーを起動し、バックアップから復元できるか確認してください。