企业官网建设流程全解析

做群晖 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，下面再按源端机器名或项目名分目录：

账号建好之后，需要在“共享文件夹权限”里给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 Replication

5.1 rsync 手动同步怎么做

如果你已经很熟悉 Linux 命令行，rsync 可以作为补充或者迁移工具。目标端启用 rsync 服务后，源端可以通过计划任务执行类似下面的命令：

rsync -avz --delete -e "ssh -p 22" \ /volume1/projects/ backuper@192.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 服务对账号进行了限制。

遇到这种情况，按顺序排查：

还有一个隐蔽问题：如果目标端装了安全相关的套件，比如 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 间备份和异地容灾不是一个多么高深的技术方案，但它是一个非常值得认真对待的运维习惯。机器买回来只是第一步，真正让数据睡安稳的，是那条定时跑起来、经得起恢复演练的备份链路。