By forrester - 17 June 2019 1:08 PM
I've set Macrium to delete when the file space is less than 50GB, but it doesn't seem to. Is there some other setting I need?
I get this:
Rules will be applied to all matching backup sets in the destination folder
Full: Retain full images for 26 Weeks
Linked incremental and differential images will also be deleted
Backup Sets: 1 sets found
Nothing to delete
Differential: Retain differential images for 4 Weeks
Linked incremental images will also be deleted
Differential Backups: 3 found
Nothing to delete
Incremental: Retain incremental images for 14 Days
The oldest incremental images may be consolidated
Incremental Backups: 14 found
Consolidation: Merging 'E57E35CC2F6796F5-23-23.mrimg' to 'E57E35CC2F6796F5-24-24.mrimg'
Merge completed successfully in 00:00:46
Renamed 'E57E35CC2F6796F5-23-23.mrimg' to 'E57E35CC2F6796F5-24-24.mrimg'
Backup Type: Differential
File Name: Append to recent image in directory 'D:\'
Operation 1 of 1
Hard Disk: 1
Drive Letter: C
File System: NTFS
Size: 464.31 GB
Free: 228.66 GB
Used: 235.65 GB
Starting Image - Monday, June 17, 2019 13:01:06
Write Method: Using File System Cache
>>>>>> Destination Drive: 2TB (D: - Free Space 30.37 GB
>>>>>> Free space threshold: Delete oldest backup sets when free space is less than 50.00 GB
Creating Volume Snapshot - Please Wait
Volume Snapshots Created
Analyzing file system on volume C:
Saving Partition - SSD (C:
Reading File System Bitmap
Looking for changes
New File: 30 GB E57E35CC2F6796F5-38-38.mrimg
No space on destination.
Gathering Windows Events - Please Wait
Backup aborted! - Timed out waiting for response.
By Drac144 - 17 June 2019 7:07 PM
I THINK it is because you only have one backup set. If it deleted that one set you could not do a differential - and you could lose your only good backup.
By jphughan - 17 June 2019 10:50 PM
Drac144 is correct. The disk space purge option, as the wording indicates, will delete the oldest SETS when space drops below the specified threshold -- but the CURRENT set is never considered for purging, because if Reflect deleted your current set, i.e. the latest Full and any of its child backups, then the Incremental you were creating would become useless. The key distinction to be aware of here is again that the option applies to entire SETS. That has a few implications:
- Again, it will only delete previous Fulls, including all of their child backups. It will NOT delete just Diff or Inc backups in older sets, nor will it delete any Diff or Inc backups in the CURRENT set sooner than your retention policy specifies, which is what you seem to have expected would happen.
- If your disk space drops below your defined threshold while you are creating a FULL, then that option could potentially delete ALL of the existing backups at your destination before the running Full completes. This creates a significant risk, because it means that there will be a period during which you have NO backups at your destination, and therefore if that Full subsequently fails and THEN you have some sort of incident on your PC, you'll have nothing to recover from. Unless of course your backup strategy incorporates something like a disk rotation or backup replication to another location.
- The fact that the option acts on entire sets at a time makes it a much more of a blunt instrument than a retention policy, which can delete individual Diff/Inc backups within a set. For that reason, you should not rely on that option as a substitute for specifying a retention policy that is appropriate for the size of your backups and your destination capacity. That option is sort of a last resort for situations where you would be willing to lose entire previous sets sooner than your Full retention policy specifies in exchange for the running backup completing rather than failing due to lack of capacity.
By forrester - 18 June 2019 1:09 PM
By forrester - 18 June 2019 1:13 PM
OK - thanks to both of you.
Yes, it looks like the retention policy is overriding the deletion. I have a retention policy of a full backup for 6 months (so I do have more than one full backup, 5 I think).
I've set the retention period to 4 months and it now works. So it looks like for the size of backups I have and the retention period I want, I need (to misquote slightly) 'a bigger disk'.
By jphughan - 18 June 2019 2:03 PM
Hmm, if you had multiple Full backups, then actually the disk space purge should have overridden the Full retention policy. The other possibility is that the previous backups are no longer considered "matching backups". An existing older backup is only considered a match for the running backup if the existing backup contains exactly the same partitions and sizes as the ones being backed up. So for example if you added or removed a partition for backup, or if a partition got resized -- as can occur automatically during Windows 10 upgrades as explained here -- then the new backups will no longer match the old backups, and the retention policy will no longer act on those old backups. So you might want to keep an eye on your backups for a bit and see whether the old backups are getting purged when you expect them to be. If they're not, you'd have to either delete them manually or switch your retention policy settings to target all backups in the destination, rather than the default all matching backups, but I'd recommend doing that only if your backup destination folder contains ONLY backups created by that job.
By forrester - 18 June 2019 7:48 PM
I changed the boot system to UEFI from BIOS a couple of months ago. That involved quite a bit of moving and converting partitions, so it could be that.
By jphughan - 18 June 2019 8:22 PM
If your system booted in BIOS mode before and is now booting in UEFI mode, that would require the boot disk to be switched from MBR to GPT. That would definitely cause new backups not to match the old backups.