In SM, where is the option to automatically delete old differential backup files to make more disk space while the backup is running?
I see an option to guess (good luck) how much an increasingly growing amount of space will be necessary before the backup begins, but nothing for SM to conveniently take care of that on a daily basis while the backup is running.
FWIW, a network share repository is used for the backup sets.
Currently, our Diff backup fails to complete, because there isn't enough room on the target for the backup file, which of course, grows every day, and there is no certain way to predict its size, in a set it and forget it way.
Design issue?
Workarounds?

+x

 

uit - 23 August 2023 1:53 PM

In SM, where is the option to automatically delete old differential backup files to make more disk space while the backup is running?
I see an option to guess (good luck) how much an increasingly growing amount of space will be necessary before the backup begins, but nothing for SM to conveniently take care of that on a daily basis while the backup is running.
FWIW, a network share repository is used for the backup sets.
Currently, our Diff backup fails to complete, because there isn't enough room on the target for the backup file, which of course, grows every day, and there is no certain way to predict its size, in a set it and forget it way.
Design issue?
Workarounds?

It's possible to set retention rules in the schedule so that only a certain number or age of backup are set - the purge of backups usually happens after the backup is complete, but can be set to run before the backup. This does open up a little risk should the backup fail though.
Unfortunately it's almost impossible to predict the size of backup before it's actually taken, given that only the changes since last backup are taken

Kind Regards,

Alex

Macrium Development

See our reviews on

Ok, but SM should be doing the thinking here, not humans.
SM can see how much disk space is available while the backup is running, and just as Macrium Reflect does, clear space so the new backup can completely write to the disk.
As it is, it's impossible to predict backup file size growth in the near, and especially distant future, and I don't want to constantly babysit multiple server's backup. That's for the backup software (which I personally pay for, dearly) to take care of.
Please pass this along to the relevant people to be addressed sooner than later.

The other reasons it's critical that SM intelligently manage space on the repository for differential backups, instead of admins having to guess and constantly monitor repository disk space, is because there can be (in my case, there are) multiple servers writing to the repository, in which case, guessing how many backup sets to keep quickly becomes futile, leading to backup failure, tremendous risk and aggravation.