I have a lot of Outlook PST files (history squirreled away).
Some are currently being used/added to, and as such obviously should be backed up in Diff/Incr backups. 
Others (many GB) are project history. They are attached to MS Outlook so they can be accessed, but are not added to or actually changed. Their physical content is constant.

Now for the problem. Outlook will update the date/time stamp on ANY PST file that is attached to it. Meaning, that even when a data file is never actually really changed, it's timestamp will change every day anyway.
This presents a problem for backups, because it falsely oversizes all Diff/Inc backups by including these oversized files.

So.. On the initial "Full" backup, obviously all files should be backed up as usual, but on the scheduled differential/incremental, the never changing files should be excluded, to prevent from creating  unnecessary oversized Diff/Inc backups.

With backup software used in the past many years, I have solved that problem by moving the "historic files" into a sub-directory of my Outlook folder directory, aptly named "Excluded-From-Differential-Backup". :-)
By simply excluding this directory from Differential/Incremental backups, knowing that things in there never change despite the changing timestamps, it seriously reduces the space/time used on diff/inc backups.
Only Full backups then contain these files.

However, with Macrium, this is not possible, since the only file/dir exclusion specification in a backup definition affects ALL types of backups from that backup definition, even the Full backup, which would in this case of course be no good.

So, the request/Wish.. It would be very useful, if there were a separate "Exclude file/folder" add-on setting for Diff/Incr backups, that did not also exclude those areas from the Full backup.
Please. Pretty please. :-)

As a workaround for now, here's an option you could consider if you haven't already.  Especially if you're already used to having an "Exclude" folder for these effectively static PST files, you could have one F&F definition file that backs up ONLY that Exclude folder, and another F&F job for your regular backups that always excludes that Exclude folder, even for Fulls.  And if those historical PST files truly don't EVER change in a meaningful way at this point, you could even run the first job just as a one-off to capture your backup rather than ever needing to run it on a schedule, since of course nothing is changing.  Or if you occasionally move new PSTs into that folder, this setup would at least reduce the interval of the schedule required on the "Exclude folder" job, or you could even just keep the definition file for the occasional manual execution, depending on how regularly/predictably new PSTs get "tombstoned".

Incidentally, this is one of the unfortunate downsides of F&F backups compared to image backups. Because F&F jobs operate at the file level, any detected change (based on a timestamp and/or size change) means the entire file has to be backed up during a Diff/Inc.  Image backups by comparison operate at the block level, so if these PST files were being backed up that way, the Diff/Inc would basically only contain enough data to specify the updated timestamp.

+x

 

jphughan - 20 January 2018 3:24 PM

As a workaround for now, here's an option you could consider if you haven't already.  Especially if you're already used to having an "Exclude" folder for these effectively static PST files, you could have one F&F definition file that backs up ONLY that Exclude folder, and another F&F job for your regular backups that always excludes that Exclude folder, even for Fulls.  And if those historical PST files truly don't EVER change in a meaningful way at this point, you could even run the first job just as a one-off to capture your backup rather than ever needing to run it on a schedule, since of course nothing is changing.  Or if you occasionally move new PSTs into that folder, you could at least least reduce the interval of the schedule on those backups, or perhaps just keep the definition file for occasional manual executions, depending on how regularly/predictably new PSTs get "tombstoned".

Incidentally, this is one of the unfortunate downsides of F&F backups compared to image backups. Because F&F jobs operate at the file level, any detected change (based on a timestamp and/or size change) means the entire file has to be backed up during a Diff/Inc.  Image backups by comparison operate at the block level, so if these PST files were being backed up that way, the Diff/Inc would basically only contain enough data to specify the updated timestamp.

Thanks. I agree that there are workarounds, and I do have multiple other protections in effect already.
Yes, sure one could create entirely separate backups for these particular files, and then have a full exclude for them that affected all drive level file backups (Full/Diff/Incr).
But one should not have to. :-)

Since, when it comes to backups, I by long experience have learned to wear all of  Belt, Suspenders, and at least two thick strings to keep my pants up, I also separately run Macrium image backups of drives.
In addition to constant file-history tracking (which excludes PST files) and separate file-sync copies of important files spread around onto both other drives and my Linux file server. I do not trust any single piece of software (not Macrium either) or hardware to be enough to protect me, so I have multiple types of software backing things up to multiple locations in multiple formats. Protecting me from inevitably failing hardware as well as from software that might fail to work as intended when you ask it to restore. :-)
Plus, all drives are running RAID 1 (mirrored), protecting me from all the usual single drive failures. This has so far mostly protected me from ever actually needing to roll in a full backup of anything. 

So, yes, if rooting around in all my many backups/copies in case of a (multiple-)disk crash, I surely can find those particular files, to restore them separately, after restoring what SHOULD otherwise be the only necessary backup (roll in from a full, then Diff/Incr).

But again, one really should not have to do all this "keeping track of individual files" in what should be a complete disk backup, since each type of backup should have a sequence of Full/Diff/Incr that combined should be enough to accomplish a restore. Without having to remember and track separately that certain individual files should be found elsewhere, because the software making that particular backup is limited. Hence my request to be able to add separate "excludes" to Diff/Incr backups.
I really want my "excludes" on full backups to be only dumb stuff like temp and other junk folders.