May 20, 2009, 4:27 PM — Once you’ve made the decision to put in a backup and disaster recovery system, then the big question is, how often to back up? Those of us of a certain age will remember when backup was done to tape, and the process was labor-intensive and involved pushing around large racks of tape to a storage room, and eventually to an off-site facility—and retrieving anything off of those tapes was an exercise in frustration.
Even today, especially in small to mid-size businesses, backup is a daily process, which is still labor-intensive, and is a poor use of a highly-paid IT staffer’s time. The daily backup process is an excellent protocol for some businesses, primarily SOHO users and smaller organizations, and is highly recommended. This “Single Point In Time”, or SPIT approach, creates a snapshot of every transaction that takes place up to that point. For non-transactional environments, this is often adequate, and most small businesses still use this type of fixed-schedule backup. If you have a small office with just a few computers and a server or two, doing a daily backup does not take much time at all, and depending on your backup system, is mostly automated.
But for larger organizations running highly-sensitive data processing applications, the daily backup may not be enough. In a large enterprise, the data entry process may be entering in tens of thousands of records on a daily basis. Suffering an outage and having to revert to the previous day’s backup still results in loss of a day’s work, which can in some cases represent a major loss. In these cases, continuous data protection (CDP) is called for. The cost and ease of implementation of CDP environments has become much more favorable, and this is now a realistic possibility even for smaller organizations that have requirements that go beyond the utility offered by Single Point In Time backup.
The CDP technology doesn’t rely on a once-a-day backup for transactional data; rather, it replicates every transaction on an ongoing basis, logging it simultaneously in the primary server and a redundant server, and then allows for a failover mechanism and a roll-back to any previous point in time.
