我正在备份家庭服务器以便重新安装它，并且我正在使用 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/驻留在不同的磁盘上。
根文件系统安装在一个小型 SSD (128 GB) 上，在此操作之前该 SSD 已满 60-70%（我记不清了）。在过去的几年里，磁盘已经满了，在过去的几天里，我没有做任何不同的事情，除了运行 rsync 命令来备份它。现在系统磁盘已完全满（df -h报告已使用 111G 中的 108G），因此它变得有点不可用（例如 nginx 抛出内部服务器错误）并且再次运行 rsync 命令失败（它实际上并没有抛出错误）但退出时进度为 0%）。至少我仍然可以 ssh 进入它。
我还没有机会重新启动它，看看这是否可以清理一些空间，但无论如何，我认为这不是我所做的预期行为。为什么 rsync 会占用 30-40% 的源磁盘空间？如果有帮助的话，我正在屏幕会话中运行 rsync 命令。
答案1
我遇到同样的问题，当我将我的数据库备份（位于单独的逻辑卷上，该逻辑卷有很多可用空间，例如总共1.8T，单个备份文件只有100GB）rsync到我们的NFS（NFS也有很多可用空间，例如 ~ 60TB 可用空间），我发现根分区（/位于另一个独立的逻辑卷上，总共 200GB）空间使用率从 ~ 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 只是将数据复制到/分区）。并且重启后autofs，rsync就可以成功，不会占用/分区空间。
所以请仔细检查目标路径是否属于源盘。