新規インストールした Discourse インスタンスでリストアを試みていますが、CLI で以下のエラーが発生しています。
ERROR: could not extend file "base/16384/17011337": wrote only 4096 of 8192 bytes at block 15860
HINT: Check free disk space.
EXCEPTION: psql failed: HINT: Check free disk space.
リストアしようとしているバックアップファイルは 22 GB（圧縮 gz）で、サーバーには 198 GB の空き容量があります。ディスク容量の問題ではないと思うのですが、なぜこのようなエラーが表示されるのか原因がわかりません。ご存知の方はいらっしゃいますか？
圧縮前のサイズはわかりますか？また、これはインデックスを考慮していないため、ディスク容量の多いサーバーで試すことを検討してください。
ディスクパーティションも確認してみてください。サーバーに 198 GB の空き容量があるとしても、サーバーには複数のディスクパーティションが存在する可能性があります（ご存知の通り）。df コマンドの実行結果を返信していただけませんか？
@Ghan さん、こんにちは
復元はコマンドラインから開始しましたか、それとも「Docker Manager」UI から開始しましたか？
両方の方法で試しましたが、直近は CLI で試しました。インポートの進行状況に合わせて、ディスク容量を増やし、その使用状況を監視します。
50 GB を追加して正常に完了しました。データベースとしては非常に多くのディスク容量ですね。
リストアプロセスでは、インポートに比べて追加のインデックスが作成されるのでしょうか？
これはフォーラムのコンテンツを保存します。Discourse インスタンスには 1 GB のものもあれば 500 GB のものもあり、どれほど活発に利用されるかによって異なります 
各テーブルのサイズを確認するクエリは、PostgreSQL 13 アップデート トピックに記載されています。実行して結果をここに投稿してみてください。
コンテンツが大量にあることは承知しています。しかし、バックアップとリストアを行うだけでストレージ要件が急激に増大したようです。バックアップ前には100 GB以上の空き容量があったため、リストアに問題はないと予想していましたが、実際には予想以上に多くの容量を必要としました。わずかに不足していたようです。
データベース内のトップ20の巨大なオブジェクトを表示するクエリを実行しようとしていますが、すでに約1時間実行されており、完了までにどれくらい時間がかかるのか見当もつきません。
スキーマのバックアップとリストアがまだ残っていないか確認してください。バックアップやリストアが（容量不足など）壊滅的に失敗した場合、それらが残ったままになることがあります。週に一度、それらを削除するバックグラウンドジョブが実行されていますが、より早く実行することもできます。
/sidekiq/scheduler にアクセスし、Jobs::DropBackupSchema を検索して「トリガー」をクリックしてください。
完全バックアップがある場合、3 つのコピーが存在します。完全バックアップ、その中に含まれるデータベースダンプ、復元されたデータベース、そして元から存在するデータベースです。
