群晖套件里的 Active Backup for Business下文统一简称 ABB。这套东西我在最近三年里给好几家中小规模的业务环境落地过主要就是拿它来备份 Linux 服务器。原因很实在Linux 服务器不像 Windows 那样有铺天盖地的整机备份工具多数人的做法还停留在 tar 打包、rsync 拉目录、或者扛着 U 盘去跑再生龙做冷镜像——能备份但是恢复麻烦、增量基本没有、集中管理全靠自己写脚本。ABB 把这件事拉回到一个图形界面里在群晖 NAS 上装套件在 Linux 主机上装一个 Agent之后就是块级增量、集中存储、可视化还原。它适合谁适合手上有群晖设备、有若干台 Linux 服务器、又没有预算上企业级备份软件的人也适合已经有一堆脚本、但每次恢复都要翻笔记的运维。这篇东西我按实际落地的顺序讲从环境盘点一路讲到裸机还原和排障中间会把我踩过的坑都说清楚。1. 先搞清楚 ABB 到底能对 Linux 做什么1.1 ABB 不是一个文件同步工具别拿它当 rsync 用很多人第一次打开 ABB会下意识把它理解成群晖版的 rsync 图形界面这个理解偏差会直接导致后面的方案设计跑偏。rsync 是文件级的它比对的是哪些文件的时间戳或大小变了然后把这个文件重新复制一遍ABB 对物理服务器走的是块级增量它关心的是磁盘上有哪些扇区被写过了只把这些变化过的块传过去。两者的差别在恢复时特别明显一台放着 500GB 数据库文件的机器rsync 方案在恢复时你要先把系统装好、再把目录同步回去、然后祈祷权限和属主没错ABB 的方案是整机连着系统、分区表、引导一起恢复回去起来就能开机。还有一个容易被忽略的差别是快照一致性。rsync 在文件读一半的时候如果文件正在被写入你抓到的就是一个半截文件数据库的日志和数据文件天然对不上。ABB 在 Linux 上做备份之前会先给文件系统做一次快照从这个时间点上读取数据保证拿到的是一份同一时刻的镜像。对跑 MySQL、PostgreSQL 的机器来说这一条几乎是刚需。当然快照也不是万能的数据库层面还是建议配合各自的 dump 逻辑备份ABB 负责的是把整台机器的底子保住。1.2 整机备份和卷级备份选错等于白做ABB 在 Linux 端建任务的时候会让你选备份范围这里有两个概念必须分清楚。整机备份是把所有卷连同引导分区一起打包这是唯一支持裸机还原的模式卷级备份只挑你指定的卷恢复的时候只能恢复到某个挂载点或者提取文件。很多人图省事选了卷级结果真到系统盘损坏那天才发现自己没有整机恢复点那时候只能重装系统再往上贴数据中间的时间成本非常难受。我的建议很直接只要这台机器的系统盘是你要保护的就选整机备份。整机备份占用空间会大一些但换来的是换台硬件也能原地复活的能力。如果这台机器上挂着几十 TB 的冷数据盘而那些盘本身有独立的冗余机制你可以在同一台机器上建两个任务一个整机任务保护系统和应用盘另一个卷级任务单独保护关键数据盘这样容量和恢复灵活性都能兼顾。1.3 授权、机型和存储格式这三个硬前提ABB 在群晖的产品体系里位置有点特殊它不是一个完全免费的套件。文件服务器这类走 SMB 协议的目标是免授权的Synology NAS 之间的备份也是免授权的但物理服务器和虚拟机的备份属于设备授权每台被保护的机器要占一个许可。部分 Plus 及以上机型会随机附赠一到两个许可小环境里够用机器一多就得单独补。买之前一定先数清楚你要保护几台 Linux 主机再对照机型附带的许可数量不然装完套件发现没授权任务建不了白折腾。存储这一端有硬要求ABB 的备份数据必须落在Btrfs格式的存储空间上。原因是它要依赖 Btrfs 的快照和数据完整性校验去做备份版本管理ext4 的卷在创建共享文件夹时是选不进去的。如果你手上的群晖已经被一堆 ext4 卷占满了就得考虑加盘新建 Btrfs 存储池或者把不重要的数据挪走重建。这一条建议在买盘规划阶段就考虑好事后调整非常费劲。顺便提一句社区里流传的那些非官方引导安装方式我不太建议用在这类场景上。承载生产备份数据的设备稳定性比省钱重要得多正规渠道的设备和正版 DSM 在这类长时间跑任务的使用场景里少掉的麻烦不止一点点。2. 动手之前的环境盘点与容量规划2.1 NAS 端准备套件、存储空间与共享文件夹NAS 这边的动作其实不多但顺序不能错。先进套件中心把 Active Backup for Business 装上装完打开会引导你完成初始化其中一步是选择备份数据存放的位置这一步选的就是前面说的 Btrfs 存储空间。初始化完成后ABB 会自动在目标卷上创建一个用于存放备份数据的共享文件夹权限由套件自己管理你不需要手动去动它。这里有个实操细节值得说不要把这个共享文件夹和你日常使用的业务共享放在同一个已经被塞到 90% 使用率的卷上。ABB 在写入增量数据、做数据校验、以及执行还原的时候都需要额外的临时空间卷快满了的时候表现是任务莫名失败或者速度断崖式下跌日志里未必给你一句人话。我的习惯是给备份卷留至少 20% 的空闲作为缓冲。另外套件装完之后建议顺手把通知打开。DSM 的控制面板里有邮件或推送通知的配置把 ABB 的事件挂上去后面任何一次备份失败你都能第一时间知道而不是等到要恢复的时候才发现最近一个月全是红的。2.2 被备份 Linux 主机的体检清单在 Linux 端动手之前花十分钟做一遍体检能省掉后面几个小时的排障。需要确认的东西我用一张表列出来照着走一遍就行。检查项命令关注点发行版与版本cat /etc/os-release是否在 Agent 支持列表内内核版本uname -rdattobd 模块要按内核编译磁盘与分区lsblk -f系统盘、数据盘、是否有独立 /bootLVM 结构pvs/vgs/lvs卷组剩余空间够不够做快照文件系统类型df -Thext4/xfs 都行确认没有网络盘混在里面软 RAIDcat /proc/mdstat有 mdadm 软阵列的要单独确认支持情况内核头文件rpm -q kernel-devel或 dpkg -lgrep headers防火墙systemctl status firewalld/ufw status出站策略是否有限制时间同步timedatectl时间偏差过大影响任务调度这张表里最容易被跳过的是 LVM 和内核头文件这两行。LVM 关系到快照能不能做成内核头文件关系到快照模块能不能编译出来这两个都是装的时候不报错、跑备份的时候才失败的典型。2.3 容量与保留策略怎么算才不爆盘容量规划这件事很多人是靠先跑起来再说结果三个月后备份卷爆了最老的全量被删掉剩下的增量链断在半空中。我一般按下面的思路估首次全量占用 ≈ 已用数据量 ÷ 压缩比。ABB 对物理服务器这块主要是块级增量加压缩普通文本和代码类数据压缩比能到 1.5:1 甚至更高已经压过的数据视频、压缩包、大量镜像文件压缩比接近 1:1规划时按 1.2:1 保守估。每日增量 ≈ 已用数据量 × 日变化率。业务库和日志类机器日变化率 3%~8% 很常见文件服务器可能只有 1%。总占用 ≈ 首份全量 每日增量 × 保留天数 20% 缓冲。举个具体的例子一台跑了业务系统和数据库的服务器有效数据 400GB日变化率按 5% 算。首份全量大约 330GB每日增量约 17GB保留 30 天的话是 330 17×30 840GB再加 20% 缓冲规划 1TB 比较稳妥。如果开了 GFS 式的多层保留比如日保留 30 份、周保留 12 份、月保留 12 份占用会明显上升规划时至少再多留一半。保留策略的设置原则是能覆盖你最坏的恢复场景就行不是越多越好。被误删的文件通常当天就会发现被加密勒索攻击往往一周内暴露需要翻到一个月以前数据的情况其实很少。我一般默认日保留 30 份、周保留 8 份、月保留 6 份这个组合在多数中小环境里够用。2.4 网络与端口把通信链路先打通ABB 的 Linux 备份是 Agent 主动去连 NAS所以链路上要放行的是客户端到 NAS 方向的端口。群晖官方文档里有完整的端口表实际部署里经常需要确认的是TCP 5510和TCP 1194这两个另外 ICMP 建议也放开Agent 会用 ping 做连通性探测。如果你的 Linux 机器上有严格的白名单出站策略这两个端口必须放行否则现象是任务一直卡在连接中或者直接超时。网络这块我踩过最典型的坑是网卡协商。有台机器的交换机端口没配好跑到了百兆备份速度只有 10MB/s 出头一台 300GB 的机器跑了将近十个小时我一开始还以为是磁盘慢。后来ethtool一看是 100Mb/s换根线换端口速度直接上到 90MB/s。所以部署前先看一眼链路速率和 MTU别把网络问题当成软件问题查。3. Linux Agent 安装与第一个备份任务3.1 安装包获取与安装命令实录Agent 的安装包在 DSM 的 ABB 界面里下载路径大致是物理服务器这一类目下的添加设备流程里会让你选择操作系统并下载对应的包。Linux 端提供 deb 和 rpm 两种按发行版选就行。下载下来一般是这样的文件名synology-active-backup-business-linux-agent-x.x.x-xxxx_amd64.deb或者对应的.rpm。Debian 系Ubuntu、Debian的安装sudo dpkg -i synology-active-backup-business-linux-agent-*.deb sudo apt --fix-broken install -yRHEL 系CentOS、RHEL、Rocky、Oracle Linux的安装建议先把编译工具链装好再装包否则快照模块编译会失败sudo yum install -y gcc make dkms kernel-devel-$(uname -r) kernel-headers-$(uname -r) sudo rpm -ivh synology-active-backup-business-linux-agent-*.rpm装完之后很多人会卡在服务到底叫什么名字。不同版本打包出来的服务名不完全一致别硬背直接查systemctl list-unit-files | grep -iE abb|backup|synology找到服务名之后确认状态正常应该是 active (running)。同时看一眼内核模块有没有加载成功这是后面备份能不能做增量的关键lsmod | grep -i datto dkms status如果dkms status里显示模块没编译或者编译失败先去看缺什么依赖通常是内核头文件没装或者 gcc 版本不对。这一条我在 CentOS 7 的老机器上遇到过两次装上kernel-devel再重跑一次安装就好。Debian 系还有个常见的拦路虎是 Secure Boot开启了安全启动的机器第三方内核模块会被拒绝加载需要在 BIOS 里关掉安全启动或者给模块签名。3.2 dattobd 和 LVM 快照怎么选Agent 安装完之后备份时的快照机制有两种选择这也是这篇东西里最值得展开讲的一个技术点。dattobd是一套内核级的块设备跟踪模块工作原理是在块设备层挂一个钩子记录哪些块被写过从而支持块级增量。它的优点是通用性强不要求你的磁盘必须是 LVM普通分区也能用而且能做真正的块级增量跟踪。代价是它需要编译内核模块内核一升级模块就得重新编译属于典型的升级完忘了这一步备份静默失败的类型。LVM 快照利用的是你现有的 LVM 卷组创建快照卷来读取一致性数据。它的优点是不用编译内核模块稳定、无侵入缺点也很明确必须有 LVM而且卷组里要有足够的剩余空间给快照用。快照空间不足会触发快照溢出快照直接作废备份任务跟着失败。我的选择策略是如果机器已经是 LVM 结构卷组剩余空间也够优先用 LVM 快照省心如果是普通分区或者卷组已经快满了那就上 dattobd但要接受内核升级后要维护这件事把它写进你的变更流程里。两种都不满足的环境就得考虑先调整分区结构了。具体到 LVM 快照的空间要求我给的经验值是快照空间至少等于备份期间数据的变化量。因为备份窗口通常持续几十分钟到几小时这个变化量一般不会太大卷组保留 10%~15% 的剩余空间做快照基本能扛住。但如果卷组已经用到 95% 了硬上快照就是在赌我不建议。3.3 在 DSM 里建任务关键参数逐项拆解NAS 端的任务创建界面看着选项不少其实真正需要动脑的没几个我按顺序说。设备类型和连接方式添加物理服务器会让你选 Linux然后系统会给一个安装指引和安装包。装完 Agent 之后在 ABB 界面点添加设备输入 Linux 主机的 IP、Agent 端口和这台机器的 root 凭据或者用 Agent 侧生成的连接方式反向注册。凭据这块我要提醒一句尽量用一个专用的运维账号并妥善保管别直接用个人账号后面人离职了还得改一堆东西。备份范围整机还是指定卷前面说过了保护系统就选整机。备份计划这里要区分备份频率和备份窗口。频率上日备是最常见的窗口上一定要避开业务高峰。首次全量最耗时如果安排在工作时间磁盘 IO 和网络带宽都会被吃掉一大块业务方会来找你。我一般把首次全量安排在下班后后续增量跑在凌晨。保留策略前面算过容量的按算出来的结果填。可以选保留最近的 N 个版本也可以选多层保留。这里有个细节——如果任务同时在跑多个版本保留策略占用的空间不是简单相加因为增量块会被多个版本共享实际占用会比你想的少一些但规划时不要按这个乐观值来。压缩与加密压缩建议开尤其是文本类数据。加密看你所在环境的合规要求开了之后密钥要保管好丢了备份就等于没有。注意加密会给备份过程增加一点 CPU 开销低配机器上要评估。应用感知Linux 这边主要是配合快照脚本做一致性处理。如果机器上有数据库可以在备份前后挂前后置脚本做 dump 或者在快照后强制刷盘。这个功能很多人不用但做过一次就知道它有多值。3.4 先手工跑一次再交给计划任务建好之后别急着让它等计划触发先在界面上手工跑一次。这一趟的目的有三确认能连通、确认速度正常、确认快照能做成。手工跑的时候盯着几个地方任务状态、传输速率、以及日志里有没有模块相关的警告。首次全量跑完之后建议再做一次小的增量验证随便在机器上写个测试文件等下一个增量周期跑完然后用文件级还原把这个文件捞出来看看对不对。这一步花不了多少时间但能提前把看起来在备份、实际上不可恢复这种最糟糕的情况暴露出来。备份这件事没验证过的都只能算疑似有备份。另外提一句手工跑首次全量的时候别关终端、别重启 NAS 的套件、也别让 NAS 上的其他重负载任务比如索引、相册转码同时跑这几个都会明显拖慢备份速度甚至导致任务中断后从头再来。4. 还原才是备份的价值三条恢复路径实操4.1 文件级还原最常用也最容易上手大部分时候你要恢复的只是几个文件比如某个配置文件被改坏了、某个日志被误删。这种情况下不需要大动干戈走裸机还原。ABB 提供了恢复门户通过浏览器登录就能浏览各个备份版本里的目录结构找到文件直接下载下来比走 ssh 和命令行舒服多了。如果是一整批文件比如某个应用的数据目录被清空我一般会走挂载还原点的思路在目标 Linux 主机上通过 Agent 侧的能力把某个备份版本挂载成一个只读目录然后用rsync -a把需要的部分同步回去。这样做的好处是可以边同步边核对不用先把几十 GB 下载到本地再复制一遍省时间也省磁盘。这里有个权限上的坑从备份里恢复出来的文件属主和权限位通常能保留但如果目标机器上的 UID/GID 和源机器不一致比如换了一台机器、重建了用户你恢复出来会发现文件是裸的数字 UID需要手工 chown。恢复前先确认目标环境有没有这道差异。4.2 整机裸机还原恢复介质制作与恢复流程系统盘挂了、机器起不来的场景才是整机备份真正派上用场的时候。流程分三段。第一段是准备恢复介质。在 DSM 的 ABB 还原界面里有创建恢复介质的入口选 Linux 后会给你一个 ISO 下载。这个 ISO 本质是一个精简的启动环境下载下来用 Rufus 或者 dd 写到 U 盘上sudo dd ifabb-recovery.iso of/dev/sdX bs4M statusprogress convfsync这里的/dev/sdX一定要确认清楚写错盘符的后果不用我多说。写完拔盘之前先 sync 一下。第二段是在目标机器上启动。从 U 盘引导后会进到一个图形或文本的恢复环境需要配置网络DHCP 或者静态 IP然后填入 NAS 的地址、账号和密码选择要恢复的设备和恢复点。这一步的前提是目标机器和 NAS 网络互通跨网段的话要提前把路由打通。第三段是选目标磁盘并执行恢复。恢复完成后一定要处理两个收尾问题一是引导如果源机和目标机的磁盘数量、控制器类型不一样grub 可能装不上去需要进 rescue 模式手动重建二是/etc/fstab如果分区 UUID 变了开机时会挂载失败进 emergency mode得先把 fstab 里的 UUID 换成新的。硬件差异越大这两个问题出现的概率越高。提醒换硬件做裸机还原时网卡名称很可能从ens33变成ens192这类如果系统里有基于网卡名的固定配置比如网络绑定、防火墙区域起来之后要一并检查。4.3 即时恢复到虚拟机做应急接管的备选方案有一个场景值得单独提源机器硬件彻底坏了但备件要等两天业务不能停。这时候可以考虑把最近一个可用的 Linux 备份直接以虚拟机形式拉起先把服务跑起来等硬件到了再做正式恢复。ABB 配合群晖自己的虚拟化套件可以做到这件事把恢复点以虚拟机方式启动网络接入原来的网段服务接续运行。这条路子的价值在于争取时间不是长期方案。因为虚拟机的性能、硬件直通、驱动都没法和物理机完全一致跑业务库这种对 IO 敏感的服务会比较吃力。我的用法是把它当成应急手段在演练里跑通过一次确认能起来就写进应急预案真出事的时候按预案执行。5. 故障排查速查表与踩坑记录5.1 Agent 侧问题从模块和依赖开始查Linux 端的问题八成集中在快照模块和相关依赖上。按下面这个顺序查效率最高现象可能原因处理方式任务报无法创建快照dattobd 模块未加载lsmod | grep datto没有则检查 dkms 状态内核升级后备份全失败模块没随新内核重编dkms status看版本dkms autoinstall重生报权限或挂载失败SELinux 拦截模块加载查dmesg相关记录评估临时放宽策略装包时报依赖缺失缺 gcc/内核头文件补齐构建依赖后重新装连接一直超时端口未放行或路由不通确认 5510/1194 出站ping NAS 测通模块编译报错Secure Boot 未关BIOS 关闭安全启动或走模块签名这张表里我遇到频率最高的是第二条。Linux 内核会不定期升级一个yum update之后内核换了dattobd 没跟上备份任务照常调度、照常失败如果你没开告警可能几周都不知道。所以我强烈建议把 ABB 的失败告警接到邮件或者即时通知上同时把内核升级后检查 dkms写进运维清单。5.2 NAS 侧与任务侧问题NAS 这边的问题更多是容量和策略引起的。备份卷使用率超过 85% 之后各种奇怪现象会开始出现任务变慢、数据校验失败、甚至同一时间内多个任务互相抢 IO。排查的时候先看存储空间、再看任务日志、最后看系统日志顺序别反。另外一个是验证失败类的报错。ABB 会定期对备份数据做完整性校验校验失败可能的原因包括存储层出现坏块、备份过程中断导致块缺失、以及底层卷做过扩容迁移之类的操作。碰到这种情况我的做法是先跑一次新的全量把链补上再把失败的旧版本清理掉别在一个已经损坏的恢复点上反复挣扎。还有一种情况是任务被卡在运行中不动通常是某个网络连接半死不活挂着。这时候不要直接重启 NAS先在 ABB 界面里中止任务观察 Source 端的 Agent 是否释放了快照再决定下一步。中途硬重启 NAS 有概率留下不一致的备份文件虽然通常会被后续校验发现但清理起来也麻烦。5.3 我踩过最疼的几个坑第一个坑首次全量安排在白天。一台 600GB 的机器全量跑了六个多小时正好覆盖了业务高峰磁盘 IO 被占满业务系统响应时间翻了三四倍。当天下午我被叫去讲清楚。教训就是首次全量必须有窗口意识宁可周末跑。第二个坑卷组剩余空间不足硬上 LVM 快照。当时那个 VG 只剩 8% 左右我觉得够用了结果备份进行到一半数据变化量大快照溢出任务失败前后白跑两个小时。后来我给自己定了个规矩VG 剩余空间低于 15%不做 LVM 快照改用 dattobd或者先扩容。第三个坑恢复介质缺驱动。给一台比较新的服务器做裸机还原U 盘启动后死活认不到网卡恢复流程根本走不下去。后来换了一版恢复介质的 ISO 才解决。这件事告诉我恢复介质要在同型号或近似型号的机器上提前验证一次别等真出事才第一次用。第四个坑没演练就宣布上线。早期我确实这么干过觉得任务绿灯就是成功了。后来一次真实的恢复请求暴露了权限和 fstab 的问题虽然最后数据没丢但过程极其狼狈。从那以后我的验收标准变成至少完整走通一次文件级还原半年走一次裸机还原演练。6. 长期运维让这套备份自己跑起来6.1 告警与巡检节奏备份系统最怕的不是失败是失败了你不知道。ABB 的事件通知一定要接出去邮件也好、Webhook 也好接一个你就少操一半的心。我的习惯是只把失败和警告级别的事件推出来成功的不推否则每天几十封邮件最后全进垃圾箱。巡检节奏我按周和月分层。每周看一眼任务总览确认所有任务在过去七天都有成功记录有异常的重点看看是哪台机器每月核对一次容量趋势看看增长是不是符合预期如果某台机器的增量突然暴增比如原来每天 5GB突然变成 50GB大概率是它的业务发生了变化或者有人在灌数据需要去问清楚。6.2 升级带来的兼容性维护群晖的 DSM、ABB 套件、以及 Linux 端的 Agent三者的版本是有关联的。套件升级之后旧版 Agent 有可能连不上或者功能受限。所以我的做法是升级 NAS 侧套件之前先把 Agent 的安装包版本记下来升级完套件后逐个确认 Agent 是否还正常如果不兼容就滚动升级 Agent。规模大一点的环境可以考虑建一个内部的软件仓库把 Agent 包放进去装和升级都走统一来源避免每台机器上去官网重新下。Linux 侧的内核升级和 dattobd 的关系前面说过了这里再补一句如果用的是 Ubuntu 的无人值守升级或者 CentOS 的自动更新一定要确认 DKMS 在升级后能自动重编模块。多数情况下 DKMS 会自动做但也不是百分百定期跑一次dkms status看一眼比出事后再查便宜得多。6.3 和其他备份方案的组合使用ABB 不是万能的把它和别的方案组合起来用覆盖会更完整。我的常见组合是这样ABB 负责整机级保护管系统、分区、应用环境出大事能整机拉起来。数据库自身逻辑备份比如 mysqldump、pg_dump 或者物理备份工具每天导出一份到本地另一个目录再让 ABB 把整个目录备走。数据库出问题时用逻辑备份做单点恢复更快更准。关键配置用 Git 管理比如 nginx 配置、systemd 单元文件改动走版本控制回滚一条命令的事不用翻备份。异地一份冷备可以借 NAS 之间的复制能力把备份数据同步到另一台设备或者异地防止单点灾难。这套组合下来恢复路径就不止一条小问题查 Git数据问题用逻辑备份系统问题用 ABB 整机还原机房级问题靠异地副本。每条路径都演练过心里才踏实。最后分享一点个人体会。ABB 备份 Linux 这套东西技术门槛其实不高真正难的是习惯——把首次全量的窗口安排好、把内核升级和快照模块的联动记住、把告警接出去、把恢复演练排进日历。我在实际使用中发现那些真正出过事又救回来的环境共同点都不是用了多贵的方案而是有人认真做过演练、有人盯着告警。工具只是把这条路铺平了走不走还是在人。