However, if I was to make a chain of incrementals then if 1 incremental was corrupted/missing, this would mean all following are unusable, right?
Yes, that's correct.
How redundant are Macrium Reflect backup files? Can they withstand corrupted sectors or bit-rot type failure?
It's always wise to run Reflect's own verification option on backup image files when they are created. Reflect's defaults can be set to do that automatically after every backup imaging operation. If corruption occurs later because the destination drive's file system itself has become corrupt and if the corruption happens to involve the backup image's index, it's pretty much "game over" for that backup set's integrity. Otherwise, it's normally possible to mount a corrupt image to recover what you can that way. There's also a "DiskRestore" option available when booted to Reflect's WinPE rescue environment that lets you ignore corruption errors. (See
this KB article for details.) Other forms of backup protection and redundancy are up to you. Personally, I rotate three swappable destination drives and keep one of them off site. It's also possible, of course, to make additional copies of backup image files just like any other.
I know I can use multipar to create parity files afterwards, but there is no hook to start an application when the backup is finished.
You can create a VBScript, PowerShell or MS-DOS batch file to run (directly or via the scheduler) any Reflect task definition(s) and include whatever additional commands you wish to run before and/or after the backup task(s). As well as running your MultiPar utility, you could also include a robocopy command for redundancy if you want to.
Regards, Richard V. ("Arvy")
