Better Backup Flexibility


Author
Message
Chris T
Chris T
Junior Member
Junior Member (67 reputation)Junior Member (67 reputation)Junior Member (67 reputation)Junior Member (67 reputation)Junior Member (67 reputation)Junior Member (67 reputation)Junior Member (67 reputation)Junior Member (67 reputation)Junior Member (67 reputation)Junior Member (67 reputation)
Group: Forum Members
Posts: 49, Visits: 76
Folks,

Would be nice if the backup options allowed you to have the backup look at how much space is available on the backup media and compare it to what is required to do the current backup.  After performing those two computations, then delete as many of the oldest backups to accommodate the new backup.

This is important because today, I left my office and let the backup run.  Came home and noticed the RDX drive was ejected indicating the backup was done.  However, I decided to check to see how many bytes were left to find the backup had failed due to lack of space on my 500GB RDX backup media.  I had to go in manually and delete two older backups to make room for the newest backup.  I should not have to do that.

So my "Wish List" is to have Macrium Reflect (Workstation) be able to give me the options (in some new options menu) in a setup to do what I have to do manually now that I am running near the capacity of my RDX backup media.

Chris


Chris T.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
This request has been submitted in similar forms before, but the fundamental problem is that at least when compression is enabled as it is by default, Reflect won't always know how large the backup is going to be beforehand, because different source data compresses differently.  And when creating Diff and Inc backups, predicting the final size of the backup would be even more difficult.  Reflect would have to analyze all of the source data before it even began backing anything up, which of course would increase total job run time, to accommodate a scenario that is arguably an edge case.  The reason I say that is because Reflect already gives you an option, shown below, to allow it to delete older backup sets if the free space at the destination drops below a certain threshold, and that deletion will be triggered in the middle of a running job if necessary.  Do you not have that existing option enabled?

Note however that the option I just mentioned purges older backup SETS, i.e. the oldest Full and any child backups, not the oldest BACKUPS.  As such, it is not a good idea to use that as a substitute for having a retention policy that is reasonable given the size of your backups and your destination storage capacity, because you might not always want the oldest entire set to be purged in order to free up space.  A retention policy allows you to control exactly WHICH older backups get purged as time goes on, because it's not always desirable to purge the oldest backups first.



Edited 6 May 2020 5:22 AM by jphughan
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
One additional note: If you have that enabled and Reflect didn't purge anything, it would be because none of the other sets was considered a "matching" set -- there are reasons that can be the case with image backups, especially after a Windows 10 feature update -- or because there was no other set available to purge, i.e. there was only one Full backup at the destination.  The CURRENT set is never considered for purging by that option because obviously if you're in the middle of creating a new backup in that set, it becomes useless if you delete the parent Full and all other backups in the set. If you want an option to purge older backups within a set, such as deleting older Diffs or consolidating older Incs, that isn't available, but that goes back to the problem I mentioned above that people won't necessarily always want to purge their oldest backups when they run out of space.  For example, if you create a Full every month, a Diff every week, and an Incremental every day, you might decide you'd be willing to get rid of some of the newer daily Incrementals if you have a lot of them in exchange for retaining the weekly Diffs and thus the ability to reach farther back in time if needed.  This again is why it's important to set a realistic retention policy, since that's the mechanism that allows you to indicate what should be deleted when.

I personally disagree that you shouldn't have to ever worry about how much space your backups are occupying and should just be able to expect Reflect to know what you'd want it to delete and assume that you're fine with it deleting whatever is necessary.  The former seems impractical given that different strategies will be used for different use cases.  Having some sort of "space-based deletion priority" on top of a retention policy seems apt to cause a lot more user confusion and thus unexpected/undesired behavior, and realistically if you'd be willing to take the time to specify that, then why not put that time toward specifying a realistic retention policy in the first place?  As for the latter, having Reflect assume that you would be ok with it deleting any necessary backups even within the current set seems hugely dangerous.  For one thing, if a new backup fails due to insufficient capacity, in most situations you'll have the opportunity to rerun that backup after clearing the necessary space, but once you delete and old backup, it's gone -- and you might not have been ready to part with that backup yet.  But more to the point, if even the current set could be purged to free up space, then Reflect could potentially end up deleting your most recent Full and its child backups, which means that if your system just happened to fail before it finished creating that new Full after freeing up space, then you'd be left with no backups at all

Edited 6 May 2020 5:36 AM by jphughan
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search