NAS 数据迁移全攻略：从旧设备到新设备无缝衔接

升级 NAS 设备本该是件兴奋的事，但一想到要迁移那几十 TB 的数据、上百个 Docker 容器和复杂的用户权限设置，很多人就头疼不已。直接拷贝文件看似简单，却容易丢失文件权限、ACL 规则和系统配置，导致新设备上各种服务瘫痪。本文将分享一套经过实战检验的 NAS 迁移方案，帮助你从旧设备平滑过渡到新设备，让数据和服务完整"搬家"。

迁移前的准备工作

在动手之前，先做好以下准备工作，能避免迁移过程中的大部分问题。

1. 盘点现有资源

登录旧 NAS 的管理界面，记录以下信息：

当前 DSM/系统版本及更新状态
已安装的套件/应用列表（含版本号）
共享文件夹名称及所在存储池
用户账号列表及所属用户组
网络设置（IP、DNS、代理等）

2. 确认新设备状态

新 NAS 开箱后，先完成基础设置：

安装最新版操作系统
创建存储池和存储空间（建议使用 Btrfs 文件系统，便于后续快照和校验）
设置网络为固定 IP（与旧设备同网段）
启用 SSH 和 rsync 服务

3. 准备迁移工具

推荐使用以下工具组合：

rsync（系统自带，适合文件级同步）
Hyper Backup（群晖官方工具，适合配置迁移）
Container Manager / Docker Compose（用于容器迁移）

文件数据迁移：rsync 增量同步

对于大量文件数据，rsync 是最可靠的选择。它支持断点续传、增量同步和权限保留，非常适合 NAS 间迁移。

在旧 NAS 上执行以下命令（假设新 NAS IP 为 192.168.1.100）：

# 先做一次完整同步（首次运行）
rsync -avhP --delete /volume1/Data/ [email protected]:/volume1/Data/

# 参数说明：
# -a 归档模式，保留权限、时间戳等
# -v 显示详细信息
# -h 人类可读格式
# -P 显示进度并支持断点续传
# --delete 删除目标端多余文件（保持源和目标一致）

如果数据量巨大（超过 10TB），建议分批次迁移：

# 先迁移最重要的数据
rsync -avhP /volume1/Data/Photos/ [email protected]:/volume1/Data/Photos/

# 再迁移其他数据
rsync -avhP /volume1/Data/Movies/ [email protected]:/volume1/Data/Movies/

验证迁移完整性：迁移完成后，使用 --checksum 参数进行校验：

rsync -avhc --dry-run /volume1/Data/ [email protected]:/volume1/Data/

如果输出没有文件差异，说明迁移成功。

系统配置与套件迁移

文件迁移只是第一步，系统配置同样重要。群晖用户可以使用内置的 Hyper Backup 工具：

在旧 NAS 上打开 Hyper Backup，创建新的备份任务
选择"远程 NAS"作为备份目的地，输入新 NAS 的 IP、账号密码
勾选"系统配置"选项，包括用户、共享文件夹、套件设置等
执行备份后，在新 NAS 上安装 Hyper Backup 并选择"还原"

对于非群晖系统（如 TrueNAS、OpenMediaVault），可以手动导出配置：

TrueNAS：系统 → 常规 → 保存配置，下载 .db 文件
OMV：系统 → 备份 → 创建备份，下载 tar 包

共享文件夹权限重建：如果配置还原不完整，需要手动重建权限。在旧 NAS 上导出用户列表：

# 导出用户和组信息（以群晖为例）
synouser --enum all > /volume1/backup/users.txt
synogroup --enum all > /volume1/backup/groups.txt

然后在新 NAS 上按列表重建用户和组，再通过 File Station 或命令行设置相应权限。

Docker 容器迁移

Docker 容器迁移是很多人的痛点。推荐使用 Docker Compose 进行标准化迁移：

第一步：在旧 NAS 上导出容器配置

# 进入容器目录
cd /volume1/docker

# 生成 Compose 文件（如果原本没有）
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  ghcr.io/red5d/docker-autocompose \
  $(docker ps -aq) > docker-compose.yml

第二步：迁移数据卷

将 docker 目录整体同步到新 NAS：

rsync -avhP /volume1/docker/ [email protected]:/volume1/docker/

第三步：在新 NAS 上重建容器

cd /volume1/docker
# 修改 compose 文件中的路径和端口冲突
docker compose up -d

如果容器使用了自定义网络，记得在 compose 文件中添加网络定义。迁移后务必检查每个容器的日志，确认服务正常运行。

常见坑与解决方案

坑1：文件权限错乱

迁移后文件所有者变成 root 或 nobody。解决方法：

# 批量修正文件所有者（假设用户 uid 为 1024）
chown -R 1024:users /volume1/Data/

坑2：硬链接失效

BT 下载的文件常有硬链接，rsync 默认会保留。如果使用 --copy-links 参数会导致硬链接丢失，务必不要加此参数。

坑3：时间戳不一致

如果迁移后文件修改时间全部变成当前时间，说明 rsync 没有保留时间戳。检查是否使用了 -a 参数，该参数包含 -t（保留时间）。

坑4：端口冲突

新 NAS 上可能已有服务占用相同端口。迁移前先规划好端口映射，在 compose 文件中调整宿主机端口。

迁移后的验证清单

迁移完成后，按以下清单逐项验证：

[ ] 所有共享文件夹可正常访问，权限正确
[ ] 用户能正常登录，权限符合预期
[ ] 所有 Docker 容器运行正常，数据完整
[ ] 定时任务（cron）已迁移并生效
[ ] 网络服务（WebDAV、FTP、SMB）工作正常
[ ] 备份任务已重新配置并指向新设备

建议保留旧 NAS 一周时间，确认新设备稳定运行后再进行数据清理。

数据迁移是 NAS 升级中最关键的一环，但只要方法得当，完全可以做到无损迁移。希望本文的实战经验能帮助你顺利完成设备升级，让数据在新家继续发光发热。