首先我要声明，我对 Duplicity 一无所知。我所在组织中了解这方面知识的人已经休假了，照例，在他休假期间，发生了一些不寻常的事情。
今天我收到警报，我们的一台服务器突然填满了根卷。这台服务器已经运行多年，根卷只有 5GB，因为里面从来没有任何东西，而且我们从来没有遇到过卷快要填满的问题。我追踪了 /root/.cache/duplicity 文件夹的使用情况。当时，服务器正在运行每月的 cronjob，执行“remove-older-than 1Y”，然后执行“remove-all-inc-of-but-n-full 3”。正是在 remove-older-than 操作期间，磁盘被填满了。看起来上个月中期，该服务器上的数据更改显著增加，导致增量备份的大小突然增加。当然，这只是猜测，因为我真的不知道我在看什么（正如我已经提到的）。
因此，我只是临时将根分区的大小增加到 20GB（感谢 LVM），但似乎工作有点挂起了。我杀死了正在执行 remove-older-than 任务的子进程，然后父脚本继续处理第二个任务。当这一切结束时，我得到了两个任务的备份报告，其中显示了 python 回溯错误“设备上没有剩余空间”——这并不出乎意料。
这让我有几个问题：
如果我理解正确，并且从我在服务器上看到的情况来看，这两个任务似乎都会出于某种原因从远程存储位置（通过 ssh）下载一堆备份文件到本地 /root/.cache/duplicity 文件夹，然后可能在最后清理这些文件。对吗？如果是这样，我不完全理解需要下载哪些文件以及这样做的确切目的。
这样我就剩下四个“duplicity-full-signatures”文件及其相关的清单文件，9 月/10 月各一个，11 月两个，以及几个“duplicity-new-signatures”文件和相关的“duplicity-inc”清单文件，似乎涵盖了上个月（但是，第一个文件似乎丢失了 - 我假设这是磁盘已满时正在下载的文件）。我将它们与我们使用 Duplicity 并同时运行相同 cronjob 的其他服务器之一进行了比较，而这台服务器只有一个完整签名文件（9 月/10 月/11 月各一个）和相关的清单文件。根本没有 inc 清单或新签名文件。我想知道清理这些文件的正确方法是什么，或者我是否需要这样做。我要么手动删除完整签名和 inc 文件，这样它就具有与服务器相同类型的文件而没有问题，要么我将它们保留在那里直到下次运行，它们可能会或可能不会被清理，或者我再次手动运行每月的 cronjob 并让它覆盖文件并在最后正确清理它们。
请原谅新手提出的问题，这是我第一次使用 Duplicity。