# Question: oplogOnly removal in PBM 3.0 ? Is that for real or joke?

**URL:** <https://forums.percona.com/t/question-oplogonly-removal-in-pbm-3-0-is-that-for-real-or-joke/39819>\
**Category:** Percona Backup for MongoDB\
**Created:** [December 2, 2025, 2:40pm UTC](https://forums.percona.com/t/question-oplogonly-removal-in-pbm-3-0-is-that-for-real-or-joke/39819 "2025-12-02T14:40:24Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Henryx](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/henryx/32/13625_2.png) [@Henryx](https://forums.percona.com/u/Henryx)\
**Post date:** [December 2, 2025, 5:29pm UTC](https://forums.percona.com/t/question-oplogonly-removal-in-pbm-3-0-is-that-for-real-or-joke/39819/4 "2025-12-02T17:29:42Z")

</div>

And one more thing if I might suggest.. I also documented our observation on oplog-replay (during reconciliation tests to validate snaps + oplogs consistency in our recovery strategy) the current issue with how PBM ensures consistency / precision in regards to timestamps.

From our point of view it would be not just “nice to have” but inherently logical, to treat oplog-replay surgically. By this I mean that –start / –end should not rely on seconds and truncate ‘increment’ positions. In our cases with oplog-heavy instances, there might be thousands of operations in the single exact second (epoch timestamp). Hence we observed the inconsistent result due to not being able to tell the oplog-replay at which exact operation-position to stop, while processing oplog chunks.  
Oracle ensures that level of consistency by using it’s own sequencing mechanism for all operations. Unfortunately mongo operates in unix epoch + increments..

> [@Pbm oplog-replay skips entire endpoint second; --end timestamp behaves inconsistently (PBM 2.12.0) | failing reconciliation tests](https://forums.percona.com/t/pbm-oplog-replay-skips-entire-endpoint-second-end-timestamp-behaves-inconsistently-pbm-2-12-0-failing-reconciliation-tests/39816/2):
>
> Just for more clarification… we do external snapshot based PITR recovery from consistent snapshot being “captured” while DB was in opened backup-cursor “backupReady” state. We utilise enterprise features of HDD hypervisor or something… which captures guaranteed consistent snapshot to the point in time. afterwards when DBs (X-1 - Target db) and (X - Reference db for reconciliation) are started, endPoint timestamps resulting from WT recovery are captured and used in later phase for PITR oplog-re…

---

_[View the full topic](https://forums.percona.com/t/question-oplogonly-removal-in-pbm-3-0-is-that-for-real-or-joke/39819)._