# PITR issue - oplog has insufficient range

**URL:** <https://forums.percona.com/t/pitr-issue-oplog-has-insufficient-range/29357>\
**Category:** Percona Backup for MongoDB\
**Tags:** closed-no-reply, pbm\
**Created:** [March 26, 2024, 12:41pm UTC](https://forums.percona.com/t/pitr-issue-oplog-has-insufficient-range/29357 "2024-03-26T12:41:23Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![peter.surovy](https://avatars.discourse-cdn.com/v4/letter/p/e9bcb4/32.png) [@peter.surovy](https://forums.percona.com/u/peter.surovy)\
**Post date:** [March 26, 2024, 12:41pm UTC](https://forums.percona.com/t/pitr-issue-oplog-has-insufficient-range/29357/1 "2024-03-26T12:41:23Z")

</div>

Hello.

We are using following MongoDB setup:

1. replica set consisting of three separate servers

2. each server is running MongoDB version 7.0.5-3

3. each server is running PBM agent version 2.4.0

4. environment is built from scratch, during the process a logical base backup is made and PITR is turned on

5. PITR is using these settings:  
pitr:  
enabled: true  
oplogSpanMin: 10  
compression: gzip  
compressionLevel: -1  
oplogonly: false

6. oplog size is approximately 1,5GB

7. logical base backup is made once every day

During the standard operation, PITR gathers chunks every 10 minutes based on configuration. Using “pbm status” command we see something like this:  
“Backups:”,  
“========”,  
“S3 local s3://http:xxxxxxxxxxxxxxxxxxxxxxxxx”,  
" Snapshots:“,  
" 2024-03-25T07:33:03Z 292.33KB \<incremental, base\> [restore\_to\_time: 2024-03-25T07:33:11Z]”,  
" PITR chunks [3.07GB]:“,  
" 2024-03-25T07:33:12Z - 2024-03-25T10:33:24Z”

But we have come across following situation:

1. during 10 minute PITR window there’s a large data write to the DB resulting into whole oplog being filled and rotated
2. when PITR is about to create new chunk, it detects, that whole oplog has rotated and fails with following error:

2024-03-25T10:43:17Z E [xxxx] [pitr] streaming oplog: oplog has insufficient range, some records since the last saved ts {17  
11362804 17} are missing. Run `pbm backup` to create a valid starting point for the PITR

Okay, makes sense - PITR has lost track of some records within the 10 minute span.  
How do we make it work again? We have created new base backup, shouldn’t PITR automatically start new chunk chain? See example below:

“Backups:”,  
“========”,  
“S3 local s3://http:xxxxxxxxxxxxxxxxxxxxxxxxx”,  
" Snapshots:“,  
" 2024-03-25T11:46:13Z 3.88GB \<incremental, base\> [restore\_to\_time: 2024-03-25T11:46:20Z]”, **– we made a new backup here**  
" 2024-03-25T07:33:03Z 292.33KB \<incremental, base\> [restore\_to\_time: 2024-03-25T07:33:11Z]“,  
" PITR chunks [3.07GB]:”,  
" **shouldn’t new chunk chain start here using 2024-03-25T11:46:13Z backup? " – shouldn’t new chain start here?**  
" 2024-03-25T07:33:12Z - 2024-03-25T10:33:24Z"

PITR keeps failing with the same exception, unbothered that there is new base available. Is this expected behaviour? We’d expect a new chunk chain to start.

Thank you for your comments.

---

<div class="post-metadata">

**Author:** ![Sandra\_Romanchenko](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/sandra_romanchenko/32/84_2.png) [@Sandra\_Romanchenko](https://forums.percona.com/u/Sandra_Romanchenko)\
**Post date:** [August 19, 2024, 1:25pm UTC](https://forums.percona.com/t/pitr-issue-oplog-has-insufficient-range/29357/2 "2024-08-19T13:25:14Z")

</div>

Hi,

You’re right, there is an issue on PBM side which will be addressed within [PBM-1344](https://perconadev.atlassian.net/browse/PBM-1344) in the upcoming PBM release.

Also for PBM to be able to save oplog between backups, I’d suggest you either [increase the oplog size](https://docs.mongodb.com/manual/tutorial/change-oplog-size/) on server side, or decrease [oplogSpanMin](https://docs.percona.com/percona-backup-mongodb/reference/pitr-options.html?h=oplog+span+min#pitroplogspanmin) interval on PBM side.