Shadow Protect or Paragon Drive Backup Pro?

Pete,

What kind of performance hit do you get with CI? I edit videos on my production machine, and I need full-on CPU usage when I render and high I/O bandwidth when I capture/import. However, those operations don't occur that frequently. The render is more frequent, but with dual quad core Xeons installed, I figure one of the 8 cores can go handle a CI without impacting me too much.

I can always schedule differential backups to run at night, but then SP loses one of its main advantages over TI - the Shadow advantage.

I plan on testing for myself, but before I invest another 3+ hours in a base/full backup, I'd like an idea whether or not the investment will pay off.

Thanks,
-Jeff

 

does it work for vista or xp?

thanks

 

@Jeff

ShadowProtect's imaging engine is highly optimized and has a minimal (for what it does) impact on CPU resources. For backups, it's not the CPU that you need to be concerned with. The real impact during a backup will be on the source and destination disk subsystems which are several orders of magnitude slower than the CPU. This is one of the primary benefits of the so-called "fast incremental" or VDIFF feature of ShadowProtect (which in practice, is indeed very fast). It makes it possible for ShadowProtect to take an incremental so quickly that the hit on your system is often unnoticed. There are a few other products out there which support fast incremental imaging, however be warned that they're not all created equal. You should only trust them if you have made many incremental backups, during heavy I/O, and have tested each backup to ensure that the file system and files within that backup are good. Don't just trust the marketing smoke - test it yourself before you entrust it with your valuable data.

As a side note, we (StorageCraft) run our ShadowProtect product on all of our own production servers (most are scheduled to take backups on 15 minute intervals, and IIRC the schedule for a couple of them is every 30 minutes, and they have been doing these backups for years now, with ImageManager managing the output images automatically (collapsing them periodically to weekly and monthly collapse files, cleaning up the unnecessary files as time passes)), so we are literally entrusting our entire business in the hands of our product. Eating your own dog food, as this practice is called, is one of the best ways to ensure that your product is solid. But, like I said, don't trust me or any marketer when it comes to your data's security. Test the products themselves, even though it's time consuming, to find the one that truly fulfills your own requirements.

 

That might seem so, intuitively, but I'm going to respectfully disagree with the above statement. A single base image is just a collection of sectors. A base image with some incremental files is, also, ultimately, just a collection of sectors. The statistical probability that you will be unable to restore because of corruption (assuming the images were good to begin with) ruining some of your image(s) sectors depends entirely upon the cumulative size of those images in sectors. The more sectors, the higher the probability that one can rot. In practice, incrementals are generally rather small files (small sets of sectors) and hence there generally isn't a significant difference in cumulative number of sectors between the case where only a base is generated vs the case where bases and incrementals are generated (perhaps 20% more sectors after an extended period of time, having generated many incrementals). Therefore, the probability that corruption will occur in one of the sectors of the base image for the base-only case isn't much different than the probability that a sector will go bad in one of the images in the base+incremental(s) case. And, interestingly, there is actually a distinct advantage if the corruption occurs outside of the base image in the base+incremental(s) case as all of the previous (chronologically older images than the one that is corrupted) images will still be useful for restore, whereas when corruption occurs in the base (in the base-only case) the image often cannot be used for restore, at all.

Although I disagree with the premis that it's dangerous because of an increased risk of corruption, I agree, to a degree, with your argument, namely that incremental imaging can be dangerous, but I would qualify and support that argument with different premises, based on the results of experimentation that I've done with imaging products that support incrementals. They don't all work correctly. It just occurred to me that perhaps this is what you meant by corruption, and that I may have misunderstood you, in which case I apologize. Some claim to support incremental imaging, and at a casual glance may appear to deliver, when in fact they don't. Make sure that you test them very thoroughly, taking incremental backups under extremely heavy I/O, and then test those backups to ensure that they're good. I recommend that interested parties sink their teeth into this relevant test.