跨网络复制现有LVM（XFS文件系统）：双生产服务器灾备方案咨询

根据你的环境（两台CentOS 6生产节点，不同容量的LVM/XFS存储，搭配10G网络的CentOS 7备份节点），我整理了几个适配不同需求的方案，从一次性全量备份到近实时同步，你可以根据业务对数据一致性的要求来选：

方案1：一次性全量复制 + 定期增量同步（适合非实时备份需求） #

如果你的业务不需要实时同步，只是定期做数据备份，这个方案最省心，依赖的都是系统自带工具，不需要额外折腾。

具体操作步骤 #

• 先在备份服务器上搭建对应的存储结构：你需要创建和生产节点匹配的LVM逻辑卷（也可以把所有生产数据放到一个大LV里，看后续管理习惯）。比如备份服务器用/dev/sdb做存储：

  # 创建物理卷
  pvcreate /dev/sdb
  # 创建卷组（命名为Backup_VG）
  vgcreate Backup_VG /dev/sdb
  # 给Prod_serv1的第一个LV创建对应大小的逻辑卷（假设原LV是10TB）
  lvcreate -L 10TB -n Prod1_LV1 Backup_VG
  # 格式化为XFS（和生产一致）
  mkfs.xfs /dev/Backup_VG/Prod1_LV1
  # 挂载到指定目录
  mkdir /mnt/Prod1_LV1
  mount /dev/Backup_VG/Prod1_LV1 /mnt/Prod1_LV1
  

• 全量备份：用XFS原生的xfsdump/xfsrestore工具，远程备份比先本地存储再传输更高效，还能加压缩节省带宽：

  # 在Prod_serv1上，把LV1的内容远程备份到备份服务器的挂载点
  xfsdump -J - /dev/Prod_VG/LV1 | ssh root@Backup_Serv "xfsrestore -J - /mnt/Prod1_LV1"
  

  这里-J是启用LZ压缩，10G网络虽然快，但压缩能减少传输时间，尤其对大文件友好。
• 增量同步：全量完成后，每天（或按需求频率）用rsync同步变化的文件：

  rsync -avz --delete /mnt/Prod1_LV1/ root@Backup_Serv:/mnt/Prod1_LV1/
  

  --delete参数会让备份端和生产端保持完全一致，注意如果生产端有删除操作，备份端也会同步删除，谨慎使用。

方案利弊 #

优点：

• 操作门槛低，依赖系统原生工具，无需额外部署软件
• 对生产节点资源占用极低，可在业务低峰期执行
• 备份逻辑清晰，易于排查问题

缺点：

• 存在数据备份窗口，无法实现实时同步
• 首次全量备份耗时较长（40TB数据大概10-12小时，取决于实际网络速度）

方案2：块级实时同步（近高可用级备份，适合实时数据保护需求） #

如果你的业务要求数据尽量少丢失，接近高可用的备份级别，块级实时同步是更好的选择。这里推荐用DRBD（Distributed Replicated Block Device），它能实现块级的实时镜像，跨CentOS 6和7版本也能兼容（注意选对DRBD版本）。

具体操作步骤 #

1. 先在备份服务器上创建和生产节点完全相同大小的LV，格式化为XFS（和生产一致）。
2. 安装DRBD：CentOS 6用EPEL源的drbd84-utils，CentOS 7可以装drbd9-utils或者兼容的8.4版本，确保两边版本匹配。
3. 配置DRBD资源：每个生产LV对应一个DRBD资源，比如针对Prod_serv1的LV1，创建配置文件/etc/drbd.d/prod1_lv1.res：

   resource prod1_lv1 {
       protocol C;  # 同步写，确保生产端写完后备份端也确认
       meta-disk internal;  # 元数据存在LV内部
       device /dev/drbd0;  # DRBD设备名
       on Prod_serv1 {
           disk /dev/Prod_VG/LV1;  # 生产端的LV路径
           address 192.168.1.10:7789;  # 生产端的10G网卡IP和端口
       }
       on Backup_Serv {
           disk /dev/Backup_VG/Prod1_LV1;  # 备份端的对应LV路径
           address 192.168.1.30:7789;  # 备份端的10G网卡IP和端口
       }
   }
   

4. 初始化并启动DRBD：

   # 两边节点都执行，初始化元数据
   drbdadm create-md prod1_lv1
   # 启动DRBD服务
   # CentOS6: service drbd start
   # CentOS7: systemctl start drbd
   # 在生产端设置为主节点，开始同步
   drbdadm primary prod1_lv1
   

5. 同步完成后，DRBD会实时复制所有块级变化到备份服务器，生产端的任何写入都会同步到备份端。

如果你觉得DRBD配置太复杂，也可以用inotifywait+rsync实现文件级实时同步，适合文件变化频繁但块级变化少的场景：

# 先在生产端安装inotify-tools
yum install inotify-tools -y
# 编写实时同步脚本
while inotifywait -r -e modify,create,delete,move /mnt/Prod1_LV1/; do
    rsync -avz --delete /mnt/Prod1_LV1/ root@Backup_Serv:/mnt/Prod1_LV1/
done

把这个脚本后台运行或者加到开机启动，就能实现文件变化时自动同步。

方案利弊 #

优点：

• 实现实时/近实时同步，数据丢失风险极低
• 块级同步对大文件、大数量文件的同步效率远高于文件级工具
• DRBD支持故障切换（如果需要），可以快速将备份端切换为生产端

缺点：

• DRBD配置相对复杂，需要跨版本兼容调试
• 实时同步会占用一定10G网络带宽（但10G足够支撑大部分场景）
• 生产端会有轻微的IO负载增加

方案3：LVM快照+增量备份（平衡效率和复杂度的中间方案） #

如果既不想做全量备份的长时间等待，又不需要完全实时的同步，LVM快照+增量备份是不错的选择。利用LVM快照的特性，只备份两次备份之间变化的数据。

具体操作步骤 #

1. 在生产端创建LVM快照：快照只记录变化的块，所以不需要和原LV一样大，根据数据变化量预留空间即可（比如原LV是10TB，预留1TB快照空间）：

   lvcreate -s -L 1TB -n LV1_Snap /dev/Prod_VG/LV1
   

2. 挂载快照并备份：

   mkdir /mnt/LV1_Snap
   mount /dev/Prod_VG/LV1_Snap /mnt/LV1_Snap
   # 用rsync备份快照内容到备份端
   rsync -avz /mnt/LV1_Snap/ root@Backup_Serv:/mnt/Prod1_LV1/
   # 备份完成后卸载并删除快照，避免占用空间
   umount /mnt/LV1_Snap
   lvremove -f /dev/Prod_VG/LV1_Snap
   

3. 定期执行这个快照备份任务（比如每天一次），每次只同步上一次备份后变化的数据。

方案利弊 #

优点：

• 减少全量备份的频率，节省带宽和时间
• 快照创建几乎瞬间完成，对生产端负载影响极小
• 备份逻辑清晰，易于验证和恢复

缺点：

• 存在备份窗口，数据丢失风险取决于备份间隔
• 快照需要预留足够空间，否则数据变化过多会导致快照损坏失效

通用注意事项 #

不管你选哪个方案，这些点一定要注意：

• 版本兼容性：CentOS 6和7的XFS是完全兼容的，xfsdump/xfsrestore跨版本使用没有问题，但建议保持工具版本尽量接近。
• 数据验证：备份完成后一定要验证数据完整性，比如对比关键文件的MD5值，或者挂载备份LV检查内容是否完整。
• 自动化与监控：把备份任务加到crontab定时执行，用监控工具（比如Zabbix）监控备份状态，避免备份失败没人发现。
• 网络规划：尽量用10G网卡专门做备份传输，避免影响业务流量；如果是跨机房，注意网络延迟对同步的影响。

内容的提问来源于stack exchange，提问作者Cristian Ion