再インストールするためにホームサーバーをバックアップしており、ファイルシステムツリー全体をバックアップするためにrsyncを使用しています。これは私が使用するrsyncコマンドです。
rsync -aAXH --info=progress2 --exclude=dev/ --exclude=proc/ --exclude=sys/ --exclude=tmp/ --exclude=run/ --exclude=mnt/ --exclude=media/ --exclude=lost+found --exclude=srv/ / /srv/dev-disk-by-label-data/backup/pensieroprofondo/debian10/btrfs/
明確にすると、他のディスクにある/ことを除いて、すべての項目は同じディスクにあります（他のパーティションにあるにもかかわらず）/srv/dev-disk-by-label-data/。
ルートファイルシステムは、この作業の前に60〜70％の小さなSSD（128 GB）にインストールされています（正確には覚えていません）。過去数年間、ディスクがいっぱいで、バックアップのためにrsyncコマンドを実行する以外に、過去数日間は何もしませんでした。これでシステムディスクが完全にいっぱいになり（df -h使用されている111Gのうち108Gを報告）、少し使用できなくなり（たとえば、nginxで内部サーバーエラーが発生した場合）、rsyncコマンドの実行は再び失敗します（実際にエラーは発生しません）、進行は終了します。 0％です。）少なくとも私はまだsshでアクセスできます。
まだスペースが整理されているかどうかを確認するために再起動する機会はありませんでしたが、それにもかかわらず、これが私がやっていることの意図された動作だとは思いません。 rsyncがソースディスク容量の30〜40％を占めるのはなぜですか？役に立つ場合は、スクリーンセッションでrsyncコマンドを実行します。
ベストアンサー1
私のデータベースバックアップ（フル1.8Tなどの多くの空き容量があり、単一のバックアップファイルが100 GBにすぎない別の論理ボリュームにある）をNFSに再同期するときにも同じ問題が発生しました。空き容量（たとえば、〜60 TBの空き容量）、ルートパーティション（/別の別々の論理ボリュームにある、合計200 GB）のスペース使用量が〜68％から100％に増加し、最終的にrsyncが失敗したことがわかりました。
rsync: write failed on "some NFS path": No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]
NFSに同期すると、rsync一部の一時ファイルがパーティションに書き込まれるようです/。 Googleを検索しましたが、すべて一時ファイル/ディレクトリがrsyncターゲットに存在すると言いますが、私の場合はまったく関係のない場所に保存されています。 rsync ターゲットまたはソースではないパス。そしてrsyncが失敗した後、スペースは回復しました/（68％に低下しました）。
しかし、もっと驚いたのは、rsyncをバックアップする前に一度確認したところ、成功したことです。 rsync の起動時に/スペース使用量は ~ であり、22%rsync も/rsync が終了するとパーティションに「何か」を書き、スペース使用量は ~ です。使用量/に達し、決して68%リリースされません！ 、失敗したrsyncが/スペース使用量で始まるのがわかります68%。
まだ調査中ですが、何かが見つかったら更新します。
修正する:
最後に、なぜこれが起こったのかを見つけました。簡単に言えば、autofsプロセスは終了し、NFSパスは/net/some_host/path/to/backup絶対/パーティションパスになりました（したがってrsyncはデータを/パーティションにコピーしました）。再起動後、autofsrsyncは成功し、/パーティションスペースを占有しません。
したがって、ターゲットパスがソースディスクに属していることを慎重に確認してください。