让不断增长的文件集合有喘息空间。

1。将集合与文件系统分开。

同时写下应用程序报告的用量和底层文件系统已用空间。它们回答的是不同问题。成员配额说明该账户在应用程序规则下可存储多少。它不一定描述使用 VPS 磁盘的所有内容。

例如，Nextcloud 的文档将用户配额与元数据、旧版本和已删除项目分开；一些应用程序数据还存储在数据库中。在没有检查这些其他类别的情况下，不要将配额总计变成磁盘容量预测。保留行为还取决于配置和版本。 Nextcloud 33 存储配额文档.

在整个工作表中使用相同单位。如果一个工具报告十进制 GB，另一个报告 GiB，请标明差异，而不要将这些数字视为可直接互换。

2。为每种存储写一行。

将原始文件、版本、已删除项目、预览和临时工作分开。加上操作系统、应用程序、数据库和日志。如果挂载了外部文件夹，请记录实际由哪个存储系统持有它；熟悉的文件夹名称不能证明字节在 VPS 上。

对于每一行，记录其当前大小、增长原因、保留决策以及可以更改该决策的人。“版本”需要应用程序设置或文档化策略。“临时”需要清理负责人和完成条件。被遗忘的导出归档即使原始用途已经结束，仍然是真实的磁盘占用。

不要因为缓存或应用程序目录的名字听起来可丢弃就删除它们。先检查所选应用程序支持的维护流程。

3。处理一个假设的集合。

设想一个小型历史兴趣小组保存扫描的通讯和活动照片。以下数字是十进制 GB 的规划假设，不是测量结果或容量承诺。它们预留四个月的增长，然后再做下一次决策。

10 GB 导出额度无法容纳第二次完整的 96 GB 集合。完整导出需要不同的目标或修订后的预算。在安排导出之前发现这一点是有用的。

4。单独为恢复副本做预算。

同一 VPS 上的第二个目录无法解决该 VPS 丢失的问题。在单独的工作表上记录独立目的地、访问所有者、保留规则和恢复位置。根据实际备份方法和保留策略规划其容量；不要假设压缩或去重会实现特定的节省。

完整的应用恢复集可能需要的不仅仅是用户文件。Nextcloud 列出了其配置、数据、数据库、主题和自定义应用（如存在）。其备份过程还考虑了数据变化时的一致性。请遵循已安装版本的文档，而不是复制活动目录并称其为完整。 Nextcloud 备份组件与一致性.

让第二位授权维护者可以访问独立副本，而无需将凭据放入预算表。

5。决定空间耗尽前会发生什么。

选择与下一个计划活动相关联的审查阈值。对于假设的集合，小组可以在其剩余可用空间无法再容纳下一个商定的导入加上临时处理及其运营储备时进行审查。该规则比等待任意百分比变红更有用。

当增长超出工作表时，首先确定类别。更多接受的原始文件可能证明更多存储是合理的。意外的版本、失败的清理或失控的日志需要调查。更改保留策略会影响人们可以恢复的内容，因此请获得商定的批准，并在永久删除材料之前验证独立副本。避免将紧急删除作为集合的正常运营计划。

6。用真实周期检查工作表。

在授权的导入或编辑周期之后，将观察到的增长与每个额度进行比较。确认接近配额的用户仍会收到有用的应用错误，并且主机保留操作空间。在不暴露共享报告中私人文件名的情况下审查最大的类别。

如果应用使用看起来适中但磁盘空间迅速下降，请检查版本、已删除项目保留、临时上传、导出和日志。如果备份意外增长，请比较其选定路径和保留更改。如果空间已经严重不足，请暂停进一步导入，并在调查时避免生成另一个大型本地存档。记录更改并更新预算；不要将差异隐藏在更大的未解释额度中。

7。将容量和实用性放在一起。

存储规划无法决定小组应保留哪些记录。单独商定这一点，包括谁可以批准删除以及成员如何了解保留变更。还要记录文件是否仍然可读：完整但格式过时的集合可能仍需要导出或转换计划。

当你了解所需的资源总量后，将工作表带到 VPS 配置器 。然后规划 可移植导出 a 恢复演练。本指南提供了一种预算方法；它不保证特定磁盘大小能够容纳未知的集合。