# fsyncLock on csrs secondary for backup cause query timeout issue

**URL:** <https://forums.percona.com/t/fsynclock-on-csrs-secondary-for-backup-cause-query-timeout-issue/15462>\
**Category:** Percona Server for MongoDB\
**Created:** [April 28, 2022, 5:23pm UTC](https://forums.percona.com/t/fsynclock-on-csrs-secondary-for-backup-cause-query-timeout-issue/15462 "2022-04-28T17:23:27Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![xora](https://avatars.discourse-cdn.com/v4/letter/x/59ef9b/32.png) [@xora](https://forums.percona.com/u/xora)\
**Post date:** [April 28, 2022, 5:23pm UTC](https://forums.percona.com/t/fsynclock-on-csrs-secondary-for-backup-cause-query-timeout-issue/15462/1 "2022-04-28T17:23:27Z")

</div>

For some reason, we want have full and incremental backup to support point in time restore, so we’ve follow the mongodb official doc to do backup for sharded cluster , but when we lock a secondary of config server to do mongodump, it would cause query timeout in production, something related to “uptime reporter” which is refreshing config setting with a majority read , but isn’t fsyncLock only lock writes ? i don’t get it , can anyone expain why it will cause production query timeout , is it a block method that would block all the query to the cluster ? what if we does not lock config but just lock shard secondary for backup ?  
Plus, no exact point in time backup needed, just almost point in time backup is enough for us.

> **[Back Up a Sharded Cluster with Database Dumps - MongoDB Manual v7.0](https://www.mongodb.com/docs/v3.6/tutorial/backup-sharded-cluster-with-database-dumps/)**

---

<div class="post-metadata">

**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:** [May 2, 2022, 2:04pm UTC](https://forums.percona.com/t/fsynclock-on-csrs-secondary-for-backup-cause-query-timeout-issue/15462/2 "2022-05-02T14:04:48Z")

</div>

fsynclock a single secondary shouldn’t be a problem as long as you have other 2 functioning nodes… in any case I suggest you give a try to [Percona Backup for MongoDB](https://docs.percona.com/percona-backup-mongodb/) which will automatically backup the sharded cluster for you