ShadowProtect Desktop 3 is out...

Right now, to image, it takes 30mins. That's 15min less than ATI. Actually it's the restore I'm concerned with. ATI takes 6hrs for 35GB Image

I'm "hoping" that SP can reduce this time by 500% to about 1hr.

I can hope can't I.

...screamer

 

I have a system partition of 11.4gb and I use only the Recovery CD.
Backup time = close to 4 minuts and Restore time = close to 6 minuts.
There are too many factors that influence the backup/restore time. You better test this yourself.
Besides the transfer rate of SP changes constantly. Sometimes 40 MB/second; sometimes 15 MB/second.

 

Imaging the hard way[immediate restore] is the only way to know if a image is sound,but as Nate explains afterwards it can detoriate because of diskrot and other compromises,so you never completely safe.

 

Before i image i clean the volume[C with no pers.data] in every possible way,so the only differences in successive images are instals i keep and security updates,because i have FDISR in full swing,i image for this reason about once in every 3 months or lesser and mostly for the fun of it.There is no urgent need for that.I keep a clean install image[only a bold Windows XP],can restore that and bring it current with a current FDISR Archive,once i did it took 16 min.

 

Maybe testing Windows services is a bit "nitty", but making sure the stored image is valid through byte-by-byte comparison is a fundamental objective of a piece of imaging software like SP. Admittedly I am not privvy to the implementation details, so it would be interesting to know what checks are made by SP during (or after) image creation to ensure that the new image is an exact replica of the source data/partition ?

That aside, after a bit of investigation I have found the cause of the problem I've been experiencing with SPD hanging and not being able to create backups. It was because the "COM+ Event System" service was disabled. When this was changed to Manual, the problem disappeared.

BTW, during my investigation I found that SPD still appears to function correctly with the "MS Software Shadow Copy Provider" service disabled, although I only tested that the backup process would start OK.

 

Back to questions about Continuous Incrementals - Am I right in my thinking of how the following scenariosn work:

1) For a schedule with nothing ticked in "Additional Incremental Backups" and Sun ticked in "VSS Incremental Backups" with a Start time of 18:00:00, then a full backup will be created if no previous full image exists. If a full image does already exist, an incremental image will be taken every Sunday at 18:00:00. The images will always be taken using the StorageCraft Volume Snapshot Manager (this is me assuming the "Use VSS" checkbox only applies to "Additional Incremental Backups") ?

2) Alternatively to (1), the same schedule could be achieved by un-ticking all "VSS Incremental Backups" checkboxes, and only ticking the Sun checkbox in "Additional Incremental Backups", with Start and Stop times both set to 18:00:00, and "Use VSS" un-ticked ?

After thinking about it for a bit, I think I'm getting the hang of it. The thing that confused me a bit was that you can have a single schedule which will backup on specific days at a specific time, as well as having it backup on independently specified days at every X minutes between a specified time period.

It also confused me having the group heading "VSS Incremental Backups" instead of something like "Daily Incremental Backups". If

If the option "Use VSS" also applies to the group "VSS Incremental Backups", then it would be more intuitive if it was moved outside the group box.

BTW, why can't the minutes between backups be entered directly (you have to use the up/down arrows) ?

 

Is it normal for incremental images to be about 200KB-300KB in size (using StorageCraft Volume Snapshot Manager) for a Continuous Incremental schedule on my system partition if, after an image has been taken, I immediately zoom the system clock forward to a few seconds before the next run time (ie. so there is only about 5-10 seconds between images) ?

The same images taken with VSS are about 9MB in size. Given this massive size difference, why would anyone ever want to use VSS ?

 

Hi Pete,

Do you only choose to have it run between 9-5 because that is the time period when you do all your critical work ?

Reason I ask is because I often work varied hours, so was considering just setting the start time to 08:00:00 and the end time to 07:59.59 with 15 minute increments. I figure that when my machine is switched off, SP obviously can't run, but I will be protected with backups every 15 minutes while the machine is on.

How much do the incrementals collapse (eg. if all 33 incrementals for the day were 1 MB each, how big would the resultant collapsed image be on average ?) ?

BTW, Image Manager is not a pre-requisite for using Continuous Incrementals, although you obviously lose the collapse feature.

 

That's a terrible thing to happen. I thought I was in another thread, and posted something uncomplimentary about the wrong protect.

Please pardon my error.

 

Actually, yes, you really *should* use ImageManager if you intend to set up a continuous incremental job.

 

First off, if you want to manually provoke another incremental (without waiting for the schedule to trigger it) you can just right-click on the job in the Jobs list and select "Incremental Backup" and it'll make another incremental immediately. No need to mess with your clock.

VSS will quiesce any VSS-aware applications (called "VSS Writers"), and so if you care about this (usually only people that are actually using VSS Writers like SQL Server or Exchange Server, etc, care about this) then your VSS backups are generally better than non-VSS backups. This also explains why non-VSS incremental backups are smaller (while the file system is flushed, VSS writer apps are not quiesced for non-VSS incremental backups).

 

Thanks for the info grnxnm, particularly that I don't need to whizz my clock forward to get it to take another incremental.

I'm waiting on the full eval which I should have soon. However, I am loving the Continuous Incrementals already and from what I can see, this software is likely to be an integral part of my backup strategy for my most critical data.

I think I'll stick to non-VSS backups though, for obvious reasons.

 

I've run into a little problem. I have a single Continuous Incrementals back schedule which is set to perform a backup every 15 minutes, 24 hours a day (ie. Start time= 08:00:00, Stop time=07.59.59), every day of the week. "Use VSS" is not selected. All checkboxes in upper "VSS Incremental Backups" group are not selected.

The first time it was run, a full image was created, followed by incremental images throughout the rest of the day. Here's the problem though, when midnight struck and a new day started SPD started to take a full image.

According to the manual, for Continuous Incrementals schedule:

So, why is it trying to take a full backup again ?

 

After looking at the log, I think I've just answered my own question:

Code:

31-Aug-2007 23:47:28	service	100	VDIFF was disabled and then enabled on C:\

I gather that a full backup is taken again when VDIFF is disabled ?

The odd thing is that I didn't manually disable it (or at least not knowingly).

What are the ways that VDIFF can be disabled ?

 

There is a minor cosmetic bug with the text on the Basic Properties tab of a job schedule, under the heading "Schedule". For my schedule above ((ie. Start time= 08:00:00, Stop time=07.59.59)), it says "Trigger every 15 minutes. Do not trigger from 08:00:00 till 07:59:59". The start and the stop time are the wrong way round though - It should read "Trigger every 15 minutes. Do not trigger from 07:59:59 till 08:00:00".

 

Yeah, we found this one and have fixed it. What happened is that an unrelated fix was added right before release and it had a side effect that turned off the "crash-proof/auto-heal incremental" feature. This feature should by default ALWAYS be on for continuous-incremental backup jobs. The basic idea is that in order to make fast incrementals, ShadowProtect maintains a tiny compressed bitmap, in memory, of the sectors that have changed since the last snapshot. When you make a new incremental it takes a snapshot and then backs up only the sectors that changed between the previous snapshot and the current snapshot. The problem with this technique is that if your machine powers off (has an ungraceful shutdown) this in-memory map is lost (if you shutdown gracefully it's saved to the .idx file in the root of your volume and re-loaded when your system comes back up) and so when it boots back up after a crash/power-loss the next incremental has to be made using a diff technique (and at this time the in-memory tracking is turned back on so that subsequent incrementals will be fast again). This capability to continue making incrementals even if a power-off occurs causing the loss of the in-memory map is the "auto-heal incremental recovery" or "crash proof incremental" feature. The really silly thing about this bug is that all of the functionality is there, but that in the wizard when you create a continuous incremental backup job it turns OFF this auto-heal option and disables the checkbox so that you can't override it. It was a very simple fix, but sometimes stuff like this gets out the door. Anyway, the net result is that if you perform any type of operation which interupts the incremental tracking then continuous incremental jobs (without the fix) will make a new base image. With the fix they'll continue making incrementals. By the way, booting the recovery environment will also wipe out the incremental tracking as whenever you boot the recovery environment it will delete all .idx files in the roots of all volumes. This is to prevent the possibility that an incremental will be generated with bad data because if you change data on a volume while within the WinPE environment, the changes you make are not known to stcvsm.sys on your normal OS (as you didn't boot your normal OS).

So, that's all a long way to say, "You're right, it's a minor issue that we've also discovered, and fixed, and the fix will be available shortly."

 

Thanks for the detailed description of the problem - I appreciate the time taken to describe the problem, why it occurred, and how you have fixed it.

From your description, I understand that when this auto heal feature is enabled the diff technique will not require any more disk space than a normal incremental. It's just that the diff technique will take a lot longer to complete (ie. similar to a full backup) ?

 

Exactly so. And actually there's a fringe benefit to the diff technique as it basically does a verify on the previous image files as part of the diff operation.

 

is there any option in SP ver3 to create bootable disc same as ATI 10?

if yes, does it work same as ATI bootable rescue disc?