組み込みのバックアップを使用して移行しようとすると、圧縮プロセスでディスクがいっぱいになってしまうためです。まだ約60GBの空き容量がありましたが、バックアップ中にディスクがいっぱいになり、失敗しました。
しかし、/var/discourseフォルダ全体を手動で圧縮すると、アーカイブは約30GBにしかなりません（フォルダ自体は約34GBです）。
容量がいっぱいになるとすぐに解放されるため、80%の時点でスクリーンショットを撮りました。
それで、私の質問は次のとおりです。
• /var/discourseフォルダ全体をtar/packして、新しいサーバーに移動し、展開してからDiscourseを実行できますか？
• それとも、推奨される方法（データベースバックアップ+アップロードの個別のコピー）に従う必要がありますか？
• バックアップ圧縮プロセス中にディスクがいっぱいになるのを回避する方法はありますか？
こんにちは。
こちらをご覧ください。
はい、空き容量を増やすことです 
その明白な答えはさておき、バックアップ作成時にスペースを取りすぎるのを防ぐための機能リクエストがありますが、まだ実現されていません: Reduce local disk space needs by not (redundantly) gzipping backups & Add option to disable backup compression
また、まだ実行していない場合は
./launcher cleanup
を実行すると、多くのDockerイメージがスペースを占有している可能性があります。
docker system prune が役立つかもしれません。
サーバーの容量を44GBに解放しましたが、合計98GBしかありません。その後、S3を再度起動しましたが、まだ機能しません。十分な空き容量がありません。Discourseがバックアップをこれほど大きくする理由がわかりません。
[2025-08-20 10:11:31] バックアップを最終処理中…
[2025-08-20 10:11:31] アーカイブを作成中: discourse-2025-08-20-101058-v20250812033430.tar.gz
[2025-08-20 10:11:31] アーカイブが既に存在しないことを確認中…
[2025-08-20 10:11:31] 空のアーカイブを作成中…
[2025-08-20 10:11:31] データダンプをアーカイブ中…
[2025-08-20 10:11:31] アップロードをアーカイブ中…
[2025-08-20 10:16:35] 一時ディレクトリ ‘/var/www/discourse/tmp/backups/default/2025-08-20-101058’ を削除中…
[2025-08-20 10:16:36] アーカイブをgzip圧縮中、これには時間がかかる場合があります…
[2025-08-20 10:28:05] 例外: gzip -1 /var/www/discourse/public/backups/default/discourse-2025-08-20-101058-v20250812033430.tar
アーカイブのgzip圧縮に失敗しました。
gzip: /var/www/discourse/public/backups/default/discourse-2025-08-20-101058-v20250812033430.tar.gz: デバイスに空き領域がありません
[2025-08-20 10:28:05] /var/www/discourse/lib/discourse.rb:171:in `execute_command’
/var/www/discourse/lib/discourse.rb:137:in `exec’
/var/www/discourse/lib/discourse.rb:32:in `execute_command’
/var/www/discourse/lib/backup_restore/backuper.rb:253:in `create_archive’
/var/www/discourse/lib/backup_restore/backuper.rb:40:in `run’
/var/www/discourse/script/spawn_backup_restore.rb:9:in `backup’
/var/www/discourse/script/spawn_backup_restore.rb:31:in `block in ’
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork’
/var/www/discourse/script/spawn_backup_restore.rb:4:in `’
[2025-08-20 10:28:05] 古いバックアップを削除中…
[2025-08-20 10:28:06] クリーンアップ中…
[2025-08-20 10:28:06] ‘.tar’ の残り物を削除中…
[2025-08-20 10:28:07] バックアップを完了としてマーク中…
[2025-08-20 10:28:07] バックアップ終了を ‘VegaMonika’ に通知中…
/var/discourse/shared/standalone/backups/default に残っている .tar ファイルを削除する必要があると思います。
アップロードが多すぎてバックアップに収まらないようです。 (1) より大きなディスクを用意する、(2) アセットを Spaces または S3 に移動する、(3) アップロードをボリュームに移動する、(4) アップロードをバックアップしない、のいずれかを行う必要があります。
.tar ファイルを削除した後の最も簡単な即時の解決策は、アップロードをバックアップしないことです。
私は、これを EC2 インスタンスからより大きなものへの移行の一部として実行しましたが、新しいサーバーは古いサーバーとまったく同じベース OS イメージ、ホスト名、インストール済みソフトウェア、IP アドレスを持つという条件付きでした。/var/discourse を新しいボックスに移動した後、launcher rebuild app を実行したところ、サイトがすぐに起動しました。
したがって、これらの非常に特定の状況下では、試した 1 回はうまくいきました。
それは乱雑な移動方法ですが、デフォルトのインストールであり、すべてのDockerコンテナを最初に停止することを確認する限り、おそらく機能するでしょう。
snap remove aws-cli
.\\launcher stop app
docker system prune
apt autoremove
.\\launcher enter app
discourse backup
docker cp “app:/var/www/discourse/public/backups/default/your-site-2006-01-02-150405-v20200101150405.tar.gz “ “root@[server_ip_address]:/var/discourse/shared/standalone/backups/default/your-site-2006-01-02-150405-v20200101150405.tar.gz“
exit
snap install aws-cli --classic
aws configure
aws s3 cp “/var/discourse/shared/standalone/backups/default/your-site-2006-01-02-150405-v20200101150405.tar.gz“ “myBucket://your-site-2006-01-02-150405-v20200101150405.tar.gz“
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.