mirror of
https://github.com/eduardolat/pgbackweb.git
synced 2026-04-25 05:35:57 +03:00
[GH-ISSUE #50] Retention timer not work #39
Labels
No labels
bug
confirmed next step
duplicate
enhancement
help wanted
in progress
in progress
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/pgbackweb#39
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SmartHome2021 on GitHub (Oct 8, 2024).
Original GitHub issue: https://github.com/eduardolat/pgbackweb/issues/50
Hi, I'm having some problems with auto-deleting old archives.
During the setup process, I experimented with the time of the auto-delete value, it seems that this does not affect anything.
At the moment, I have the following parameters set:
cloud backup - 30 days
local backup - 3 days
Despite this, local backups have been stored since 19.09, for 19 days now.
I periodically delete them myself, but this is not the experience I would like to have
I will be glad of any advice. Thanks
@Stitch10925 commented on GitHub (Oct 13, 2024):
I am seeing the same problem. I have a fairly big database of around 3 GB that holds non-crucial data. As such I have set the retention to 2 days. However, the backup folder for the database has now grown to 21 GB. When looking into the folders I can indeed see that some old versions are not being deleted.
@SmartHome2021 commented on GitHub (Oct 17, 2024):
I almost understood what was going on. The Docker container logs show that the deletion is trying to work, but there is a problem with the file path. .
{"time":"2024-10-17T15:10:00.014281114+03:00","level":"ERROR","msg":"error soft deleting expired executions","error":"failed to delete file /backups/backups/billing////
It remains to understand why this happened
UPD. this file was deleted by me on my own, the file cannot be found because it is not there.
2 backups with the success status are stuck in the completed ones. now there is no way to delete them even from the web. It seems that this causes the cause
@Stitch10925 commented on GitHub (Oct 18, 2024):
I also have a backup in the database of which the file does not exist anymore (because I changed the file structure). When the cron job runs it seems to fail on that one file and stop, so other backups from other databases are not cleaned up.
I also cannot manually delete the file, since I get the error that the file does not exist anymore. There seems to be no way to delete the database entry.
Why not simply delete the database entry when a "delete" is tried but the file does not exist anymore?
@SmartHome2021 commented on GitHub (Oct 18, 2024):
Try to create a text file using the path specified in the error , for example: backup_name.zip . In theory, this will be enough for the system to see the file and send it. Naturally, the name must match the name of the deleted file
Unfortunately, the situation is more complicated for me, I made a mistake in the installation and I have the first phantom backup stored on the path :
/backups/backups/billing/<destination-directory>/<YYYY>/<MM>/<DD>/dump-<random-suffix>.zip/2024/09/17/dump-20240917-142336-01bd3366-3296-438d-958d-db0f36152afe.zipThe < symbol causes an error and the system cannot delete the file, even though I was late all the way.
Such characters should be escaped with the \ character, then everything works correctly.
I hope this error will be noticed by the developer and he will tell you what to do
@SmartHome2021 commented on GitHub (Oct 21, 2024):
I have solved this problem, and I am giving you a solution.
sudo docker psto display the list of containerscontainer_idof the container that is responsible for the database (image postgres:*)sudo docker exec -it command (your copied id) bashI have this :
sudo docker exec -it 004891c02e6b bash5.
psql -U postgres- let's connect to the database setupSELECT datname FROM pg_database;- getting a list of databases\connect pgbackweb- connecting to the database8.
\dt- getting a list of tables in the current databaseSELECT * FROM executions;- getting the contents of the tableDELETE FROM executions WHERE path ='(copied path)'commandIt looks like this for me :
DELETE FROM executions WHERE path = 'backups/billing/<destination-directory>/<YYYY>/<MM>/<DD>/dump-<random-suffix>.zip/2024/09/17/dump-20240917-142336-01bd3366-3296-438d-958d-db0f36152afe.zip'PROFIT! There is no need to reboot anything, we wait 10 minutes and open the catalog. The old versions have been deleted.
@TristisOris commented on GitHub (Feb 6, 2025):
But retention still not working. I have 3 months old dumps, with 7days rule.
@Stitch10925 commented on GitHub (Feb 6, 2025):
I am also still seeing delete errors despite having gone through and manually deleting the files that were giving errors recently:
I also saw a permission issue to delete the files, but I haven't seen it recently. So I'm not quite sure what is going on.
@eduardolat commented on GitHub (Feb 6, 2025):
let me take a look
@eduardolat commented on GitHub (Feb 6, 2025):
@Stitch10925 Can you please verify in your file system if the files in the logs exists?
@Stitch10925 commented on GitHub (Feb 7, 2025):
@eduardolat
Yes, the files exist. When I manually delete them, the error goes away.
@Stitch10925 commented on GitHub (Feb 7, 2025):
Maybe to give a bit more context, at least in my case:
I use an NFS volume mount to my NAS to mount the directory where the backups are stored. Writing always seems to work, but removing seems to be an issue, even though manually deleting the files has never been a problem.
Hmm, I just realized, maybe something is changing the permissions of the files causing issues with the deletion, I will have to check that this weekend 🤔
@hellofaduck commented on GitHub (May 26, 2025):
I have same problem on local mounted ext4 drive, i can login into the container and delete files with rm command. I think there is a problem with manually deleted files, so if i delete file by my own, but it still exists in pgbackweb database, and pgbackweb trying to delete this file, it cant, and all cleanup process fails and not moving forward simply omitting this file.
@TristisOris commented on GitHub (Oct 8, 2025):
Still not fixed.
this log repeated for 100 times. No attempts to remove any other date. I removed old backups manually, but db is not cleared.
@TristisOris commented on GitHub (Oct 10, 2025):
empty folders not removed with files.
@BartschLabs commented on GitHub (Oct 29, 2025):
I also have empty folders remaining after the files are deleted.
@zitom4 commented on GitHub (Nov 13, 2025):
Hello, I had the same problem. Apparently, the process that deletes historical files stops if it doesn’t find a file in the directory structure, just as (@TristisOris) mentioned in their message. In my case, I changed the directory structure where I stored the backups, and there are files that pgbackweb copied that no longer exist in the paths where they were stored.
The scheduled task that makes backups stores each backup in the "executions" table, along with its date, status, and path. The deletion script goes through this same table.
To temporarily fix this, we can connect to the Postgres container, access the pgbackweb database, and query the "executions" table. This table contains all the backup executions. To prevent the script from trying to delete a backup, it is enough to mark it as "deleted" and update the "delete_at" field.
In my case, I analyzed the backups by the date of the change and updated the ones I knew didn’t exist to status="deleted", updated_at="", deleted_at="".
I hope it helps.
@vutsalsinghal commented on GitHub (Feb 19, 2026):
@eduardolat i'm facing issue with pgbackweb not adhering to retention settings as well. I have B2 as my S3 Destination and since I started using pgbackweb 3 months ago, none of the backups have been deleted even though retention is set to 10days.