The storage on one of our URBackup servers hit the roof earlier this week which prompted us to revisit and trim retention values, to then run the manual cleanup script.
We first noticed that a few clients had one very old full file backup, way past the longest archival time otherwise specified. We suspected that this was due to us not activating full file backups for these clients, and thus not caring about the minimum complete file backups value, which was set to two. But because URBackup seems to always begin with a full file backup also for incrementals, this initial one stuck around, this was the theory anyway.
We set minimum complete file backups to 0, thinking this would allow the cleanup script to remove these old full backups, as we’ve understood from other discussions that they are not necessary to keep for later incremental backups to still be usable.
After a first round with cleanup.bat and the free space target set to 5% we got a few TB freed, but the old full backups from the “heaviest” clients still stuck around. We did see another client, call it CLIENT_A, that got its initial full backup removed, but incremental backups retained, so we thought thought it was just a matter of running it again but with a higher percentage.
So I started the cleanup again today with a 10% target, but instead of cleaning these seemingly valid-for-removal full backups, the script ended with
ERROR: Cleanup failed. Could not remove backups. Please lower the minimal number of backups
What’s worse though is that we now had all incremental backups completely wiped from CLIENT_A, which has minimum incremental backups set to 8??
Are we missing out on some key detail here, or is the cleanup.bat script not safe for use ATM?
I found two more wiped clients now, common denominator for these are that they all are linux machines, while the ones that won’t let themselves be cleaned are windows boxes.
The linux machines are not under archival rules, but if we interpret the documentation correctly this should not matter, the minimum number of backups should always be honored by the cleanup procedures.
Starts deleting incremental backups if there is exactly one full backup left and incremental backups are activated, because getFilesIncrNum overwrites backupid for the full backups set on line 1357.
Quick fix would be to rename backupid on line 1364, but I’d perhaps split getFilesFullNum/getFilesIncrNum into separate functions for counting and fetching of IDs, and only ever fetch the ID for the backup type to remove after the while conditions have been met, for clarity.
do you have any additional information on why that initial full backup is prevented from deletion when only activating incremental backups? Any still needed files should be linked in subsequent incrementals and it should be safe to remove.