Kelly Lipp - Vice President, Manufacturing and CTO

Kelly Lipp graduated with a degree in Electrical Engineering and Computer Science from the University of Colorado. As a System Engineer at Ford Aerospace, he was responsible for delivery of hardware and systems design and documentation. Moving to Digital Equipment Corporation as a systems administrator in the storage division, Kelly became an expert on the OpenVMS operating system, storage and networking. In 1995 he, along with three others, formed Storage Solutions Specialists, Inc., to work with IBM to develop the Tivoli Storage Manager client for OpenVMS. The company discovered a need to make TSM simpler and the focus changed from software to appliance development. STORServer, Inc was formed to further these efforts. Currently as Chief Technical Officer of STORServer, Inc. he is responsible for developing appliance solutions meeting diverse customer needs in the backup and storage environment.

Let's get this started!

No, data replication and data backup are not interchangeable either in word or in application. 

Replication allows for very rapid (in some cases) restoration of data (usually an entire logical drive, or volume) to a relatively recent point in time.  The goal of replication should be high availability of an application, not backup/restore.  Using replication, it should take seconds to restore all of the required data.  Replication is generally very good at restoring large objects (and entire disk of data or a very large application file).

Backup / restore allows for restoration of a piece of data to a particular and flexible point in time.  The desired data may have been backed up on a daily basis for the previous month and we may want a file from three days ago.  Backup/restore provides an easy mechanism for viewing all versions of the file and an easy way to initiate a restore.  Finally, generally speaking, backup/restore should be very good at recovering small objects.  Store them on disk rather than tape to speed this type of restore.

The goals of the two technologies is different.  To find a specific file from 30 days worth of snapshots, especially if you are not quite sure which file is required, is tedious.  From backup/restore it is easy.  On the other hand, restoring a very large database, let's say a couple of hundred GB of data, is time consuming.  From replication, that is easy.

Replication?  Lots of data, fast and most recent.

Backup/Restore? Some data, perhaps a bit slower, and a specific point in time.

So really, you may need both to have an effective strategy for handling data corruption.