企业官网建设流程全解析

群晖套件里的 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 端动手之前，花十分钟做一遍体检，能省掉后面几个小时的排障。需要确认的东西我用一张表列出来，照着走一遍就行。

这张表里最容易被跳过的是 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 -y

RHEL 系（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 if=abb-recovery.iso of=/dev/sdX bs=4M status=progress conv=fsync

这里的/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 端的问题，八成集中在快照模块和相关依赖上。按下面这个顺序查效率最高：

这张表里，我遇到频率最高的是第二条。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 这套东西，技术门槛其实不高，真正难的是"习惯"——把首次全量的窗口安排好、把内核升级和快照模块的联动记住、把告警接出去、把恢复演练排进日历。我在实际使用中发现，那些真正出过事又救回来的环境，共同点都不是用了多贵的方案，而是有人认真做过演练、有人盯着告警。工具只是把这条路铺平了，走不走还是在人。