Alternative to True Image (nervous nellie)

I am waiting for Shadow Protect 3, but I will not be using it for incremental/differential backups because of the issue in http://forums.hardwareguys.com/ikonboard.cgi?s=4492619c5fa1ffff;act=ST;f=13;t=4573, unless SP 3 has remedied that issue (which I doubt).

 

Tjena Sukarof,

ShadowProtect ver 2 fungerar inte på Vista, men ShadowProtect ver 3 kommer at fungera på Vista.

Var stans bor du i Sverige?

Hey då

 

Hi Howard! I read through the link you referenced and I wanted to make sure that I understood your concern. It appeared to me that you wish to be able to have multiple backup jobs for the same volume. A backup job in ShadowProtect will first take a base image, and then will take incremental images according to the job schedule that you specify. Am I on the right track here, as far as understanding your concern, that you want to be able to schedule multiple simultaneous jobs for a single volume?

If so, I doubt that we will make it so that multiple jobs, with different schedules, can be assigned for one volume. This complicates things too much for most users. ShadowProtect job schedules are already pretty flexible and have been designed to handle the use cases for the vast majority of users. Sometimes design decisions have to favor the masses over the odd power user.

 

@grnxnhm

Great

That sounds interesting.

 

I'd like to see other developers commenting here... It would be nice to see the other perspective.
grnxnm, you're something else. You almost convinced me. When i trial, i'll sure take a look at Shadow Protect.
How is the license/update procedure with you guys? Any rules, like i buy ver 2 and can't update to 3? Or is it time based, like 1 year updates?

Yes, don't complicate sorry Howard Kaikow.

 

Trialing is the best way to determine if the product is for you. Try them all out. Who knows, maybe True Image will be the best for your needs.

Updates on a major version are typically free. So to upgrade from 2.0 to any other 2.x version, it's free. However, if you have a 2.x license and want to upgrade to 3.x, there are two routes:

1) At the time you purchase ShadowProtect 2.x, you can opt to pay 20% more for a year of maintenance (at the end of each year you can extend the maintenance to an additional year for this same 20% fee). If you are under maintenance then all MAJOR upgrades (version 3, for instance) are free.

2) If you bought ShadowProtect and didn't opt to pay the additional 20% for maintenance, you will still be able to upgrade from version 2.x to version 3 for 50% off of the normal version 3 price.

Licensing: Your license is good for one online-activation of ShadowProtect. If for some reason you have to install ShadowProtect again on the same machine the activation will generally succeed as long as your hardware hasn't changed too much since the first activation. It's basically similar to XP's activation. If you have trouble with activation and need to deactivate on one machine and move to another machine then you need to contact support 'at' storagecraft.com.

 

It seems a good way to prevent abuse. Although it can complicate things.
In order to use it on another computer, for instance if i buy another one, i uninstall it from the older, and all i need to do is install it on the new and contact you to activate it. OK.

So far, i'm thinking on trialing Shadow Protect, Acronis TI, and IFD/IFW.
The control group ) ) will be DriveImage XML and g4u, although i'm not sure how the latter works for simple imaging.

About the trial: if i download the trial, since i can't create a CD, how can i see if it works?
Because i have to do all this right, i won't be doing it any time soon. But i do have to check how things can be done.

 

Add Savepart

 

If you wish to restore system volume images during your trial period, then you should request a full evaluation of ShadowProtect which will include the bootable recovery environment CD .ISO which you burn to CD. To make this request you must fill out an online form:

For desktop edition:

http://www.storagecraft.com/products/ShadowProtectDesktop/Desktopedevalrequest.asp

For server edition:

http://www.storagecraft.com/products/ShadowProtectServer/Serveredevalrequest.asp

 

Hi Guys,

Grnxnm - Yes I've looked at my spam folder, nothing from your company.

Take Care
Rico

 

grnxnm, thank you for your help and prompt replys.
Now i'm getting impatient. I'll try all this in February.

edit: oh, and Lucas . I'll take a peak. Have you tried it or saw a good review?

 

I use it Works very well for me.
Manual
Tutorial (Spanish)

 

hummm, solo en DOS, necessito uno con GUI para burritos como yo.

 

Oh, but it has a "window". Not commands. I'll check it out.

 

Okay, I've PM'd you. I'll try to track down what happened with it. Sorry about that.

 

Like Ghost, SP has two mechanisms for creating backups.
In GHost, one can create an Independent Recovery Set, which is only used for FULL backups.

SP has a similar mechanism, not as obvious to use.

ALL users need multiple backup sets.
It's insane not to do so.
AFAIK, only TI allows multiple backup sets along with incremental and differential updates.

 

Howard,

can you be more specific as to what this means.

Do You mean different point in time baseline images with different incrementals/differentials ??
Why?

 

Yes.

See http://forums.hardwareguys.com/ikonboard.cgi?s=4492619c5fa1ffff;act=ST;f=13;t=4573.

 

Yes.

In Ghost, you can do either "Independent Recovery Sets", or "Recovery Point Sets".

The former always does a full backup and is independent of any other "Independent Recovery Set", so you can have as many as you want.

Ghost's "Recovery Point Sets" permit incremental/differential backup, but multiple sets do not quite work the way we would want. See http://forums.hardwareguys.com/ikonboard.cgi?s=4492619c5fa1ffff;act=ST;f=13;t=4573.

In Shadow Protect 2, the same issue exists (and I have discussed this with SP and the admit the issue). However, by careful selection of the options, you can create "independent" backup sets by NOT enabling the sector tracking.

The mechanism used by GHost and SP (actually, GHost licenses the engine from SP) to track sectors prevents independent backups from being used.

 

Wait a minute, let me see if i get you:

All three allow as many full backup images as you want.

TI allows you to make as many incremental and differential updates as you want to a single full backup. With the others you can't? Or it isn't that simple?

Thanks, i can be slow sometimes..

 

For TI yes, for Ghost and SP, only if you select the right options.

 

I'm not sure this applies to ShadowProtect. First off, ShadowProtect doesn't support multiple jobs on any particular volume. Secondly, if you have created a scheduled backup job on a particular volume (C: for instance) and it has already taken a base and a few incrementals, you CAN at any time specify that you wish that job to generate a new base image, and ShadowProtect will in fact reset the incremental tracking so that the next incremental that is generated, following this second base image, will be all of the changes that occurred since the second base image. Ghost may have a bug where they do not reset the incremental tracking, but I know for a fact that ShadowProtect does reset the incremental tracking if you specify that you want the job to create a new base. Not only have we tested this feature, but we also frequently use it in house (our policy is to use our own software on all of our own production servers, which forces us to deal with any issues, especially critical issues, immediately).

Test this yourself and you will see what I mean. Create a backup job to backup C: and specify a schedule for incrementals every fifteen minutes. Roughly 30 minutes after your base has been generated you will have the following files (assuming you use the default filename pattern):

C_VOL_b001.spf (this is the base image)
C_VOL_b001_i001.spi (this is the first incremental image, and it is dependent on C_VOL_b001.spf)
C_VOL_b001_i002.spi (this is the second incremental image, dependent on C_VOL_b001_i001.spi)

Now at this point, select the job in the job list and on the toolbar click on the arrow by the Execute button so that it drops down and then specify that you wish to generate a new base image right now. The job will then create the following base image and will reset incremental tracking to start from this time the snapshot was taken for this new base image:

C_VOL_b002.spf (the second base image)

and after fifteen minutes it will create another incremental because that's what the schedule tells it to do, however this time the incremental will be dependent on your second base image:

C_VOL_b002_i001.spi (first incremental after base 2, dependent on C_VOL_b002.spf)

So, basically, with ShadowProtect you can create a backup job with a flexible schedule for the automated generation of both base and incrementals (for instance, you can specify that you want to automatically generate one base image each day at a particular time, and several incrementals during a specified period of each day). You can also, at any time, manually signal the schedule to generate an incremental or base image, even if it's not yet time for it to do so, and if you've specified that you wish a new base image to be created then any incrementals that follow will be dependent on that new base image.

ShadowProtect's design intent here is to minimize the size of image files. This is the reason that any time a backup job generates a new base file (either automatically or because you direct it to take an immediate base) any subsequent incrementals will be dependent on this new base image file. This minimizes the size of the incrementals. If subsequent incrementals were dependent on a previous base image (a base image taken before the new base image) then they would generally be larger in size. That would be inefficient (waste space). Whether this is a "mis-design" is, I think, a subjective thing. Frankly I like it, but clearly I'm also biased.

The core feature that we're discussing here is "multi snap," the ability to track multiple simultaneous snapshots (keep in mind that a "snapshot" is NOT a backup image, but is a virtual volume, created by a specialized snapshot driver, that represents the state of a real volume at a given point-in-time) on any particular volume, which is necessary if you wish to provide on-demand incrementals and on-demand bases where, any time a new fast incremental is generated, the user/program can specify the base+incremental(s) upon which the new incremental will be dependent. This core capability is in fact in the StorageCraft Volume Snapshot Manager (stcvsm.sys), however we intentionally did not employ this capability in ShadowProtect as it can easily confuse users as well as cause unintentional waste of disk space (as I mentioned previously). There are some other very cool capabilities of stcvsm.sys that we haven't yet exposed, and I imagine some of them will see the light of day in future releases.

Let's suppose, hypothetically, that we had exposed this multi-snap capability in ShadowProtect, and apply the previously-mentioned use case. After the second base image is created, the user/program would have the option of choosing upon which image file the next new incremental would be dependent. This next incremental could be dependent on either C_VOL_b001_i002.spi or upon the new base C_VOL_b002.spf. Now, we know that image C_VOL_b001_i002.spi occurred, in time, before image C_VOL_b002.spf. Let's call the time at which C_VOL_b001_i002.spi was created T1, and the later time at which C_VOL_b002.spf was created T2, and the time at which our new incremental is created we'll call T3. Now if we make our new incremental dependent upon C_VOL_b001_i002.spi, it is necessary that this new incremental contain all of the changes that have occurred to the volume between T1 and T3. However, if we chose to make our new incremental dependent upon the latest base, C_VOL_b002.spf, then it only needs to contain the changes made to the volume between T2 and T3, and it's extremely probable that this case will result in a smaller incremental image than the previous case. Keep in mind that it also takes more time and computational (CPU) resources (and network resources if the target image is on a share) to generate a larger incremental, so the cost of a larger incremental is more than wasted disk space. Certainly stcvsm.sys could suggest the best choice, and so the best choice could be made automatically for the user. However multi-snap support also necessitates a rather complex user-interface, and unfortunately sometimes cool/powerful capabilities have to take a back seat to simplicity. Users don't like programs that are incomprehensible. Most users are not power users, and we've had many requests to simplify our GUI to the point that it's little more than a "Backup" and a "Restore" button (I kid you not). It's rather difficult to expose complex functionality via two buttons , so we try to reach a middle ground between ultra-simplistic GUI and a rich expression of functionality. I think it's a matter of opinion as to whether multi-snap is necessary for "all users." I respect Howard's opinions (he's provided extremely helpful feedback to us) but on this issue I respectfully disagree. By always making new incremental image files dependent upon the chain of the latest base file, ShadowProtect always choses the optimal route. That's just my opinion though, and hey, I'm human, so I may very well be wrong.

Note that if you are testing this, there really is no need to actually wait 30 minutes. After the job has finished taking the first base image, you can just select the job and on the toolbar click on the down arrow by the Execute button and tell the job to execute an incremental immediately. Do this a couple of times, then tell the job to make a new base, and then tell it to do another immediate incremental. You can test this all out in very little time on a data volume with little data so that it doesn't take long to make the base images.

 

Thankyou Grnxnhm
Very well written
Very clear
@Howard you have the watchmakers approach: we need you to keep doing it
OK i'll wade in here at the usual risk of exposing my bottom dweller ignorance

Incrementals to me are a vexed issue

Any damage to any stage of this process will as I understand it 'break the chain' and render anything from the initial error unusable. Not counting size/space issues

I for one support the concept of 'differentials' which I feel FDISR has addressed admirably.

I believe it (the process)can become unnecessarily complex as described above. The greater the complexity the more likely a catastrophic failure.
The weakest link may not be the soft itself or even the user (although possibly most likely lol) there are a myriad of possible failure points in the HW let alone the software. Its not he $500,000 mainframe that fails it's the 50c powerboard that you grabbed on special. !!

Agree, but what is wrong with Less buttons and more safety?
You may have some idea what temporary secretarial staff or even the office manager on a bad day can screw up with the wrong "click"

I have worked really hard to make my back-up protocol as simple and as foolproof as possible. I have addressed the time and cost issues elsewhere.

Coding any software is a task of incredible complexity. Storage craft have obviously done well. Home users, small biz is just the tip of the iceberg.
Just KISS please.

LOL my favourite close to idiot proof GUI
Regards

PS TU addresses the multi boot set-up with ease. But no incrementals/differentials yet