做群晖 NAS 间备份这件事很多人一开始想的是“复制一份到移动硬盘不就行了”可真到数据恢复的时候才发现备份的价值不是那份文件在不在而是你能不能在需要的时候把它完好地拿回来。我现在的方案是两台群晖一台当主 NAS一台放在另一个物理位置专门接收备份。这个组合做出来的效果就是标题里说的群晖 NAS 间数据备份和异地容灾主 NAS 被水泡了、被搬走了、硬盘阵列崩了第二台机器上仍然有一份能用的数据。这篇文章我想把整套思路和实操步骤完整讲清楚。你会看到为什么“群晖对群晖”是比单纯外接硬盘更可靠的做法也会看到我用 Hyper Backup 配置远程备份任务时考虑的每一项参数端口、账号权限、备份计划、保留策略、加密开关、完整性校验以及首次全量备份时如何把速度尽量拉起来。文章后半部分还会聊 rsync、Snapshot Replication 这类辅助方案最后是我用几年时间踩出来的一堆故障排查记录。如果你手头正好有或者即将有两台群晖想给工作室、家里或小团队的数据多加一道保险这篇内容可以直接当操作手册用。1. 为什么值得做“群晖对群晖”的异地容灾1.1 备份和同步不是一回事先纠正一个常见误区把文件从主 NAS 复制到另一台 NAS不等于备份。很多人在两台群晖之间挂了个同步任务主 NAS 删了文件同步任务过几分钟就把删除动作也带到备份 NAS最后两边一起空空如也。这在我实际维护中见过不只一次尤其是有人拿 Cloud Sync、Drive 这类工具当备份用时最容易埋雷。真正的备份至少要满足三个条件有历史版本能回到“过去的某一个时间点”。有独立的保存位置不依赖主 NAS 的存在。有恢复验证机制确保那份数据真的能读出来。群晖 NAS 间数据备份恰好能满足前两条。历史版本可以交给 Hyper Backup 的版本轮转独立位置就是另一台物理设备。第三条则要靠定期恢复演练后面我会专门讲。1.2 什么场景真正需要这台“第二台群晖”不是人人都需要两台群晖。但如果你符合下面这些情况NAS 间备份就是性价比很高的方案数据已经重要到“坏一次就会对工作或生活造成实际损失”比如家庭照片视频、公司项目文件、数据库导出包、Docker 数据卷。有固定的两台机器一台在常用场所另一台在另一个位置天然形成异地。不想把核心数据全部交到第三方云盘但又希望有类似“云备份”的离地保护。需要容灾级别希望主 NAS 整机丢失后能尽快在备机上把数据拉回来。我自己就是典型场景主力 NAS 放办公室备份 NAS 放在家里两台机器相隔几十公里。主 NAS 哪怕被偷、被烧、硬盘全挂家里那台还是能提供最近一天左右的数据。你要是只有一台机器又想异地容灾那也可以考虑“本地群晖 云端对象存储”的组合但这不是今天聊的重点。1.3 什么场景不建议硬上有一类情况我不建议用“NAS 对 NAS”硬撑业务本身有强一致性要求比如数据库需要秒级或者分钟级容灾而且数据变化量巨大。这时普通文件级备份可能不够应该考虑数据库本身的复制机制、双机热备或者更专业的容灾产品。另外如果你的两台 NAS 放在同一个房间同一个机柜里那不叫异地容灾只能叫“多了一份冗余”。真正的异地至少应该在网络、电力、物理位置上都相对独立。群晖对群晖解决的是“机器级 位置级”故障不是“应用级”故障这个定位要清楚。2. 先想清楚用哪种备份方案2.1 Hyper Backup功能最全的首选群晖最推荐的 NAS 间备份工具是 Hyper Backup。它是群晖官方套件支持把数据备份到本地共享目录、外接硬盘、远程 NAS、云服务等目标。做“群晖到群晖”时源端安装 Hyper Backup目标端安装 Hyper Backup Vault两台机器配合得非常顺。Hyper Backup 的优势在于它不只是把文件原样拷过去而是会做增量备份第一次全量之后只传输变化的数据块。块级去重和压缩节省目标端空间。版本保留策略可以按每日、每周、每月、每年的维度自动清理旧版本。客户端加密备份数据在写入目标端之前就加密目标端即使被人拿走也读不出明文。备份完整性检查能发现备份数据有没有损坏。这些能力对“异地容灾”非常关键。因为异地备份往往要跨越慢速网络每次都全量拷贝会非常不现实增量备份几乎是必须的。2.2 rsync够用但缺少保护的裸同步rsync 是很多 Linux 用户熟悉的老牌同步工具。群晖也内置了 rsync 服务你可以手动用它把目录推到另一台 NAS。优点是灵活、轻量、几乎没有套件依赖缺点是没有版本管理、没有加密选项除非走 SSH、没有完整性校验体系。rsync 做出来的通常只是一个“镜像”源端误删或者中毒后如果不小心加了--delete参数远端会被同步成一个“同样残缺”的副本。所以它在我心中的定位是临时同步、带宽有限的裸拷贝、或者给熟悉命令行的用户做补充方案。主力备份不建议用它。2.3 Snapshot Replication搭配使用的快照复制还有一个容易被忽略的套件叫 Snapshot Replication。它依赖 Btrfs 文件系统可以对共享文件夹做时间点快照并且可以把快照复制到远端群晖。它的恢复速度极快特别适合应对误改、勒索病毒这类逻辑错误。但它和 Hyper Backup 不是二选一的关系我更愿意把它看成“第二道防线”Hyper Backup 管长期版本Snapshot Replication 管快速回滚。2.4 选型小结如果让我给一个明确的推荐组合我会说主力方案Hyper Backup备份整个项目的共享文件夹、Docker 数据卷目录、重要套件数据。辅助方案Snapshot Replication对变化频繁、需要快速恢复的共享目录做快照复制。临时方案rsync做一次性迁移或者目录级镜像。这套组合的好处是既有长期历史版本也有短时间窗口的快速恢复能力。哪怕 Hyper Backup 某个版本损坏快照复制那边还可能有一个干净的副本。3. 动手前的准备账号、目录、容量和带宽3.1 目标端安装 Hyper Backup Vault 并启用 rsync 服务在配置任务之前先明确一下角色源端保存业务数据的 NAS也就是“干活”的机器。目标端接收备份的 NAS也就是“容灾”的机器。目标端需要做两件事。第一在套件中心安装 Hyper Backup Vault它是群晖官方提供的“备份接收端”源端连过来时会顺畅很多。第二打开“控制面板 文件服务 rsync”勾选“启用 rsync 服务”。默认端口是 873。如果你选择走 SSH 方式还需要打开 SSH 端口但出于安全考虑我通常只在可信内网这么做平时更推荐 rsync 协议。这里说个实际经验目标端机器如果长期放着不用建议把硬盘休眠关掉或者至少别让备份目录所在的存储空间频繁休眠。否则每次备份任务一开始目标端硬盘要从休眠状态唤醒任务可能因为超时直接报错。3.2 共享文件夹和专用账号怎么规划很多新手喜欢直接用管理员账号做备份省事但我不建议。因为备份任务一旦被误操作或者被故障拖累会造成权限扩散后期查问题也更难。我习惯在目标端单独建一个专用账号比如backuper只给它备份目录的读写权限不给管理员权限。目标端共享目录建议单独建一个总目录名如OffsiteBackup下面再按源端机器名或项目名分目录源端目录目标端备份目录/volume1/projects/volume1/OffsiteBackup/projects/volume1/docker/volume1/OffsiteBackup/docker/volume1/family_photo/volume1/OffsiteBackup/family_photo账号建好之后需要在“共享文件夹权限”里给backuper分配OffsiteBackup的读写权限。注意如果目标端启用了 rsync 服务有些时候还会涉及用户是否允许访问 rsync 服务的设置这一步在不同 DSM 版本里入口不太一样但核心原则都是给专用账号最小必要权限。3.3 容量与带宽估算容量规划不复杂但一定要做。Hyper Backup 虽然做了增量备份和去重但版本不可能无限保留。你需要先估计目标端需要多少空间。一个粗略公式是目标端空间 ≈ 源端数据总量 ×1 版本保留系数 一定余量如果源端数据总量是 1TB你打算保留 7 个每日版本、4 个每周版本、3 个每月版本那么版本保留系数通常在 1.5 到 2 之间。也就是说目标端至少要预留 2TB 到 3TB再多留 20% 余量。如果源端全是已经压缩过的视频或图片增量变化可能不大但首次全量仍然会占很多空间。带宽方面第一次全量备份是最难熬的。假设你有 2TB 数据两台 NAS 之间实际有效传输速度是 10MB/s那么首次备份理论时间就是2TB 2048GB ≈ 2097152MB 2097152MB ÷ 10MB/s ≈ 58 小时这个时间在局域网内可能还好异地跨网络就要提前计划。我的经验是第一次全量备份尽量安排在周末并且先在本地局域网或高带宽条件下跑一遍避免任务长时间悬在“正在备份”状态。4. Hyper Backup 备份任务配置全过程4.1 在源端创建远程 NAS 备份任务确保源端已经安装 Hyper Backup。打开后点“”号选择“数据备份任务”然后在目的地里选“远程 NAS 设备”。接下来填目标端信息服务器名称或 IP填目标端的内网 IP 或域名。协议默认用 rsync端口 873。账号密码填刚才在目标端创建的backuper账号。连接通过后选择你要备份的共享文件夹和应用程序。这里我强烈建议把“Docker 数据卷目录”也选进去。很多人只备份了普通共享文件夹恢复的时候才想起来 Docker 容器数据没备份。你至少要把/volume1/docker或你实际存放 Docker 数据卷的目录纳入备份范围。进入设置页后需要重点看四个选项备份计划。保留策略。完整性检查。客户端加密。不要急着点完成这四项直接决定了备份任务将来是否可靠。4.2 备份计划、保留策略和完整性校验怎么设备份计划方面我的建议是“频率别太高但绝不能太低”。普通办公和家庭数据每天一次增量备份已经足够。如果数据变化非常密集可以一天两次但要注意目标端 IO 压力和网络压力。如果只是每周备份一次那主 NAS 故障时最多可能丢失一周数据很多场景难以接受。保留策略我一般用自定义循环保留保留最近 7 个每日版本。保留最近 4 个每周版本。保留最近 3 个每月版本。保留最近 1 个每年版本。这样既能覆盖“误删文件后想找回几天前版本”的日常需求也能覆盖“几个月前的数据需要翻出来”的长期需求。版本太多不是好事一方面是吃容量另一方面是备份任务清理旧版本时也会占用 IO。完整性校验建议打开但不要每次备份都跑。Hyper Backup 的完整性检查会重新读取备份数据并校验极端情况下还会把备份空间占用和 IO 拉高。我习惯设置为“每月检查一次”重要数据可以选择每周但别让检查任务和日常备份挤在一起。4.3 客户端加密到底开不开客户端加密这个选项我建议这样判断如果两台 NAS 之间走的是不可信网络或者你对目标端所在位置的物理安全没把握就开启。如果两台 NAS 都在自己可控的内网里加密会稍微降低吞吐量我通常可以选择不开换取速度。但这里有个非常重要的提醒一旦开启客户端加密密码就是唯一的钥匙。密码丢了备份数据等于一堆乱码群晖官方也救不了你。所以不要把加密密码随手填个临时值最好放进密码管理器并在团队协作时指定责任人。我身边已经发生过不止一次“备份任务创建时随手填了个密码半年后想恢复却怎么也想不起来”的悲剧。别让这种事发生在你身上。4.4 首次备份如何提速首次全量备份是最容易让人焦虑的。如果你的源端数据有好几 TB建议按下面几步优化把网络问题先排除局域网内先做一次测试确认源端到目标端能稳定跑满带宽。在 Hyper Backup 任务里开启压缩但如果 CPU 比较弱压缩反而会拖慢速度需要实测对比。把大文件和小文件分开处理。如果备份目录里全是几 KB 的小文件比如文档库、源码仓库首次备份的瓶颈往往在网络往返和文件系统 IO而不是带宽。尽量避开业务高峰。录像机、监控、实时下载这些任务占用 IO 时备份速度会明显下降。我实测下来的结果是同样是 500GB 数据网络稳定的情况下开启压缩后总时间可能比不开启多 10% 到 20%但目标端空间能省不少。如果你的目标是“尽快完成首次备份”可以先不压缩如果目标是“长期省空间”再开压缩。5. 两条补充路线rsync 手动同步与 Snapshot Replication5.1 rsync 手动同步怎么做如果你已经很熟悉 Linux 命令行rsync 可以作为补充或者迁移工具。目标端启用 rsync 服务后源端可以通过计划任务执行类似下面的命令rsync -avz --delete -e ssh -p 22 \ /volume1/projects/ backuper192.168.1.10:/volume1/OffsiteBackup/projects/这条命令的意思是把源端/volume1/projects/目录下的内容镜像到目标端指定目录。我必须提醒你注意--delete参数它的含义是“源端删除什么目标端也删除什么”。如果你用它做定期同步相当于用源端状态覆盖远端这不是版本化备份。一旦源端数据因为勒索病毒或者误操作被删远端也会被清掉。所以 rsync 适合什么场景适合你知道自己在做什么、并且能接受“同步而非备份”的临时需求。比如数据迁移、把某台旧 NAS 的内容拉到新 NAS而不是长期容灾。5.2 Snapshot Replication 适合放在哪个位置Snapshot Replication 适合对“恢复速度”有要求的目录。它基于 Btrfs 快照可以在秒级生成一个时间点副本并且可以配置为复制到远端群晖。比起 Hyper Backup 的逐文件恢复快照复制在恢复整个目录时快得多。它不适合单独作为外部容灾方案。因为快照通常保存在同一组硬盘上如果整台 NAS 被偷走或者硬盘阵列物理损坏快照一样会丢。所以我的建议是用 Snapshot Replication 处理“快速回滚”需求用 Hyper Backup 处理“长期异地保护”需求。两者并不冲突反而互补。如果你要在远端启用 Snapshot Replication目标端也需要安装对应套件并且需要 Btrfs 文件系统。在创建复制任务时系统会要求选择目录和快照保留数量。这里我给一个参考值保留最近 24 个每小时快照外加最近 7 个每日快照。这样既能回滚到几小时前也不会占用太多空间。6. 常见问题与故障排查实录6.1 登录失败与权限问题“用户名或密码权限不够”是我在群晖备份任务里见过最多的报错。很多人第一反应是密码错了但更多时候是账号权限漏配。比如目标端backuper账号没有给OffsiteBackup目录读写权限或者 rsync 服务对账号进行了限制。遇到这种情况按顺序排查检查项操作账号密码先在目标端用这个账号通过 File Station 登录测试共享文件夹权限确认backuper对备份目录有读写权限rsync 服务确认目标端“控制面板 文件服务 rsync”已启用防火墙确认 873 端口没有被防火墙拦截连接方式SSH 方式时确认账号有 SSH 权限且 22 端口通还有一个隐蔽问题如果目标端装了安全相关的套件比如 Security Advisor有可能会阻止异常来源的 rsync 连接。排查时可以把安全策略临时调低测试确认后再把策略调整回来。6.2 速度慢、任务中断备份任务建好后最常遇到的是速度慢。速度慢不一定是网络带宽不够也可能是小文件过多、目标端硬盘休眠、源端正在做大量读写、加密和压缩选项太激进。我的建议是先用 iperf 或大文件拷贝测一下两台机器之间的裸传输速度如果裸速度正常再考虑是不是备份本身的 IO 特征问题。任务中断也是高频问题。尤其是异地跨网络时长时间大流量传输中间一次网络抖动就可能让任务中断。Hyper Backup 支持断点续传重新运行任务通常会从上次中断的地方继续。但如果任务反复在同一个位置报错就要怀疑某个文件是不是有问题或者源端和目标端之间网络稳定性太差。可以尝试把备份拆分成多个小任务按目录分开备份这样故障范围更小。6.3 恢复才是最终检验备份做得再勤没有恢复过就不能说自己有备份。我在实际维护中养成了一个硬习惯每季度至少做一次单文件恢复测试每半年做一次全量恢复演练。在 Hyper Backup 里恢复操作不算复杂。选择对应的备份任务点击“还原”选择一个版本再选择要恢复的文件或恢复整个共享文件夹即可。第一次恢复演练时建议把数据恢复到“新目录”而不是直接覆盖当前主 NAS 上正在使用的目录。等确认恢复出来的文件内容和时间戳都对再考虑替换现有数据。恢复时还有一个容易忽略的问题如果你备份了 Docker 数据卷恢复后不能直接双击运行容器就完事。Docker 容器、镜像、网络这层信息需要重新创建恢复出来的只是数据卷目录。所以涉及 Docker 的备份最好把docker-compose.yml或者容器的创建参数也一起备份。7. 我长期维护备份任务后的几个经验最后分享几个我用真金白银和时间换来的经验。第一不要把备份任务当成“建完就不管”的事。至少每个月看一次备份日志确认上一天的任务确实成功。很多 NAS 用户只在出事后才打开套件结果发现已经连续一周没备份成功了。群晖有通知机制强烈建议在“通知设置”里把备份失败的通知发到邮箱或手机。第二目标端 NAS 不要放太多日常任务。我见过有人把备份目标 NAS 同时拿去做下载机、跑数据库、开一堆 Docker最终备份任务和业务任务抢硬盘 IO两边都慢。备份目标机不需要高性能但需要稳定最好让它专司备份。第三重要数据不要只依赖一套备份。我现在的状态是主 NAS 本地快照 异地 Hyper Backup 一个外接硬盘离线备份。这三层各有各的作用谁也不会替代谁。真遇到极端情况比如机房进水、整栋楼断电至少还有离线盘能兜底。群晖 NAS 间备份和异地容灾不是一个多么高深的技术方案但它是一个非常值得认真对待的运维习惯。机器买回来只是第一步真正让数据睡安稳的是那条定时跑起来、经得起恢复演练的备份链路。