某天早上看监控，OA 应用服务器弹了条根分区告警，/ 已经爬到 95% 往上。
这类告警最麻烦的地方不在于当下有多急，而在于它不会自己停。初步估计是OA 的附件造成的，而且是只增不减的，流程越走越多，附件越堆越厚，今天不动手，过阵子就是用户上传失败、系统写不进文件。
先确认是谁吃的空间
df -h 只能告诉你哪个分区满了，找凶手得靠 du。一层层往下扒，很快落在附件目录上：
du -sh /usr/weaver/ecology/*（这是这套 OA 的默认安装位置，你的环境按实际路径改。）
结果不出所料，filesystem 一个目录就吃掉了根分区的大半。这里面存的是所有流程附件、公文、扫描件，业务上一个都不能删，只能想办法搬走。
为什么不直接扩容
装机的时候，LVM 的空间基本都分给了 /home 那个 LV，根分区留得很小。VG 里已经没有余量再往 / 上扩，除非把 /home 缩回来。可线上机器缩 LVM，停机窗口和风险都不划算。
所以方向只剩一个：把附件目录挪到 /home，让根分区腾出来。
两条路，选了软链接
一条是改应用配置，把附件存储路径直接指到 /home。厂商官方文档走的是这套，但配置文件里牵扯的地方不少，这台机器上又有些本地定制的东西，改完能不能干净生效，心里没底。
另一条是软链接：数据在文件系统层面搬走，应用看到的还是原来那个路径，一行配置都不用动。跟厂商技术支持确认过这条路可行，最后就用了它。
对程序完全透明，出问题也好退回去，这是它最大的好处。
操作过程
需要停 OA 服务，所以安排在下班之后做。
1. 停服务
先把应用停干净。附件目录里有正在写入的文件，带着业务在线同步，很容易拿到半截文件。
2. 记录当前空间
df -h留个操作前的底，后面对比用。
3. 同步数据
mkdir -p /home/filesystem
rsync -av /usr/weaver/ecology/filesystem/ /home/filesystem/这里用 rsync 而不是 cp -r，是因为 -a 会把属主、权限、时间戳、软链接一起带过去。附件目录的权限要是不对，上传就会莫名其妙失败，这个细节不能省。
数据量大的话这步最花时间，加个 --progress 能看着点。
4. 改名，别直接删
cd /usr/weaver/ecology
mv filesystem filesystem_old这一步纯粹是给自己留后路。改名是瞬间完成的，原数据一个字节都没动，万一后面发现链接没生效或者应用报错，改回来就完事。
5. 建软链接
ln -s /home/filesystem /usr/weaver/ecology这里有个容易看错的地方：命令给的是 /usr/weaver/ecology 这个目录，不是 .../ecology/filesystem。ln 发现目标位置是个已存在的目录时，会在里面按源路径的 basename 建链接，结果就是 /usr/weaver/ecology/filesystem -> /home/filesystem，正好是想要的。
写成 ln -s /home/filesystem /usr/weaver/ecology/filesystem 效果完全一样，而且更好读。两种都行，但脑子里得有 basename 这层逻辑，否则容易建出 filesystem/filesystem 这种嵌套。
6. 验证链接
ll /usr/weaver/ecology/filesystem
ls /usr/weaver/ecology/filesystem/ | head看指向对不对，再进去列几个文件，确认能读到。
7. 把旧目录挪走
mv /usr/weaver/ecology/filesystem_old /home/到这一步根分区才真正腾出来。
8. 再看一次空间
df -h9. 起服务，验证业务
登录 OA，传一个新附件，再打开几个老附件。读写都正常才算完，光看命令没报错是不够的。
回滚预案
真出问题，退回去也就两步：
rm /usr/weaver/ecology/filesystem
mv /usr/weaver/ecology/filesystem_old /usr/weaver/ecology/filesystem然后重启服务，看附件的上传和查看是否正常。
第一条 rm 删的是符号链接本身，不是数据。顺手提醒一句：删软链接时路径末尾千万别加 /。rm link 删链接，rm -r link/ 会顺着链接把目标目录里的真数据删掉。这个坑踩一次就够记一辈子。
事后想到的几点
旧副本别急着删，但也别忘了删。 我把它挪到 /home 先留着观察，确认业务没问题再清。要注意的是，这时候 /home 上装着同一份数据的两个拷贝，占用直接翻倍。忘了清的话，下一次告警的就是 /home。
这只是止血。 根分区偏小的根本问题没解决，附件还会继续长。真正该做的是从装机阶段就把附件目录单独划一个 LV；退一步讲，至少把告警阈值往前挪，别等到 95% 才被动出手。
软链接方案有它的代价。 备份脚本如果用 tar 或 rsync 而没处理好链接，备出来的可能是个链接文件而不是数据；du 统计目录大小时也得留意要不要跟链接走；个别程序遍历目录时，对符号链接和真目录的行为并不一致。这台机器上是 OA 自己读写，没碰到麻烦，换个场景就得先验证一遍。
能不停机当然好，该停还是得停。 数据量再大一个量级，我会先用 rsync 在线预同步一遍，再停机做增量，把停机窗口压到几分钟。这次量还能接受，直接一次做完了。