NAS这行当做得越久我越觉得“备份”这两个字的分量比参数表上任何性能指标都重。找我咨询的朋友十有八九都会问同一个问题数据要是没了怎么办。单说本地备份外接硬盘、RAID、快照这些手段大家多少都知道一点可一旦把场景放大到整台机器报废、机房停电、家里漏水这种灾难级别本地所有副本会跟着一起完蛋。真正能兜底的思路只有一个把数据的另一份副本放到离你有物理距离的机器上这就是异地容灾。群晖NAS间数据备份做的正是这件事源端和目标端各放一台群晖让备份数据自己通过网络跑过去源端出事就从目标端拉回来。这篇文章会完整过一遍从方案选择、容量规划、账号配置到Hyper Backup实操和恢复演练的全过程适合有两台群晖、或者准备把老家那台旧NAS当容灾目标的朋友。别急着上来就建任务先把几个关键选择题做对后面能少踩一大半的坑。1. 群晖NAS异地容灾方案怎么选才不踩坑1.1 为什么群晖对群晖备份比“本地移动硬盘”更像异地容灾先说一个我经常见到的误区NAS里已经建了RAID 1再插一块移动硬盘定时拷贝很多人就觉得万无一失了。RAID解决的是硬盘物理损坏解决不了误删、勒索加密、固件升级翻车、甚至整台设备被搬走的问题移动硬盘如果只是简单的单向同步没有版本管理那某一天源端被写入坏数据、感染加密病毒下一次同步就会把坏数据原封不动地复制到移动硬盘里等于备份了一堆垃圾。真正意义上的异地容灾核心是三件事份数、位置、可恢复性。至少要有三份数据其中一份放异地而且异地那份得有历史版本能回到灾难发生前的某个时间点。群晖NAS间数据备份天然契合这个场景两台设备各自动运行目标机上的副本带着时间轴源端整机挂了还能从远端把文件捞回来。在群晖体系里能实现跨机复制数据的方式不少但有的工具跟“容灾”两个字根本不是一个赛道。比如很多人习惯用Drive ShareSync做同步它会实时把源端的增删改都镜像到目标端误删一个文件远端立刻也跟着删这不叫容灾叫把故障放大一倍。真正做备份需要的是快照式、带版本增量、能独立于源端存在的数据副本这也是我在下文反复强调选择工具时最核心的一个判断标准。1.2 三大主流备份工具选型Hyper Backup、rsync、Drive ShareSync群晖之间做数据复制社区里讨论最多的就是这三类方案我直接整理成一张对照表看完再决定用哪个比自己一个个试效率高得多。维度Hyper BackuprsyncSynology Drive ShareSync备份形式套件级多版本增量备份命令行数据同步实时双向/单向同步版本与轮换原生支持可配置保留策略基本靠手动管理无多版本概念压缩加密内置压缩、客户端加密有但需额外配置传输加密为主恢复体验图形化浏览和恢复命令行操作恢复门槛高文件级直接拉取适合场景异地容灾、系统配置备份熟悉Shell的高级用户文档协作不适合容灾我最终推荐Hyper Backup原因很实际。第一它能备份的不只是共享文件夹还能备份系统配置、套件设置灾难后恢复的完整度高。第二它自带多版本去重和增量机制每次任务只传变化部分对异地带宽的占用远比想象中小。第三它的版本轮换策略真的能做到“按日保留、按周保留、按月保留”这是rsync和ShareSync完全做不到的。rsync也不是没用它适合按目录整机重置同步或者当你是命令行重度用户时作为补充手段。但它的版本管理很弱容易出现“目标机已被写坏”的尴尬局面。ShareSync则明确不推荐作为容灾主工具它更强调多设备之间的协作效率灾难恢复这个场景下缺了时间维度就等于没有安全网。1.3 冷备还是热备先说清RPO和RTO再谈方案很多朋友一听到“异地备份”就默认要上实时网络传输结果一看自己家上行带宽只有30M立刻打了退堂鼓。其实异地容灾可以分冷备和热备两条路线关键看你能接受多长的恢复时间。RPO是“最多丢多久的数据”RTO是“从灾难发生到业务恢复需要多久”。如果数据是个人相册、家庭文档能接受丢一天那每天凌晨跑一次Hyper Backup增量任务RPO就是24小时这已经覆盖了大多数家用场景。如果跑的是服务型业务能接受丢的时间按小时算那就把调度频率设成每6小时甚至每小时代价是目标机的空间和网络开销同步上升。冷备则是更极端但更省事的办法定期把数据副本同步到一块移动硬盘再带到异地的群晖上导入一次。两块硬盘轮流带当地设备只做存储链路差也能接受。我自己见过不少“宽带上行迟迟升不上去”的案例最后都是冷备保底、网络增量补差效果并不比全程热备差。方案没有绝对好坏先定RPO和RTO再选冷热节奏这才是正确顺序。2. 备份机准备清单容量、账号、网络配置一步到位2.1 目标机基础要求系统、文件系统和硬件目标端那台群晖不需要多强的多核性能备份任务主要吃的是压缩能力和网络吞吐像J4105、3865U这类低功耗四核平台完全够用性能瓶颈基本都在异地带宽上。但存储盘一定不能将就目标机硬盘建议至少要做到RAID 1因为容灾副本不应该因为目标机单盘损坏而失效。DSM版本方面两台设备可以一个是DSM 7、一个是DSM 6Hyper Backup的基本备份链路都能工作但新版本的优势在于更稳健的WebDAV、SMB3支持以及更灵活的版本管理。如果条件允许尽量把目标机也升级到DSM 7.x再配置任务减少协议兼容性上的坑。文件系统建议选Btrfs不光是快照功能权限控制、共享文件夹配额也更好用对后续精细化权限管理很重要。如果你还在用Ext4也不影响Hyper Backup运行只是部分高级特性用不上。另外如果目标机是拿旧笔记本刷的黑群晖或纯Linux拼的DIY NAS备份协议层面都能对接但我要多说一句破解系统升级风险高、可靠性不可控别拿它当唯一的容灾副本顶多算第三份冗余。2.2 备份容量怎么算才不会跑一半没空间我做容灾方案时最反感的就是拍脑袋指定“目标机要比源机多一倍的盘”。版本数量、增量速度、保留周期这些都要量化不然很快就会被“每天看着剩余空间一点一点往下掉”支配。给一个可以直接套用的粗算公式目标空间 ≈ 源端已用数据量 单日增量总和 × 计划保留的版本份数举个例子源端当前已用数据是3TB每天新增10GB计划保留30个每日版本 12个每周版本 24个每月版本版本份数大约是66份。那目标空间就是3TB 10GB × 66 ≈ 3.66TB再叠加20%安全余量目标机至少准备4.4TB可用空间。Hyper Backup带多版本去重实际占用通常会比这个公式小但做规划时用保守算法更稳妥。容量规划还有一个容易忽略的点要同时考虑目标机上的其他文件和系统快照占用。不要把整块盘的可用容量全部当成备份空间共享文件夹配额一定要设好给系统运行和快照留出缓冲区。我见过不止一次因为目标机还跑着监控套件、下载任务硬盘悄悄被塞满最后备份任务连着一周失败的情况。2.3 目标机账号、共享文件夹和网络端口最小开放策略目标机上的权限一定要按“最小权限”原则来配。很多新手图省事直接把管理员的账号密码填进Hyper Backup任务这等于把整个NAS的后门交给了网络传输链路一旦账号信息泄露目标机上的所有资料也一起完蛋。正确做法是单独建一个专用备份账号比如backup_remote密码用长随机串只给它访问备份共享文件夹的读写权限不加入管理员组不给任何套件管理权限。共享文件夹建议单独划一个backup-pool不要直接把整块卷开放给源机。通过共享文件夹配额限制它最大能占用多少空间再配合账号权限既能防误操作也能防目标机被远程脚本扫到后批量拖数据。网络端口这个环节尤其要谨慎。Hyper Backup可以走到SMB、WebDAV、rsync、SSH等不同协议不同协议对应的端口和暴露风险完全不同。SMB默认走445端口直接暴露在公网非常不安全我不建议在路由器上把445映射出去。跨公网做异地备份时我更推荐用WebDAV over HTTPS或者rsync over SSH只映射必要的端口并在群晖防火墙上限定来源IP。如果两地之间实在没有可靠的直连条件那就干脆退回到冷备方案轮换移动硬盘也比裸奔一个高风险端口要靠谱得多。3. 手把手实操Hyper Backup异地备份任务创建与自动调度3.1 目标机环境创建与权限确认正式开始之前先把目标机这边的环境配置好。以下几个步骤建议按顺序执行不然后面建任务时很容易因为权限或服务没开而反复报错。在控制面板的“共享文件夹”中新增一个backup-pool并设置容量配额比如上面的计算案例里设成4.5TB。配额不是必须的但能防止备份任务把整块卷空间耗尽。创建专用备份账号backup_remote密码用随机生成的强密码并将该账号加入backup-pool的读写权限列表中。注意不要勾选“加入管理员组”也不要顺手给它所有共享文件夹的访问权。决定备份协议。如果两台群晖在同一个内网环境直接用“远程NAS设备SMB”最省事如果跨公网我建议在目标机的“文件服务”中开启WebDAV服务并绑定HTTPS证书这样源机可以通过WebDAV方式连接传输过程是加密的。最后检查端口。确认目标机路由器上的端口转发只映射了实际用到的端口并在群晖防火墙中将源机IP加入白名单其他IP一律拒绝访问。这条做得好源机就算被爆破目标机也不会被波及。3.2 源机创建Hyper Backup备份任务目标机准备妥当后接下来就是源机的操作我这里以DSM 7为例。打开套件中心确认已经安装Hyper Backup。如果没装直接在套件中心搜索安装。安装完成后打开套件点击左下角的“备份”按钮任务类型选择“数据备份任务”。目的地类型的选择取决于3.1里你的协议决定。选“远程NAS设备”时需要填写目标机的IP或DDNS域名、端口、账号密码以及目标机上已经创建好的共享文件夹名例如backup-pool。选“WebDAV服务器”时填写格式是https://目标域名/共享文件夹路径同样用备份账号登录。接下来会进入“选择备份内容”页面。这里建议勾选共享文件夹、系统配置和套件设置但如果某些目录纯粹是缓存或临时文件比如P2P下载目录、缩略图缓存就没必要塞进备份包能省不少空间和时间。任务名称和运行账号页面上建议用专用账号运行任务比如源机上也可以建一个hyper_backup账号避免用管理员身份跑定时任务。所有设置完成后先手动运行一次确认链路通、数据能落地再去做调度安排。我最怕的就是配置完直接丢到计划任务里不管结果一周后一看日志全是连接失败。3.3 压缩、加密、去重、版本策略和计划任务参数怎么填任务能跑起来只是第一步决定备份质量的是后面这几个参数。加密必须开。Hyper Backup允许设置客户端加密密码数据到目标机之前就完成加密这样即使目标机硬盘被物理拿走对方拿到的也只是密文。这个密码一定要单独保存后面细说我先强调一句丢了加密密码备份基本等于报废。压缩看两端CPU。目标机和源机都是J4105、3865U这类处理器开启压缩可以减少网线上的数据量代价是每次备份任务会多吃一些CPU。如果目标机已经是第三代酷睿以上的平台压缩收益明显建议开启旧平台则要看实际传输速度和CPU占用再权衡。多版本去重Hyper Backup默认会启用它只在目标机上保存变化的数据块而不是每次新增一份完整副本。这对增量备份的带宽和空间占用影响巨大不要关掉。版本策略有些人直接选“智能回收”它会按Recovery Time Objective自动决定保留粒度适合不想手动算空间的用户。我自己的习惯是自定义规则每日保留30份、每周保留12份、每月保留24份这样覆盖大约一年配合容量规划公式能提前知道需要多少空间。版本数不是越多越好保留规则越激进目标机硬盘被塞满的速度越快。调度频率以RPO为准。如果目标是每天一份就选择“每天”并设成凌晨2点这个时段网络低峰、源机业务负载也低。如果数据敏感度更高就把频率调成每小时但每个时间点之间会有更多小增量包目标机的随机读写负载也会增加。3.4 首次全量备份的时间评估与提速技巧第一次备份一定是全量耗时要提前算好否则很容易觉得任务卡死了。带宽换算有个经验公式1MB/s等于8Mbps100Mbps的上行链路理论值约12.5MB/s。按这个速度传1TB数据理想情况下需要1024000MB除以12.5MB/s约22小时所以通常要跨两三个晚上。如果你的上行链路只有30Mbps实际速度约3.75MB/s传1TB就要接近74小时意味着将近一周的时间窗口。既然首次全量耗时长就不要把所有数据一股脑塞进一个任务。我的建议是先建一个小任务让人像照片、工作文档这类高价值目录先走一遍确保数据落地确认链路稳定后再通过修改任务范围把其他目录加进来。这样即使中间断链核心数据也已经有一份安全副本了。还有一个提速技巧值得专门提一下异地链路实在慢的时候可以先做一次“冷播种”。把源端的共享文件夹导出或打包通过移动硬盘运到目标机所在位置人工拷贝到目标机的共享文件夹之后再用Hyper Backup做增量校准。整个过程比纯网络全量快得多尤其适合首次迁移、数据量几个TB的场景。4. 恢复演练和故障排查实录4.1 文件级恢复和整机恢复演练流程备份做得再好不会恢复也等于没有。我强烈建议每年至少做一次恢复演练别等灾难真的发生时第一次打开恢复界面。文件级恢复最简单打开Hyper Backup控制台选择对应的备份任务和版本点“浏览”就能以文件浏览器的形式看到当时的目录树选中文件或文件夹直接下载恢复。日常误删文件、覆盖文件90%的恢复动作都在这个界面完成。整机恢复的流程会重一些。如果源端NAS完全损坏先在备用设备上安装DSM再通过Hyper Backup的“恢复”功能选择之前备份好的共享文件夹、套件配置和系统设置。要注意恢复时如果硬件型号和原设备不同个别套件可能因为底层驱动或版本差异无法直接还原最保险的策略是核心共享文件夹优先恢复套件和系统设置随后逐步补。这个经验来自我自己的迁移经历有一次目标机是J4105平台源端坏了后换了一台更高规格的机器系统配置大部分自动回来了但有个依赖硬件指令集的套件重新装了三次才正常。恢复演练不能只是点两下确认软件能用真要模拟灾难我会选择性地把目标机上的共享文件夹挂载备份再对比文件数量、目录结构和关键文件哈希值。只有走到这一步才能确认备份数据真的可以用于恢复。4.2 常见故障速查表实战下面这些故障是我这几年在各类NAS群晖备份部署里反复遇到的高频问题整理成速查表遇到可以直接对着排查。现象排查方向解决思路连接超时目标机端口、路由器映射、DDNS解析先用局域网IP连一次确认链路通再检查端口是否被运营商拦截用户名或密码权限不够目标机共享文件夹权限确认备份账号至少有读写权限不能只读任务显示中断网络不稳定、磁盘休眠设置备份重试次数尽量在凌晨低峰跑给目标机硬盘关闭休眠增量包过大是否有大量文件替换或元数据重建检查源机是否有临时文件波动必要时重建备份索引目标机空间满版本保留策略太激进减少保留版本数或扩容目标机共享文件夹配额WebDAV连接失败证书过期或未启用HTTPS更新Let’s Encrypt证书确认WebDAV服务里的HTTPS选项是开启状态还有一个隐蔽问题很多人没遇过就是目标机硬盘休眠导致备份唤醒失败。NAS默认为了省电会让硬盘在一定时间无读写后休眠但源机发起备份时目标机硬盘从休眠到就绪需要几十秒某些协议会直接超时。解决方法是让备份共享文件夹所在的硬盘组关闭休眠或者设置定时任务在备份开始前做一些轻量读写把它唤醒我用的是后者效果更稳。说到“用户名或密码权限不够”这个提示我还要多说一句。有相当高比例的情况根本不是密码错了而是目标机上账号对共享文件夹只有只读权限Hyper Backup需要读和写只有只读权限时就会一直报权限不足。这个低级错误浪费了我至少三个小时排查希望你不要再踩。4.3 备份监控和几个容易忽略的心得运行时间久了真正决定容灾方案靠不靠谱的往往不是备份工具本身而是监控和运维习惯。源机和目标机都要设置通知。控制面板-通知设置里配置邮件或手机推送任务失败、存储空间异常时第一时间收到消息。很多人的母NAS是7x24开着的但目标机在异地可能没通电、没联网到备份时间点“打不通”通知会立刻暴露问题。异地那台机器最好再接一台UPS至少保证短时断电后备份窗口不会漏掉。加密密码的保存方式需要特别重视。我见过不止一个案例用户开了Hyper Backup客户端加密美滋滋以为万无一失后来恢复时想起密码已经忘了备份数据就成了一堆无法解密的文件。我的习惯是密码手写两份纸质件分别放在不同地点的安全位置同时存在自己靠谱的密码管理工具里。加密可以防泄露但密钥本身要用冗余方式留存钥匙丢了锁再结实也没用。还有一个容易被忽略的设置完整性检查。Hyper Backup带有备份完整性校验功能它会扫描目标机上的备份数据块确认没有静默损坏。我建议每三个月安排一次放在周末凌晨运行因为完整校验会大量读取目标机硬盘平时跑会影响正常使用。备份任务不是建完就完事的定期看日志、看空间曲线、跑恢复演练都是这份工作的日常。最后提一个我自己的亲历教训也是这篇文章最想强调的点。曾经给一位朋友配置了异地备份任务版本策略设置得很“激进”只保留了每日最近几份。半年后他有个重要文档被反复覆盖想恢复更早的版本时才发现可用版本已经被轮换掉了。从那以后我所有方案的版本保留默认都会给足周版本和月版本空间不够可以扩盘但误删后没有历史版本可恢复那是任何扩容都弥补不了的。做群晖NAS间异地容灾技术上不难真正难的是把方案建立在“数据一定会丢、丢了一定要能恢复”的假设上。每一次备份任务的成功都只是在给这个假设多上一道保险该做的加密、权限、容量规划、恢复演练一样都不能省。按这个流程走完一遍之后你大概率也会和我有同样的感觉与其焦虑数据安全不如把这些动作变成系统里自动运行的日常。
