How CDP saves your bacon

* It's hard to get more granular than continuous backup protection

Continuous data protection is changing the way IT is doing business. In the bad old days when computers had lots of lights, toggle switches (you old guys probably knew them as "sense switches") and whirling tapes all over the place, backups were generally divided into two categories. In most shops, full backups (backup every file in the place) were usually run on weekends because that was the only time when most people weren't using the machines. Incremental backups were run every night during the third shift for the same reason. For incrementals, of course, we were only backing up files when a flag had been flipped to indicate that the file had been changed.

Continuous data protection is changing the way IT is doing business.

In the bad old days when computers had lots of lights, toggle switches (you old guys probably knew them as "sense switches") and whirling tapes all over the place, backups were generally divided into two categories. In most shops, full backups (backup every file in the place) were usually run on weekends because that was the only time when most people weren't using the machines. Incremental backups were run every night during the third shift for the same reason. For incrementals, of course, we were only backing up files when a flag had been flipped to indicate that the file had been changed.

The problem of course - and it's one that continues to this day - is that if a user messed up a file, IT was only able to recover back to the most recent backup. At best, the granularity of recovery meant that you would be rolled back to the previous evening's incremental - not a particularly bad thing if you blew away your work early in the morning, but if your problem occurred toward the end of the day, you might have lost a full day's worth of work.

Those of us who worked in development learned to save to new files, and to do so often. If you were working on a FORTRAN compiler, for instance, you saved your work as "FTN001", and then as "FTN002" after adding a few more lines of code; if you blew away the second file, you picked up again by going back to the first file.

Obviously, even with workarounds, the fulls-plus-incrementals approach didn't offer much in the way of aggressive recovery point or recovery time objectives, nor did it contribute much in terms of efficiency. Even today, when snapshot techniques can make things much better by enforcing a much-improved level of granularity on the backups, the time between one snapshot and another is still a window of vulnerability.

Time-based backups - that's what the full/incremental/snapshot technique is - are now giving way to a much better approach. CDP is event-based. This means that every time a "data-changing event" takes place on the disk, the change is captured on the backup medium. It's hard to get more granular than that.

Most CDP backups write to SATA or some other relatively cheap disk device. This is that "second tier" storage - sometime called "nearline" which we hear so much about these days. The significance of writing backups to disk is hard to overestimate: disk-to-disk backups create an enabling environment for disk-to-disk recovery, which can be very fast and which, in several implementations, means end-users can recover data without involvement of the help desk. You can still run a weekly full backup to tape so you don't run out of disk space.

Next time we'll look at a CDP product that possesses the twin virtues of being both easy to use and cheap.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2006 IDG Communications, Inc.