My backups are run from an elevated cmd script, and the weekly full backup now fails regularly on the two largest files - approx 650Mb and 400Mb. It leaves 2 files a similar size to the final zip with extensions .001 and .002 - the second is always much tinier than the first, around 10mb. The backups are done to the "C" drive before being copied to an encrypted DVD.
Backups failed occasionally in XP, but it now happens every week. I've created a special config just for this, but have to run it twice as the first time succeeds for the smaller file and then fails for the larger. If I run it again just for the larger, it runs OK. I've had to code a loop in the script to handle this, but it means that it is no longer "handsfree".
It is hard to say what is happening. WinRescue divides a backup file up when it gets too big and so you get the .001, .002 files. You can set what too big is in Backup Properties on the Misc. tab. If I understand you correctly, the problem happens when two large files are being backed up and so you have set up special configs to handle them. You might try backing those two files up with no compression and see if that works. I don't know what is causing the backup to fail. It could be Vista interfering.
The backups themselves are big, but the smaller one contains almost 400 files and the larger just 3 files (backups of my email). I've created an extra 2 versions of the Full Backup config to handle this issue, as I only use 1 Full and 1 Incremental backup usually.
Compression is on the highest setting, but the files are only 12% and 20% compressed, so I'll turn it off and see what happens.
The "Save large files in blocks of..." is unticked, but I could set to 800,000,000 bytes. This would be large than the files and allow for some growth. Is that significantly larger than the default and would that cause any problems?
I did have this problem occasionally on the XP version, but it now happens every week on Vista. I initially thought it might be due to the Task Scheduler running everything at "Below Normal" priority, but the problem happens even when I change it manually to "Normal". There is nothing else running hard on the PC, and the Idle Time is round 70% when I see the problem and re-run it. I do find it strange that, when I re-run with 2 file-sets ticked, the first succeeds and the second fails. When I then re-run with 1 file-set, it succeeds...
Ah. I hadn't realised that disabling compression would remove the option to split. I'll let you know on Sunday morning if it's worked. If it does, I might try reinstating the compression at a lesser level while specifying a large block size and see if it that causes any problems.
I ran with no compression, and it went OK though it failed to backup 6-or-so files. I hadn't realised it just copied the files across - I thought it just created backup zip files as before, just without compression, similar to the option in the zip programs. The backup was over 2.5Gb, which is over 1Gb larger than the compressed version and rather too large.
So I tried your other suggestion to change the backup file block size. I set it to 900,000,000 bytes and highest compression, but it still split the files into .001 and .002 files. The first failed backup had .001 of 477Mb and .002 of 267Mb, the second .001 of 44Mb and .002 of 605Mb. It has changed the behaviour in that the split is now of different sizes.
I then ran the config for the two backup files with 900Mb(-ish) block size and medium compression, and the first file succeeded with a file size of 386Mb (!) and the second failed with .001 of 471Mb and .002 of 182Mb. I then ran the config for the single backup file with 900 and medium and it produced a file of 654Mb (!) So the .001 and .002 files are larger than the final backup, and don't seem to be produced due to block size splitting.
I'd rather not have to leave it uncompressed, so I've changed it to backup everything but the 2 filesets in one config, and then the other 2 filesets in 2 other configs. It produces 3 separate folders, but it works.