My machine refused to complete the backup process,
until I unchecked Make Opus the system default handler for Zip files in Opus Preferences - Zip Files - Zip Support
I'm just posting this in case it might save someone else the hour or two I spent resolving this issue.
For the record:
I don't rely on Windows Backup as I use an excellent third party backup application which does not suffer from this issue,
but I'm wound way to tight to allow something to remain broken on my machine
Opus doesn't "monitor' .zip files (whatever that means), and setting it as the default handler for them only changes what happens when you double-click on an already existing .zip file - it doesn't affect the creation (or adding to) of zip files at all.
I have to say, the disk-image backup is good in Windows 7, but the file-by-file backup is absolutely terrible. If you monitor what it does while updating a backup, you'll see it unpacks all of the existing backup .zip files, compares the files being backed up, then re-packs everything. So if one file on a 1TB drive has changed, it ends up unpacking and (if memory serves) re-packing 1TB of data for no real reason. It's okay for tiny backup sets but I found it unfit for real work. Hours after the scheduled backup, my HDD and CPU were still going crazy because of this, even on days where virtually no data had changed.
It's so badly written that I am not that surprised by this issue.
Not much hope of Microsoft fixing something like this between Windows releases, I imagine.
It's good to have the info here, though. It may help other people who run into the same problem.
Looking at the filetypes in the registry, I think it would be possible to make a hybrid of the Windows and Opus zip registry settings which might work, but it's hard to be sure when the KB article doesn't give the exact details. I'm sure I had Opus set as the default zip handler when I used Windows Backup's file-based mode in the past, although I only used it briefly just after Win7 came out, before realising it just didn't work properly and sticking to the image-based backup mode only from then on.
It works pretty good for the casual user the first time... but then...
By default it is set to make a system image followed by the file backup.
If you have 250G of files and a 500G destination, it will work the first time,
but then the second time it attempts to make another system image,
which of course will not fit on the destination.
and yes, the zip method they use is plain awful.
For whatever reason, it is the subsequent attempts after the first one which triggers the breakdown.
I've been having this problem periodically when trying to back up. After three failures in a row with the same error code, despite freeing up extra space on the destination drive, I decided to seek advice online. I don't have any non-windows zip software on my computer so I knew that wasn't the issue. On another forum I spotted a tip to deactivate your antivirus before backing up. I gave that a try this evening and was delighted to find that it backed up fine, with plenty of space to spare. Worth a try if you're experiencing the same issue.
Speaking for myself:
I've moved on from even attempting to use the built-in windows backup software;
I've turned all scheduling and use off - but it needs to stay installed as it's hooked into the Restore Points creation and more.
For the quick project & application backups I use Corbian 11, which is free and actually fun.
For all my serious system backups & cloning I use Macrium Reflect, of which I've found no equal.
IMHO
