初探Percona MongoDB增量备份

前言

最近在学习MongoDB相关知识，MongoDB集群数据小的时候可以通过自带的备份命令来处理，命令如下：

企业使用的最多的还是副本集群，副本集群一般通过全量备份+Oplog来实现，但是这里有一个问题，副本集群数据量如果有几T，全量备份的时间超过Oplog时间，备份节点再使用Oplog已经无法追上主节点数据。

这种场景下需要研究一下增量备份的方案，了解到percona这家厂商家有https://docs.percona.com/percona-backup-mongodb/features/backup-types.html

PBM测试

1.部署测试集群

#副本集群初始化
var cfg = {
     _id: "lilj_test",
     members: [
       {_id: 0, host: "th100:30017"},
       {_id: 1, host: "th101:30017"},
       {_id: 2, host: "th102:30017"}
     ]
   }

rs.reconfig(cfg, {force: true});

rs.status()

#还原节点初始化
rs.initiate({
_id: "lilj_test",
version: 1,
members: [
{ _id: 0, host: "localhost:30017" }
]
})

2.部署PBM

创建备份用户和赋予库操作权限，参考percona官方文档创建备份用户

打算往minio上写入备份文件，PMB的配置格式如下

storage:
  type: minio
  minio:
    region: ""
    endpoint: minio URL地址
    bucket: test-lilj
    prefix: pbm/backup
    credentials:
      access-key-id: '***'
      secret-access-key: '***'
    secure: false
    partSize: 10485760
    retryer:
      numMaxRetries: 10
    insecureSkipTLSVerify: false

#声明PBM_MONGODB_URI变量
export PBM_MONGODB_URI="mongodb://pbmuser:密码@127.0.0.1:30017/?authSource=admin"

#查看pbm状态，全部OK就可以了
./pbm status
Cluster:
========
lilj_test:
  - th100:30017 [S]: pbm-agent [v2.12.0] OK
  - th101:30017 [P]: pbm-agent [v2.12.0] OK
  - th102:30017 [S]: pbm-agent [v2.12.0] OK


PITR incremental backup:
========================
Status [OFF]
  
#启动agent  
./pbm-agent -f pbm_config.yaml  > pbm-agent.log 2>&1 &
  
#查看状态   
./pbm status

#测试连接s3
./pbm-speed-test  storage
Test started ................
1.00GB sent in 34s.
Avg upload rate = 30.20MB/s.

正常启动如果无法看到数据的话需要重新同步一下，具体命令如下所示：

./pbm config --file pbm_config.yaml --force-resync

3.增量备份

1、MongoDB集群初始状态下test下面只有orders和products两个表

2、先进行一次完全备份，执行下面的命令：

./pbm backup --type incremental --base

在副本集群运行pbm命令，会随机在一个节点启动备份进场，在th102 备份进程开启并上传数据，如日志所示：

在minio上可以看到提交的文件

使用阿里云千问模型分析日志，梳理流程图和关键环节

关键环节详细拆解（按时间线）

第二步，删除orders表

进行增量备份，操作命令如下：

./pbm backup --type incremental

pbm agentlog和minio信息如下：

使用阿里云千问模型分析日志，梳理流程图和关键环节

关键环节详细拆解（按时间线）

4.恢复测试

th103准备一个单独实例的副本集群，运行pbm list 可以看到在minio上存储的备份数据列表：

#进行恢复第一次全量备份测试
./pbm restore 2026-01-01T08:48:15Z

pbm-agent.log 日志如下

还原完成后MongoDB进程和 pbm-agent进程都退出，需要启动MongoDB进程。

使用阿里云千问模型分析日志，梳理流程图和关键环节

关键环节详细拆解（按时间线）

能看到还原了完整备份，proders和products表都在。

进行增量备份的恢复，每次还原之前需要确认pbm list可以看到备份列表信息。

#进行恢复第二次着增量备份测试
./pbm restore 2026-01-01T08:58:49Z

pbm-agent.log 日志如下

使用阿里云千问模型分析日志，梳理流程图和关键环节

关键环节详细拆解（按时间线）

还原完成后启动数据库，可以看到orders表不见了

留意点

需要注意MongoDB的版本和PBM版本的对应关系（PBM和MongoDB版本对应关系），版本特别低的MongoDB不支持增量备份。

MongoDB副本集群的升级可以参考下面的流程：

MongoDB副本集群程序升级后，新版本的二进制文件虽然已经运行，但为了保证兼容性和可回滚性，MongoDB 默认不会立即启用所有 4.4 的新特性。

这个“开关”就是通过 featureCompatibilityVersion（简称 fCV）来控制的。

MongoDB集群升级到7.0开启新版本特性支持，有一个提示：

MongoServerError[Location7369100]: Once you have upgraded to 7.0, you will not be able to downgrade FCV and binary version without support assistance. Please re-run this command with 'confirm: true' to acknowledge this and continue with the FCV upgrade.

这里是MongoDB 7.0 引入了一个不可逆升级警告（point of no return）：

⚠️ 一旦将 featureCompatibilityVersion 设置为 “7.0”，你就不能再降级回 6.0 或更早版本了！

即使你想回滚二进制文件或配置，也必须联系 MongoDB 官方技术支持才能完成降级 —— 否则会面临数据损坏风险。

写在最后

percona PBM 可以解决数据量在1T并且OPlog时间在3-7天的这种副本集群的增量备份需求，如果集群数据屋里存储达到2T以及以上并且Oplog时间较短，全量备份写入s3或者其他存储的时间很大概率会超过Oplog的时间，导致后面增量备份没有办法实现。

数据量很大最好的办法还是拆库拆表，升级为分片集群。但是分片集群的备份又带来很大的不确定性，各大云厂商还支持磁盘快照方式的备份，在MongoDB备份上还是基于实际情况进行规划最好。

受限于遇到和网上搜到的MongoDB信息整理完成，作为2026年技术分享第一篇。

祝大家新年马到成功！