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.