# Plans for better handling of pod restarts affect on in progress backup?

**URL:** <https://forums.percona.com/t/plans-for-better-handling-of-pod-restarts-affect-on-in-progress-backup/26413>\
**Category:** Percona Backup for MongoDB\
**Tags:** closed-no-reply, kubernetes\
**Created:** [November 7, 2023, 7:43pm UTC](https://forums.percona.com/t/plans-for-better-handling-of-pod-restarts-affect-on-in-progress-backup/26413 "2023-11-07T19:43:50Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![dmn](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/dmn/32/6170_2.png) [@dmn](https://forums.percona.com/u/dmn)\
**Post date:** [November 7, 2023, 7:43pm UTC](https://forums.percona.com/t/plans-for-better-handling-of-pod-restarts-affect-on-in-progress-backup/26413/1 "2023-11-07T19:43:50Z")

</div>

Are there plans to bring this [epic](https://jira.percona.com/browse/PBM-46) up in priority? Our k8s environment is a managed platform where nodes coming in and out is a normal occurrence. Mongo handles this gracefully but for our larger clusters where a backup job can take upwards of 10hrs, the whole job fails. I can file a jira ticket with some logs I’ve captured when this happens, the gist is a pod restarts that happens to be hosting the pbm-agent running the backup for that rs. The other pbm agents dont understand that this happened, and the error message contains nil for the reason of failure.

Maybe if pbm-agent could take the termination signal and send a message somewhere, it could restart when it returns? Or start a backup on both secondaries and pick a winner?