I'm in my trial period, trying to figure out if SP is right for me.  I've had one or two issues, and sought help here a few days ago, but I've gotten no response, which troubles me a bit; I'm not sure if there are other avenues of support I should be seeking, or places I should be going to get answers that I need before I can commit to this software.  Anyway, I'm trying again with my original issue, and I have a new issue that's arisen that's really making me uncertain about ShadowProtect.

I've set up to use the "Second and subsequent backups are differentials" option.  I started with my original "Full" backup on Thursday, and I'm set up to do weekly "full" (differential) backups, with incrementals each day.  The initial Full backup is in file C_VOL-b001.spf.  Incrementals have been going smoothly.  Then today my system froze.  After I reset, I assumed SP would begin a dirty shut-down differential, or whatever it's called.  Instead, though, it did a complete new Full backup.  I checked the log and found an error message - that "the system cannot find file C_VOL-b001.spf."  But that file is right there in the directory where it belongs - it hasn't moved.  And I double checked that I could mount it and explore it, and I can.  Meanwhile, though, I have a new Full backup, which is exactly what I *didn't* want, and no understanding of why this would have happened.

Can anyone help?  I don't want repeated full backups - I only want one, which is why I chose this option.  And is there any way to get back to my original job, so incrementals and subsequent differentials are being taken off the first full backup, C_VOL-b001.spf, and not the second one, which is what I want to do?  I really want my chain to begin with the full backup from last Thursday, not a subsequent full backup; that was the whole point!

This is my  main concern right now, but my original questions were about my try-out of the Recovery Environment.  When I first got into the Recovery Environment and looked at my Disk Map, none of the letters for my drives matched how I have them assigned on my system.  For example, I have three internal drives: my primary drive has a C partition (system and applications) and a D partition (documents and data); my secondary drive is E (single partition), and the third is I, but in the Recovery Environment these volumes were C and I (on the primary drive), F, and D, respectively.  Same with my two eSATA drives, my Firewire 800 drive, and my USB drive - all appeared to have been randomly assigned drive letters.  Is this how it should work?

And I was able to mount my backup image fine as a drive letter and to explore the mounted image.  But when I attempted to mount it as a mount point (either to the default location or to another location), I got the following error:

"SPExplorer.exe Application Error.  The instructions at 0x7c283b40 referenced memory at 0x00000050.  The memoery could not be read. Click OK to terminate the program."

Any ideas what this might mean? Does it matter if I'm able to mount an image as a drive letter?

Thank you.

Could you send some information to support@storagecraft.com?  First, go to the backup job in the ShadowProtect UI, right click and select "Write Job File".  Next, zip the directories "\Program Files\StorageCraft\ShadowProtect\Logs" and "\Program Files\StorageCraft\ShadowProtect\Jobs" assuming you used the default install directory.  Use "Differential full schedule" as the subject.

I've done this; thank you.

From the log file you sent I can see why a new full backup was created.  Our logic has been that whenever a differential backup fails, we retry using a full backup.  The thought has been that it is better to have a full backup than no backup.  The continuous incremental job does not follow this logic to avoid requiring the transport of multiple full images for customers transporting their image files.  Based on this incident,  we have changed ShadowProtect 3.3 to error out instead of create a full backup for jobs with differentials as full images when a differential backup fails.  This will require closer monitoring of backup jobs, perhaps setting email notifications if they are not set to be notified when backups are not occurring.

What I don't know is why the error "File not found" was returned when we tried to access the original base.  We are calling Windows APIs and rely on the return values so the failure was within the system, not in our software.

I have asked support to respond to the Recovery Environment error you are seeing.

Doug:

From the log file you sent I can see why a new full backup was created.

Well, I'm glad about that - but could you you explain it to me?  I'm inferring from your response that for some reason the differential backup that was supposed to happen after the dirty shut-down failed, so it went to a full one instead.  You must be able to tell that from looking at some part of the log other than what I can see; there's nothing in the SP backup history that makes that obvious to me.  But okay - still, I really would like to have some understanding why would this have happened - the failure of the differential, I mean - if the full from which the differential was being taken was in fine shape. I am 100% certain it was in fine shape, not only because I was able to mount and explore it, but also because - and in fact, a new development since I wrote to you yesterday - I actually did a successful recovery from it yesterday afternoon.  So I still don't understand why this happened in the first place; the 3.3 "solution" (which is due out when - do you have any idea?) seems to address the result and not the root cause.  Is it likely to happen again?  Is there any way I can prevent it?

And to repeat my main, really important question, which I haven't seen a definitive - or any - answer to: I'm assuming there's no way to make my job go back to taking incrementals off that original full backup?  Will 3.3 change this?  Isn't there any way to make it an option in SP to set up a job based on a particular full backup, either a manual one or, as in this case, one that seems to have incorrectly been removed from the chain? 

About my Recovery Environment issues - I'm assuming support is going to contact me about the error message, so I'll wait for that.  But at risk of sounding like a broken record, I still don't know what it means that the Recovery Environment Disk Map isn't showing the "right" drive letters.  I've searched but have seen no reference to that on the forum.  As I said, I did a full recovery yesterday of my system (C) volume, and it worked fine, which goes along way toward giving me high faith in the product.  But the C volume is the only one whose disk letter carries over to the Recovery Environment.  So what if I have to do a recovery of another partition, back to the original partition (not a new disk or a different partition), and the Recovery Environment is telling me that that partition is "J:" when I know I've assigned it "D" in Windows"?  If I recover to that partition, what letter will it have when I boot back into Windows, D or J?  Changing it to J could screw up a lot of things (if, for example, it's the partition where I have "My Documents," and I have lots of registry entries pointing to it).  I suppose in that case I could just re-letter it back to D...  Or I could just do the restore from Windows rather than the Recovery Environment.  But I'm trying to understand the consequences and effects of this "incorrect" drive letter mapping, and if it's a bug.

I really do appreciate your help, but I'm finding it a bit frustrating that getting answers feels like pulling teeth, one at a time - I don't know if my questions are particularly difficult or I'm too persistent or if this is how it always is.  Would it make a difference if I'd actually purchased SP already?  Do registered purchasers have a smoother avenue to getting questions answered, and does having the maintenance plan make a difference?

Here is the section of your log file that indicates why a full backup was taken:

20-Jul-2008 13:21:43 sbset 108 platform error opening the file (-2 The system cannot find the file specified.)
20-Jul-2008 13:21:43 sbset 404 Cannot open file Z:\ShadowProtect Puget\C_VOL-b001.spf (-2 The system cannot find the file specified.)
20-Jul-2008 13:21:43 (loader) 504 Final error (-2 The system cannot find the file specified.)
20-Jul-2008 13:21:43 sbvol 109 fini done
20-Jul-2008 13:21:43 sptask 516 sbrun.exe exited with error "Initialization failed"
20-Jul-2008 13:21:43 service 104 retry task
20-Jul-2008 13:21:43 service 104 image will be created by VDIFF
20-Jul-2008 13:21:43 sptask 110 Worker thread has started

As I mentioned in the previous post this is an error returned from a Windows API call so ShadowProtect worked as expected.  If Windows reports that a file cannot be found when it clearly exists then there is a system problem.

In answer to your main question, the UI does not allow you to revert to a previous full image once a new full backup has been taken and there are no plans to allow this in future versions.

I'm not sure I find that an entirely satisfactory explanation - it's easy enough to blame it all on Windows when something goes wrong; I have no understanding of why Windows would report that a file that is there, isn't, and it sounds odd to me - but I guess that's all I'm going to get, so I'll have to be content with it. 

And I don't completely understand why the UI wouldn't permit you to choose what image you want to use as the base for future differentials in general - why, for example, it couldn't be a full you've taken manually -  but particularly for full differential jobs.  It seems to me that if full differentials are going to be an option, then not allowing this potentially defeats their purpose - if even *one* differential goes wrong, thereby triggering a second full backup, you've ruined your set-up. You then have to give up one of the advantages of the full differential system: you can either delete the first full and thereby give up the point-in-time history going back to the very beginning, or keep the first full (along with the second of course, since that's now the base) and thereby eliminate the advantage of reduced storage space.  And if it were to happen twice...you might as well not have selected "second and subsequent..." to begin with.  So it seems to me that if you are going to make full differentials an option, having the ability to go back to an earlier full as the base for future differentials should go along with that, as a way to "fix" problems that might interfere with a full differential scheme.  But full differential isn't the default; maybe it's just not going to be as fully supported.  Or maybe the advantages I see to it aren't the same ones others do. 

Anyway, beyond that I still have no answer to, or even acknowledgment of, my question about disk letter mapping.   Or the question about the error message; support has not contacted me. And my frustration about that has become pretty high. Perhaps it's because I started with higher expectations than I usually have, based on comments in this forum and elsewhere, about the level of support I could expect with SP.  I suppose I have to adjust my expectations if I want to continue to use this product, and I'll have to make a decision about that.

Your concern about additional full images negating the benefit of saving space with full differentials caused us to rethink the automatic creation of a new full image when the differential fails.  As I mentioned before, we have changed this logic in 3.3 so we will no longer automatically create full images for a Differential full job, therefore there will be no need to revert back to a previous full image.

Okay, I understand better now the need for the 3.3 fix - if it had been in place, it would indeed address the issues I'm concerned about (though I'm still curious what's so wrong with being able to choose the image you want to use as the base for future differentials), and I'll wait for it eagerly - also because it will solve the retention issue you mentioned in an earlier post,which I have now also experienced. 

Just to reinforce the need for the fix, I thought you might be interested to know that this problem arose for me again today.  This was with respect to a different backup job - my D volume this time, not the system volume.  It's a much larger partition (about 300Gb), and the job is also set up to use full differentials.  It had been working fine for about a week.  Today, for no reason that I can discern, the incremental backup failed.  The relevant portion of the log:

23-Jul-2008 09:01:37 sbfile 101 successfully opened file Z:\ShadowProtect Puget\D Volume\D_VOL-b001-d004.spi
23-Jul-2008 09:01:37 sbvol 107 disk MBR sectors: 1
23-Jul-2008 09:01:37 sbvol 107 first track sectors: 63
23-Jul-2008 09:01:37 sbvol 109 disk CHS 121601/255/63 partition 2
23-Jul-2008 09:01:37 sbcrypt 107 compression mode: 5
23-Jul-2008 09:01:37 sbcrypt 107 encryption mode: 0
23-Jul-2008 09:37:42 sbset 108 platform error reading the file (-1450 Insufficient system resources exist to complete the requested service.)
23-Jul-2008 09:37:42 sbset 503 Fatal I/O error on Z:\ShadowProtect Puget\D Volume\D_VOL-b001.spf offset 1455f94e00 on read (-1450 Insufficient system resources exist to complete the requested service.)
23-Jul-2008 09:37:42 sbset 504 Cannot read the older data set (-1450 Insufficient system resources exist to complete the requested service.)
23-Jul-2008 09:37:42 sbset 502 Fatal error on pipe (-1450 Insufficient system resources exist to complete the requested service.)
23-Jul-2008 09:37:42 sbcrypt 500 Unexpected end of the image file
23-Jul-2008 09:37:42 sbset 109 fini done
23-Jul-2008 09:37:42 sbfile 109 deleting the incomplete output file(s)
23-Jul-2008 09:37:42 sbvol 109 fini done
23-Jul-2008 09:37:42 sbcrypt 109 fini done
23-Jul-2008 09:37:42 sbfile 109 fini done
23-Jul-2008 09:37:42 (loader) 504 Final error (-109 The pipe has been ended.)
23-Jul-2008 09:37:43 sptask 516 sbrun.exe started successfully but failed to complete the task
23-Jul-2008 09:37:43 service 104 retry task
23-Jul-2008 09:37:43 service 104 image will be created by VDIFF

This time it was an insufficient system resources error, which I do understand was generated by Windows and not by SP.  I have no idea why - I have a new system, set up for video editing, with more than sufficient resources in general: an extremely powerful processor, lots of ram, plenty of HD space, and not an excessive number of processes or programs installed given its power.  Perhaps it was a conflict with a spyware sweep going on at that time or something; I don't know.  It doesn't matter - the point is, SP generated a second 250+ GB full backup on my backup drive, which I did happen to have space for, but I won't if it happens again. 

So I don't know if it's bad luck or what, but I've experienced two failed differentials, for two different reasons, on two different jobs, in the space of four days.  That definitely does suggest to me that this is a real issue - it certainly has the potential to completely negate any benefits of the full differential option - so I am extremely glad that 3.3 will be addressing it.

Support got back to me about the other issues, too, which is making me feel quite a bit bettter, so thank you very much - I appreciate it.

jcat:

This is my  main concern right now, but my original questions were about my try-out of the Recovery Environment.  When I first got into the Recovery Environment and looked at my Disk Map, none of the letters for my drives matched how I have them assigned on my system.  For example, I have three internal drives: my primary drive has a C partition (system and applications) and a D partition (documents and data); my secondary drive is E (single partition), and the third is I, but in the Recovery Environment these volumes were C and I (on the primary drive), F, and D, respectively.  Same with my two eSATA drives, my Firewire 800 drive, and my USB drive - all appeared to have been randomly assigned drive letters.  Is this how it should work?

The letters assigned to the various disks are defined in the registry of the OS. When you boot up ANY bootable disk (WinPE, Linux etc.) it has NO idea what letters might be in that other OS, so it assigns temporary letters to each disk. This is NOT a function of the application, SP or otherwise, but a function of the booted OS. No change is made to the disk letter assignments or entries in the registry of the installed OS - they are just temporary assignments.

I forget what the exact registry keys are, but when you but up your PC you can run a quick search in the registry and find them for yourself.

When you restore the disk, or partition, with your base OS, it will retain its original drive letter assignment. It will also contain references to the drive letters for the other disks on your PC. If you want to be absolutely certain to maintain the drive letter assignments, simply backup all partitions as one backup, and then restore them as one restore.

But to be honest I can't think of a problem even if you restored the partitions separately. Just restore the OS ones first. Just keep in mind, if you boot up any of the restored OSs before restoring any other data partitions you have, the OS will automatically try to assign drive letters to the drives it can see. I think it enumerates the HDs first, then the DVD/CDROMS, then the USB drives, but I may be wrong. In this case the OS may well assign the drive letter "E:" to the DVD-ROM and that may well be the drive letter for your data partition. But it doesn't matter. When you boot into the SP recovery CD and restore the data partition with drive letter "E:", and then boot the OS, what will happen is that the OS will see that the "E:" drive letter is taken, and assign another drive letter to the DVD-ROM etc. The only time this does NOT work is when you decide to fix the drive letter assignment, e.g. setting the DVD-ROM to "X:", or whatever.

In the special case of restoring to another PC:
From what I remember, if you restore to a different PC, with one or more pre-existing drive letter assignment already in place, the SP HIR function will run through the registry of the restored OS and update a number (though not all) drive letter assignments. It does that so that the restored OS can at least boot up. In this particular case, you might encounter a problem with a badly written application that has decided to use a hard-coded drive-letter in the registry (such as C:). It should use a reference to the active partition (which allows you to change the drive letter of the OS etc.. and the application can still function).

 

Thanks for this!  As I recall, someone replied to this issue in another post and alleviated my concern, but I do appreciate your taking the time to respond.

After a few months of using SP, another more problematic issue relating to partitions has arisen for me.  I have two partitions on my primary drive, and my goal (which I'm close to abandoning) has been to back both of them up using SP, using the full differential option - second and subsequent backups are differential.  But I've realized that if I have the Auto Execution of Unexecuted Task option selected for both of these, and I have a crash/dirty shutdown, then when I eventually start up again, differential incrementals - which are incredibly resource intensive - will immediately begin for both partitions (as well as for any other SP jobs I have set up, of course).  And since both partitions are on the same drive, and it's a terabyte drive...well, my poor hard drive heads are dancing around like they're on hot coals. Very inefficient, very slow.  I've solved this by turning off the Auto Execution option, so the differential doesn't execute until the next scheduled time for an incremental for each job, but that seems an insufficient way to address the issue. 

SP just doesn't seem to be set up well to take into account issues that might arise with multiple automated backup jobs, particularly of partitions that might be on the same drive.  I mean, if you have, say, four jobs set up, and you have a dirty shutdown for six hours, or whatever, thereby missing execution of incrementals for all four jobs, and then you start up again - all four jobs will immediately start executing concurrently (with the Auto Execution option), with no way to prevent or manage that, as soon as you start up again.  Talk about inefficient - and that could indeed be the trigger for another dirty shutdown.

In fact, the one thing I've been extremely unhappy about with SP is the resource-hogging of the differential (and full, of course, but those can be scheduled more infrequently) jobs.  I have a brand new, very powerful system, with a fast powerful processor and lots of RAM - set up for video editing - but time after time, if I try to do anything else while a differential backup is taking place (and for a 300Gb partition, that can take a while), my entire system has simply frozen, requiring me to reset and thereby forcing all my SP jobs to lose their incremental status.  Sometimes, the system doesn't freeze, but the differential backup job fails because of a Windows error message - insufficient resources -  which then triggers a full backup and screws up my entire full differential scheme (I've been told 3.3 will fix this, whenever it is released). This has happened, for example, when there's an antivirus scan running at the same time - I've had to carefully time system scans to make sure they don't take place at the same time as SP differential backups - or when I've had two or three multitab Firefox windows open. 

This strikes me as ridiculous, and I've been on the verge of abandoning SP numerous times, and am at the very least seriously considering giving it up for everything other than my system drive.  Maybe it's the 300Gb+ size of the non-system partition job that's causing these problems, or maybe it's that the full differential option is something of an afterthought (though to my mind it's the most sensible option for smaller users), but whatever it is, I've about reached the end of my patience with them.

But anyway, sorry for going off topic - none of this has to do with my original question, or your answer, for which I truly am grateful!

Sorry to hear about your frustrations. I also use my system for video and other CPU/HD intensive applications. My experience with SP is generally very positive. After experiencing Acronis, MS Backup, Norton Ghost, Paragon, not to mention Legato and Veritas backup clients on the company's servers, I'm feeling less pain and frustration now that I have SP.

A few points based on my experience
- I have found SP is much faster and reliable
  Full backup with Ghost was taking hours, SP takes 20 minutes)

- A well thought out set of partitions works wonders
  Small OS/Application partition: few changes, few backups + Data partition: few changes, more backups).
  If you are trying to backup videos that you are editing you might want to create two data partitions. One for completed videos and one for the onse that you are still planning on working on.  

- I also have various temporary files/directories on a second HD (e.g. Photoshop scratch, temporary internet folder, pagesys file etc.) 
  That gives the PC a chance to use both HDs at the same time (faster than an old RAID 0 set up I had in many cases).

- I use a weekly backup (full late on Sunday, with incrementals every hour or so). The incrementals only take 20 seconds.
  I have SP throttle set to 100% so my machine does slow when that happens. I could set the throttle lower, but I'd rather have a quick incremental instead.
  Sometimes I forget about the backup and wonder why the PC is "frozen" and I can't log in or use the browser....then look at the clock and realize there's a backup going on...wait 20 seconds and I'm back up and running. Most of the time the backup occurs when I'm reading a website or document, so I don't even notice.

- I understand the appeal of a differential backup.....just prefer more frequent incrementals.

- One other thought. If you are producing videos commercially, then it might be worth investing in a high-end RAID controller card (not the onboard RAID). You can set up a RAID1+0 and have fast HD access with a nice protective mirror. You'd then be protected continually and will only need to make regular (potentially full backups) when you've finished for the day. The may be expensive but trust me, they will take away a lot of stress.  

Best of luck either way.

Admittedly, I've never used any other image-based backup software - I've always used a file/folder based application (Retrospect, which I still use) - so I have nothing to compare SP to.  I do understand from everything I've read that it's superior to the alternatives, which is why I've stuck with it.

I planned my partition scheme very carefully before acquiring my current system.  I have two internal terabyte drives; on the primary drive, a small OS/Application partition ("C") and a larger data partition ("D") - but not for video (except for use as a Premiere scratch drive).  The secondary drive is devoted entirely to video.  The D-partition is for other stuff - photos, files, etc. (and my video editing is not commercial; it's a hobby, for myself and for a few groups/clubs).  RAID-0 has its advantages, but I've found them to be outweighed by the problems, and after my last system died, I decided no more RAID-0 for me!  RAID1+0 is a very appealing idea, but more than I need, given my usage.

So in SP, for each of my jobs (currently one for C and one for D partitions), I've set up weekly full backups, but I've selected the "second and subsequent backups are differential" (or whatever the exact phrasing is) option.  So essentially, I should be working off a single original "full" backup, with each week a new differential backup off that single original full.  That's the theory, at least - in reality, various issues trigger new "full" backups when I don't want them; that's a problem I've been told will be addressed in 3.3.  I'm still waiting for that.  In between my weekly full-differential backups, I have it set to do about 3-5 daily incrementals.  Each weekly "full differential" and its set of subsequent daily incrementals for the week form a backup set.

The problem is, if I have a dirty shutdown for any reason, instead of the almost-instantaneous incremental, SP has to do a differential for its incremental when it "catches up" (or for its next scheduled incremental for the day).  This is always the case, regardless of whether second-and-subsequent is selected; in a dirty shutdown, SP loses whatever it needs to do that almost-instantaneous incremental backup and has to start the incremental from scratch, comparing the current state to the previous one sector by sector (or whatever the correct terminology is).  For my (currently) 300Gb D-drive, this can take a long time, even backing up to an eSATA drive.  And if this process begins simultaneously for the C and D drives, SP is attempting to access two partitions of the same hard drive simultaneously, which is a disaster.  Even if they weren't on the same partition, it would be an unbelievable resource drain.

It's during these differential backups (either the weekly scheduled ones or the "incremental" ones that occur after a dirty shutdown - and most of my dirty shutdowns have been triggered by SP, actually!), not the almost-instantaneous incrementals, that my problems have arisen.  Having my system tied up for an hour and a half (which is roughly how long it takes to do a differential backup of the D-drive) is pretty constraining.   Perhaps, though, one solution would be to set the throttle back from 100%.  It would take longer, yes, but I'd be less likely to have these resource conflicts that sometimes cause either the entire system to freeze (permanently, requiring a hard reset - I mean, I come back five hours later and it's still frozen, with the computer clock showing the time of freezing) or cause my SP differential backup to fail for "insufficient system resources" (an error apparently generated by Windows, and one that baffles me - I could hardly have more system resources on a home computer, and it strikes me as absurd that SP sometimes seems to require every other application to be shut down in order to have sufficient resources to do my backup).

I am not using SP to back up any video.  A file-based backup solution works just fine for that.  And indeed, given the problems I'm having with resources, I'm thinking perhaps I should give up on using SP to back up my D-drive, which is all data and files.  Perhaps I should limit my use of SP to what it seems to do best: system recovery; that might limit my aggravation, as well.  Though maybe I'll at least wait until 3.3 is released....

Thanks for your input!

Well, I can see that you're frustrated. If you have the patience to look into this a little more, then I have a few more questions.

From your other posts it looks like you have:
HD1: C:Partition (OS/Apps), D:Partition (Photo and Premiere scratch)[300Gb]  (...you describe this as a terabyte drive ?)
HD2: E:Partition (Video) (size...1 terabyte?)
HD3: I:Partition (?) (size ?)
2 x external eSATA hard drives (size ?),
1 x Firewire 800 drive (size ?), and,
1 x USB HD drive (size ?)
RAM ?
CPU ?

I'm guessing you are backing up to one of the eSATA drives? 
When the system "froze" during the incremental backup, what were you doing on the PC? How long did you leave it be power-cycle?

Not to make you feel bad, but to show you that SP can work fine on 'busy' machines, I can give you an insight into my PC. I'll often run video-editing, photoshop, animation software, browsers and music playing, all at the same time (I'm easily distracted). Oh, and ZoneAlarm is doing it's low-level, OS firewall, regular firewall, continuous virus check and SP runs it's incrementals just fine. And the WinXP install is pretty old - I've used SP to migrate it between 3 separate PCs (Intel P4, AMDx64, Intel Quad).

I'm sorry, but I couldn't find out how big the C: drive is. You probably mentioned it somewhere, but I didn't see it. If the D: partition is 300Gb, and it's a terabyte drive, then C: ...is fairly *large*.

You may have also checked the following, but I'll ask just in case you haven't:

- If you're not backing up large video files then I'm kind of surprised why you have a 300Gb data partition. You could break the whole disk up into 3 partitions:

1 for OS/Apps (backup full once a week, no incrementals
1 for Data that doesn't change much (photos, dbs etc.) (Full backup Sunday evening)
1 for Data (small) that changes a lot (documents etc.) (Full backup and daily incrementals)
Each can be backed up on a different schedule, rather than at the same time.
Reduce the size of the partition that has the most changes and back that up more frequently.
If I'm editing videos, photos etc. I'll make sure they are in the partition with incrementals. When they're "done" I'll dump them into the 'finished' partition.

- Checked the System & Application logs for Warnings/Errors just prior to the fault (excluding the SP one you found)

- If you have space on the E: drive, you can add partition specifically for backup files (faster than USB and firewire, and removes any potential problem with eSATA controller)

- Are you using "Second and subsequent full backups are differentials" in order to save space? If it is making things worse by causing SP to try to make a full backup, then just disable this option. You could simply use Weekly Full + Incremental + rentention policy 1 + "enforce policy" option to clean/up remove old backups before making new. 

- How often are you making incremental backups and on what partitions? Changing the frequency might help.

- You might see a performance boost moving the Premiere scratch to different HD to the one running Premiere (e.g.E: or I:)

- Have you run a verification on any of the full backups? Make sure there are no problems with any of the HDs (CRC errors)