Replication vs Offsite Backup

You may have read some of my previous postings where I encourage everyone to maintain offsite copies of data. One method for getting your data off site to protect against a disaster at your main site is replication. Most database servers have built-in replication functionality. There are third-party products that can be used replicate data across a network. Replication has one advantage over backup in that the data is usually replicated soon after it arrives at the primary server. Relatively little data would be lost if the primary server were lost because the replication server would be within a few minutes of the primary server. Of course in order for replication to be considered a form of offsite backup, the replication server must be in a different physical facility than the primary server, preferably with some distance between the two.

While using replication to backup your data to an offsite location has the advantage of being very current, there are some significant exposures that you should be aware of. First of all, there is the potential for human error or malicious code that destroys the data on the primary server causing the same data to be destroyed on the replication server. With replication, many of the causes of data loss would also be replicated to the secondary server. Another significant area that needs to be covered are historical backups. With pure replication, you don't have any way to retrieve an older copy of your data.

Bottom line is that you may need to do both. Replication serves to keep a standby copy of your data that can be used in case of a disaster at your primary facility. But replication does not protect you against some of the more common forms of data loss involving intrusions, viruses, and human error. A recent backup may be needed to restore erroneously updated data. A good assessment of your backup and recovery policy is the best way to make sure that you are adequately protected against costly data losses.