# Restore to new environment with Operator 1.16.0 and mongo v7 **URL:** \ **Category:** Percona Operator for MongoDB\ **Tags:** mongodb, psmdb-operator\ **Created:** [June 25, 2024, 3:54am UTC](https://forums.percona.com/t/restore-to-new-environment-with-operator-1-16-0-and-mongo-v7/31209 "2024-06-25T03:54:30Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Vivek\_Shinde](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/vivek_shinde/32/15778_2.png) [@Vivek\_Shinde](https://forums.percona.com/u/Vivek_Shinde)\ **Post date:** [June 25, 2024, 3:54am UTC](https://forums.percona.com/t/restore-to-new-environment-with-operator-1-16-0-and-mongo-v7/31209/1 "2024-06-25T03:54:30Z")
HI All, I am facing an issue when trying to restore backup of psmdb v7 (with operator 1.16.0) on new kubernetes setup. (with same secret of psmdb users). Same backup works well when restore on same setup where backup is taken. I see problem on restore - mongos and config servers are continously restarting with below error. Anyone have any idea if there is something missing for restoring backup to new setups? {“t”:{“$date”:“2024-06-24T05:49:27.619+00:00”},“s”:“E”, “c”:“ASSERT”, “id”:4457000, “ctx”:“CatalogCache-0”,“msg”:“Tripwire assertion”,“attr”:{“error”:{“code”:6493100,“codeName”:“Location6493100”,“errmsg”:“**Time monotonicity violation: lookup time { chunkVersion: { e: ObjectId(‘6674055e88af34e862123419’), t: Timestamp(1718879582, 9), v: Timestamp(1, 2) }, forcedRefreshSequenceNum: 27, epochDisambiguatingSequenceNum: 42 } which is less than the earliest expected timeInStore { chunkVersion: { e: ObjectId(‘667901f96cb45948937c6ab4’), t: Timestamp(1719206393, 18), v: Timestamp(1, 1) }, forcedRefreshSequenceNum: 27, epochDisambiguatingSequenceNum: 41 }.**”},“location”:“{fileName:"src/mongo/util/read\_through\_cache.h", line:549, functionName:"operator()"}”}} {“t”:{“$date”:“2024-06-24T05:49:29.225+00:00”},“s”:“I”, “c”:“ASSERT”, “id”:4457002, “ctx”:“CatalogCache-0”,“msg”:“Detected prior failed tripwire assertions, please check your logs for "Tripwire assertion" entries with log id 4457000.”,“attr”:{“occurrences”:1}} ---
**Author:** ![Vitaliy\_Yablonskiy](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/vitaliy_yablonskiy/32/17240_2.png) [@Vitaliy\_Yablonskiy](https://forums.percona.com/u/Vitaliy_Yablonskiy)\ **Post date:** [July 9, 2024, 9:21am UTC](https://forums.percona.com/t/restore-to-new-environment-with-operator-1-16-0-and-mongo-v7/31209/2 "2024-07-09T09:21:59Z")
It happening because in first you made a fresh cluster with its own topologyTime which is newer that topologyTime in your backup. Even one second is a big difference. Percona documentation states that you need to stop mongos (router service) before restoring by yourself. It’s crucial in mongodb 7 because difference in topologyTime causes critical error and mongos service is the one who remembers this new topologyTime. tl; dr - you need to stop all mongos before restore. Not sure how the operator works but this is the cause. ---
**Author:** ![mbahmanzad](https://avatars.discourse-cdn.com/v4/letter/m/bc8723/32.png) [@mbahmanzad](https://forums.percona.com/u/mbahmanzad)\ **Post date:** [February 14, 2025, 2:29pm UTC](https://forums.percona.com/t/restore-to-new-environment-with-operator-1-16-0-and-mongo-v7/31209/3 "2025-02-14T14:29:26Z")
@Vivek_Shinde I am experinceing the same issue, could you find a way to fix it? Note: Operator stops the mongos pods before any restore. ---
**Author:** ![ldn87g](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/ldn87g/32/21181_2.png) [@ldn87g](https://forums.percona.com/u/ldn87g)\ **Post date:** [June 4, 2025, 7:53am UTC](https://forums.percona.com/t/restore-to-new-environment-with-operator-1-16-0-and-mongo-v7/31209/4 "2025-06-04T07:53:44Z")
I have the same problem. My problem was with collection system.sessions db config. When you create new configdb and add the same shard? this collection shard to the same shard from recovery. You can check state db.adminCommand( { checkMetadataConsistency: 1 } ) cursor: { id: Long(‘0’), ns: ‘admin.$cmd.aggregate’, firstBatch: [ { type: ‘CollectionUUIDMismatch’, description: ‘Found collection on non primary shard with mismatching UUID’, details: { namespace: ‘config.system.sessions’, shard: ‘rs0-shard02’, localUUID: UUID(‘3fbc4f82-dd15-4484-99a4-f722a59722d2’), uuid: UUID(‘5ab453db-15ee-446b-99d9-33c5c73e1699’) } } ] }, so you need first add shard another name first, then restore, then drop this collection new place ---
**Author:** ![Vinodh\_Krishnaswamy](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/vinodh_krishnaswamy/32/46_2.png) [@Vinodh\_Krishnaswamy](https://forums.percona.com/u/Vinodh_Krishnaswamy)\ **Post date:** [June 25, 2025, 8:01am UTC](https://forums.percona.com/t/restore-to-new-environment-with-operator-1-16-0-and-mongo-v7/31209/5 "2025-06-25T08:01:51Z")
Hi Guys, > [@Vivek\_Shinde](#): > > Time monotonicity violation it is reported as bug in JIRA as mentioned here - [K8SPSMDB-1336](https://perconadev.atlassian.net/browse/K8SPSMDB-1336). You can check this comment on what is happening behind this error - [PBM-1487-Comment](https://perconadev.atlassian.net/browse/PBM-1487?focusedCommentId=425263). The fix is expected with the release of PBM v2.10.0. Please subscribe to the bug for receiving any further updates on it. Regards, Vinodh Guruji ---
**Author:** ![dasol](https://avatars.discourse-cdn.com/v4/letter/d/ed655f/32.png) [@dasol](https://forums.percona.com/u/dasol)\ **Post date:** [July 3, 2025, 12:09pm UTC](https://forums.percona.com/t/restore-to-new-environment-with-operator-1-16-0-and-mongo-v7/31209/6 "2025-07-03T12:09:13Z")
Hello. I’m experiencing the same issue, so I upgraded the PBM to version 2.9.1 -\>2.10, but the error doesn’t go away. i am performing a logical backup on a Shard cluster and restoring it on another server. The restore ends in success, but the mongos service goes down every 5 minutes, and you can see the following error message in the mongos’ log file: pbm version 2.10 and mongodb version 8.0.4. How can we do that? msg":“Tripwire assertion”,“attr”:{“error”:{“code”:6493100,“codeName”:“Location6493100”,“errmsg”:“Time monotonicity violation: lookup time { chunkVersion: { e: ObjectId(‘683017aec543eb7413a60cf5’), t: Timestamp(1747982254, 15), v: Timestamp(1, 0) }, forcedRefreshSequenceNum: 17, epochDisambiguatingSequenceNum: 18 } which is less than the earliest expected timeInStore “location”:”{fileName:"src/mongo/util/read\_through\_cache.h", line:609, functionName:"operator()"}"} ---
**Author:** ![oleksandr.havryliak](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/oleksandr.havryliak/32/5703_2.png) [@oleksandr.havryliak](https://forums.percona.com/u/oleksandr.havryliak)\ **Post date:** [July 4, 2025, 11:31am UTC](https://forums.percona.com/t/restore-to-new-environment-with-operator-1-16-0-and-mongo-v7/31209/7 "2025-07-04T11:31:52Z")
Hi @dasol ! Could you, please, share us with pbm logs. ```auto pbm logs -sD -t0 ``` ---
**Author:** ![Slava\_Sarzhan](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/slava_sarzhan/32/3196_2.png) [@Slava\_Sarzhan](https://forums.percona.com/u/Slava_Sarzhan)\ **Post date:** [July 8, 2025, 9:35am UTC](https://forums.percona.com/t/restore-to-new-environment-with-operator-1-16-0-and-mongo-v7/31209/9 "2025-07-08T09:35:01Z")
@dasol We have reproduced it and created the task [Jira](https://perconadev.atlassian.net/browse/PBM-1583) to fix it.