我用了四年的NAS，最后还是迁到了云盘上
三年前公司刚起步，我买了台群晖DS920+放在机房，觉得这东西踏实——数据在自己手里，放心。那时候团队不到十个人，文件全塞进NAS的共享文件夹，偶尔用Drive同步一下，出问题了重启路由就完事。
但到了去年底，问题开始集中爆发。
第一个爆发的痛点是存储容量。四年来积累的文件超过2TB，照片、视频、设计稿、代码备份全堆在里面。群晖的读写速度开始明显变慢，尤其是同事们同时访问的时候，加载一个大点的PPT要等十几秒。紧接着权限管理也出了问题——共享文件夹的权限只有”读写”和”只读”两个选项，根本做不到按项目、按部门精细控制。设计部的老马抱怨过好几次，说他们的图纸被市场的人误删了，找不回来。
这些问题逼着我开始认真考虑：是不是该换到企业云盘了？
迁移的第一道坎：数据怎么搬
决定迁移之后，第一个问题就是数据怎么搬。2TB的文件，不可能停机等着慢慢拷。我用的是最笨的办法——先全量同步，再增量补差。用 rsync 跑了三天三夜，把核心文件全部同步到云端，然后告诉各部门”接下来一周旧的NAS还能访问，发现缺文件立刻告诉我”。
结果还真发现问题了。rsync默认不处理NTFS权限，迁移之后文件的 Owner 和 ACL 权限全变成了默认状态。之前在NAS上设置的文件继承关系、只读组、可访问部门，全部归零。好在我们用的是巴别鸟，支持批量重新设置权限，这一步花了两天时间才把权限体系重新搭起来。
另外有个坑要提醒：文件名里的特殊字符。NAS上有些文件是早年代理商帮我们整理的，名字里带了一些奇怪的符号，比如”「”和”」”。云端系统识别不了这些字符，迁移后文件名直接显示乱码。批量重命名花了我一个下午。
老张踩过的坑：别低估权限重建的复杂度
我隔壁那家公司比我早半年迁移，他们的IT负责人老张跟我说，他当时低估了权限重建的工作量。”我们三百多号人，原来NAS上按部门、按项目分了二十多个共享文件夹，迁移之后发现云端根本对不上原有的逻辑，重新搭了一遍权限体系花了整整三周。”
老张的教训让我重视起来。迁移之前，我把NAS上所有的文件夹结构和权限配置全部导出了一份Excel，花了两天时间梳理清楚哪些目录该对应云端的哪个团队、哪些人，才开始动手迁移。这个准备动作值了，整个过程比老张那边顺利得多。
上线之后：团队适应才是真正的硬仗
技术迁移花了两周，但团队适应花了两个月。很多人习惯了”文件存在本地或者NAS”，不愿意主动把文件传到云端，协作的时候还是老方式——U盘拷来拷去、微信发来发去。
我的办法是”堵不如疏”。先把协作频率最高的几个项目强制迁移到云端，旧的NAS共享目录逐步关掉，逼大家必须用云盘。同时设置了提醒机制，每次有人用老方式协作，就在群里提醒一句。三个月后，大部分人已经形成习惯，现在你再让他用NAS他反而不习惯了。
几点忠告
如果你也在考虑从NAS迁移到企业云盘，有几个建议供参考。迁移之前务必梳理清楚权限体系，权限重建的工作量往往比数据迁移本身还大。另外，提前处理文件名特殊字符，用脚本批量替换掉再迁移，这步很多人会忽略。还有，给团队留足适应时间，别想着一步到位，强制推行反而容易引起抵触。最后，选平台的时候重点看权限管理的灵活度和对中文文件名的支持程度，这两点是NAS迁移最常踩的坑。
我同事王姐的团队也经历过类似的过程，他们迁移的时候没做权限梳理，结果上线第一天财务和市场的人互相能看到对方的合同文档，紧急叫停重配了两天。这个案例也提醒我们，迁移前的准备永远不嫌多。
迁移四年积累的数据不是小事，但更难的是改变团队的使用习惯。做好准备再动手，坑会少很多。