一台 2TB 服务器，不该先拿来囤电影

拿到一台 2TB 的服务器，最容易做的事是开个大目录，把电影、下载、镜像、安装包和各种 “以后也许有用” 的东西全丢进去。几个月后再看，空间快满了，没人知道哪个能删，真正重要的备份也和临时下载混在一起。

2TB 看着不少，按二进制计算实际约是 1.82 TiB。它不适合假装自己是无限媒体库，但很适合做一个小而可靠的个人数据节点：同步、备份、归档和自托管服务数据。

容量先给 “不可重建的数据”

一块盘满了以后，最危险的不是不能再下载，而是备份任务悄悄失败、数据库没有空间写入、服务数据损坏后找不到可恢复版本。

可以先按下面比例做第一版规划：

数字不是硬规定。照片和视频多的人可以调整，但 “预留空间” 不要被吃掉。它是应对迁移、快照、异常增长和恢复操作的缓冲区。

先做备份，再谈 “数据主权”

把文件放到自己的服务器，不自动等于有备份。只有一份数据，只是换了一个地方存。更实际的目标是至少做到：原始设备一份、服务器一份、另一处还有一份可恢复副本。

用 restic、borg 或 rsync 都可以，关键是把恢复也跑一遍。很多备份方案平时看起来绿灯，真正需要文件时才发现权限、加密密钥、保留策略或路径都没验证过。

最小验证不复杂：

1
1. 从笔记本备份一个测试目录
2
2. 删除其中一个测试文件
3
3. 从服务器恢复到新路径
4
4. 打开文件，确认内容和权限正确

每次改备份工具或换磁盘，都重复一次。备份的价值不在 “任务执行成功”，而在 “需要时拿得回来”。

把服务数据和杂物分开

服务一多，目录应该能一眼看懂：

1
/data
2
├── backups/       # 可恢复备份，保留策略明确
3
├── sync/          # Syncthing 等跨设备同步数据
4
├── services/      # Docker bind mounts、数据库导出、应用附件
5
├── archive/       # 网页归档、文档、长期资料
6
└── staging/       # 下载和临时导入，允许定期清空

staging/ 很重要。下载、转码、解压、导入都写到临时区；确认归档后再移动到正式目录。这样 “能不能删” 不需要靠记忆判断。

Docker 的数据库、附件和配置也别全部依赖匿名 volume。重要服务至少要知道：数据在哪、怎样备份、容器重建后如何恢复。应用配置、Compose 文件、环境变量模板和数据库备份都应纳入备份范围；真正的密码和密钥则单独放在密码管理器或安全的 secrets 流程里。

媒体库是可选项，下载目录不是资产

Jellyfin、Plex、照片库、网页归档都能放在 2TB 上，但先决定内容的保留规则。比如只存自己确定会回看的片单；下载完成七天后自动清理；网页归档只保存真正要引用的资料。

对单盘来说，媒体库还有一个现实问题：它很占空间，却往往最容易重新获取。备份、文档、照片、配置和创作文件的恢复价值通常更高。空间冲突时，先删临时下载和可再获取媒体，而不是让备份被挤掉。

监控容量，也监控增长原因

给磁盘设置使用率告警，建议不要等 100% 才报警。超过 70% 先看趋势，超过 85% 就应该处理。除了总容量，还要关心：

• 哪个目录增长最快；
• 快照和回收站是否占用大量空间；
• 数据库日志、容器日志是否未轮转；
• 下载和转码临时文件是否遗留；
• 备份保留策略有没有失控。

du、ncdu、节点监控工具都能发现问题。发现占满空间时，不要上来就 rm -rf。先列出最大的目录，确认它属于临时数据、可重建数据还是唯一副本，再删除。

什么时候该扩容或拆分

如果一个 2TB 节点同时承担唯一备份、照片库、媒体库、对象存储和多个数据库，迟早会互相争空间。这不是规划失败，而是它已经超出单盘职责。

出现以下任一情况，就该考虑扩容或拆分：

• 备份加预留空间长期超过总容量的一半；
• 重要服务和大下载在争写入性能；
• 单盘故障会同时影响所有唯一副本；
• 为了腾空间，已经开始删不确定是否可恢复的内容。

先升级备份冗余，再扩媒体容量。多一块盘不一定让数据更安全；有独立副本、知道怎样恢复，才算。

2TB 的价值不在塞满多少内容，而在于让关键数据有确定的去处。先把备份、目录和保留规则做出来，剩下的空间才是真正能自由折腾的空间。