# Try to delete backups from pbm, but failed in not founding file or directory.

**URL:** <https://forums.percona.com/t/try-to-delete-backups-from-pbm-but-failed-in-not-founding-file-or-directory/7751>\
**Category:** Percona Backup for MongoDB\
**Created:** [July 7, 2020, 9:21pm UTC](https://forums.percona.com/t/try-to-delete-backups-from-pbm-but-failed-in-not-founding-file-or-directory/7751 "2020-07-07T21:21:35Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ccccc\_Cora](https://avatars.discourse-cdn.com/v4/letter/c/6f9a4e/32.png) [@Ccccc\_Cora](https://forums.percona.com/u/Ccccc_Cora)\
**Post date:** [July 7, 2020, 9:21pm UTC](https://forums.percona.com/t/try-to-delete-backups-from-pbm-but-failed-in-not-founding-file-or-directory/7751/1 "2020-07-07T21:21:35Z")

</div>

![](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/1X/069c5785a785b841dd834339f7ba281426f85c9e.jpeg "Image: /uploads/percona1/original/1X/069c5785a785b841dd834339f7ba281426f85c9e.jpeg")  
  
As shown above, we started backup using remote filesystem server storage, everything goes fine, except trying to delete old backups. What should i do to fix this issue?&nbsp;  
  
Thanks in advance.

---

<div class="post-metadata">

**Author:** ![Akira\_Kurogane](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/akira_kurogane/32/1280_2.png) [@Akira\_Kurogane](https://forums.percona.com/u/Akira_Kurogane)\
**Post date:** [July 14, 2020, 8:07am UTC](https://forums.percona.com/t/try-to-delete-backups-from-pbm-but-failed-in-not-founding-file-or-directory/7751/2 "2020-07-14T08:07:42Z")

</div>

Hi Cora.  
The PBM list of backups are not refreshed against the remote files every operation; they’re cached in a PBM control collection. It seems the remote files were already removed, and PBM has a bug here. The delete-backup subcommand should see missing files as being a warning situation as most; not an error.  
Could you please open a new ticket at [jira.percona.com](http://jira.percona.com) in the&nbsp;[https://jira.percona.com/projects/PBM/](https://jira.percona.com/projects/PBM/ "Link: https://jira.percona.com/projects/PBM/")&nbsp;project? And include that screenshot and version no. etc.?  
Thanks,  
Akira

---

<div class="post-metadata">

**Author:** ![Akira\_Kurogane](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/akira_kurogane/32/1280_2.png) [@Akira\_Kurogane](https://forums.percona.com/u/Akira_Kurogane)\
**Post date:** [July 14, 2020, 8:14am UTC](https://forums.percona.com/t/try-to-delete-backups-from-pbm-but-failed-in-not-founding-file-or-directory/7751/3 "2020-07-14T08:14:12Z")

</div>

For something you can do now: the following command will resync the list of backups based on what is found in the remote storage:

```auto
pbm config --force-resync

```

---

<div class="post-metadata">

**Author:** ![Ccccc\_Cora](https://avatars.discourse-cdn.com/v4/letter/c/6f9a4e/32.png) [@Ccccc\_Cora](https://forums.percona.com/u/Ccccc_Cora)\
**Post date:** [July 15, 2020, 8:45pm UTC](https://forums.percona.com/t/try-to-delete-backups-from-pbm-but-failed-in-not-founding-file-or-directory/7751/4 "2020-07-15T20:45:54Z")

</div>

Thanks for the reply. As you mentioned, ‘It seems the remote files were already removed’, &nbsp;that is not what i am facing. The backup files are still there and the delete-backup command did not remove the history files at all , just like does nothing, but returns error message, not like what you said.  
  
Another, using&nbsp;–force-resync, all the meta data in the collection&nbsp;pbmBackups is lost. I checked the db in mongo, and found that the command renamed the collection ,which is also not what i want.

---

<div class="post-metadata">

**Author:** ![Akira\_Kurogane](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/akira_kurogane/32/1280_2.png) [@Akira\_Kurogane](https://forums.percona.com/u/Akira_Kurogane)\
**Post date:** [July 15, 2020, 9:02pm UTC](https://forums.percona.com/t/try-to-delete-backups-from-pbm-but-failed-in-not-founding-file-or-directory/7751/5 "2020-07-15T21:02:08Z")

</div>

This sounds as though the configured storage is not pointing to the place it once did, or the credentials (eg. AWS secret key) are no longer working.  
What is the storage configuration in this case?

---

<div class="post-metadata">

**Author:** ![Ccccc\_Cora](https://avatars.discourse-cdn.com/v4/letter/c/6f9a4e/32.png) [@Ccccc\_Cora](https://forums.percona.com/u/Ccccc_Cora)\
**Post date:** [July 17, 2020, 1:01am UTC](https://forums.percona.com/t/try-to-delete-backups-from-pbm-but-failed-in-not-founding-file-or-directory/7751/6 "2020-07-17T01:01:15Z")

</div>

We set up a nfs server and mount remote filesystem disk to local to back up the DB. Are there some limitations on&nbsp;remote filesystem server storage? Here are the screenshots of the mounting case, on three machines, three different nfs locations, but same mounting point.  
 ![]()

 ![](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/1X/484fb3b26a8bfeb80e3c59b197b8d1212d2898ff.jpeg "Image: /uploads/percona1/original/1X/484fb3b26a8bfeb80e3c59b197b8d1212d2898ff.jpeg") ![](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/1X/cd6adb262ec3d276e5432e1c553db2f0ea26d993.jpeg) ![](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/1X/5bf3c5e2296ea3b8de358c30da4d1ecd7abb5501.jpeg "Image: /uploads/percona1/original/1X/5bf3c5e2296ea3b8de358c30da4d1ecd7abb5501.jpeg")

---

<div class="post-metadata">

**Author:** ![Akira\_Kurogane](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/akira_kurogane/32/1280_2.png) [@Akira\_Kurogane](https://forums.percona.com/u/Akira_Kurogane)\
**Post date:** [July 17, 2020, 1:22am UTC](https://forums.percona.com/t/try-to-delete-backups-from-pbm-but-failed-in-not-founding-file-or-directory/7751/7 "2020-07-17T01:22:29Z")

</div>

The remote directory that is mounted at the same path must be the same remote filesystem directory. I.e. in this case it should be one NFS location mapped to three different servers at the same mountpoint. As there is only one copy of the data for the replicaset, whether it is a single-node one, triple-node, or larger.  
I think what has happened until now is that the files have been saved in (to pick one for an example) location 47. But the pbm-agent nodes that won the ‘race’ to take the lock for later commands (pbm delete-backup and pbm config --force-resync) were one of the ones with the other NFS locations 48 or 49.
