# Leveraging MongoDB's native oplog applier for faster PBM PITR restores **URL:** \ **Category:** Percona Backup for MongoDB\ **Tags:** percona, mongodb, pbm\ **Created:** [October 7, 2026, 11:15am UTC](https://forums.percona.com/t/leveraging-mongodbs-native-oplog-applier-for-faster-pbm-pitr-restores/41318 "2026-10-07T11:15:02Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Daniel\_Osuntoyinbo](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/daniel_osuntoyinbo/32/22879_2.png) [@Daniel\_Osuntoyinbo](https://forums.percona.com/u/Daniel_Osuntoyinbo)\ **Post date:** [October 7, 2026, 11:15am UTC](https://forums.percona.com/t/leveraging-mongodbs-native-oplog-applier-for-faster-pbm-pitr-restores/41318/1 "2026-10-07T11:15:02Z")
Hi all, While testing replicaset PITR restores of multi-terrabyte mongodb clusters using PBM, I observed that PBM replays the oplog serially. PITR restore for a `4` hour window of oplog size of about `46GB` took `2+` days to complete. I patched PBM to apply the oplog in parallel using multiple threads. It did improve but not ideal as it took 24hrs to complete and cluster was mostly idle during the run. This performance profile matches what was reported in [PITR restore performance](https://forums.percona.com/t/pitr-restore-performance/40877) as there was no resource contraints on the cluster and it was mostly idle. Hardware specs was about 64k iops and io2 storage for the nodes. I have a PR in draft state currently that adds a `--native-pitr` option for PBM PITR restores built on `PBM 2.16.0` and `PSMDB v7`. Basically PBM appends the PITR window from the backup storage (S3 in my case) to the restored node’s oplog and mongod then replays it with its own multi-threaded applier during startup recovery. With this approach the whole restore (which includes the `4hr` PTR window) on a `12TB` cluster completed in `4hrs` while on an `8TB` cluster, `4Hr` oplog window with `5GB` oplog the restore completed in about `30` minutes. This excludes time for creating/initializing the volumes tho as that is a separate process. Data validation was done successfully as there was no missing data and accuracy was verified. Using this approach means there is no need for a separate `pbm oplog-replay` run after restoring the base snapshot as the PITR restore can now be completed in a single run when you run `pbm restore-finish` command. It currently supports replicasets only, I believe the same approach could be extended to sharded clusters. I would appreciate if this could be reviewed when i open the PR and any feedback on the approach would be welcome. ---
**Author:** ![Ivan\_Groenewold](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/ivan_groenewold/32/6299_2.png) [@Ivan\_Groenewold](https://forums.percona.com/u/Ivan_Groenewold)\ **Post date:** [October 8, 2026, 10:49am UTC](https://forums.percona.com/t/leveraging-mongodbs-native-oplog-applier-for-faster-pbm-pitr-restores/41318/2 "2026-10-08T10:49:11Z")
Hi Daniel, thank you so much for your contribution. Let’s keep comm in the PR you opened so we can get this merged. Thanks again