1 Comment Written by Robert on May 18, 2008 – 5:09 am

Here the data is backed up (or replicated) as it changes, resulting in continuous backups. The data is replicated to a second host and then backed up from the second (target) host to tape. This moves the backup burden to the target system in exchange for a steady impact on the source system and the network. Real-time backup also offers you the opportunity to create versions based on more system-based events.

Markers would be used in the log stream to synchronize the source and target checkpoints with application quiescence. Some solutions today actually sit at the application layer, above the cache, and will replicate changes incrementally, rather than the entire filesystem. These software solutions may provide a higher level of protection in the event of a failure, since the replication may be committed before the actual source information is committed.

Backup of a filesystem is typically accomplished by copying files from the source hard disk across the network to a network server hosting tape drives. The backup system would need to ‘walk’ the filesystem in order to accomplish its task. The frequency of the backups is governed by practical considerations such as network impact, system impact, and available media. On the other hand, remote filesystem replication products monitor changes to file objects and copy these changes to a remote disk location for safekeeping.

Some solutions choose to do a full file copy, block-level changes, or simply incremental or delta changes of a file when they sense a file change. The remote replica can be utilized for disaster recovery in the case of major physical damage to the primary filesystem. Data protection in this scenario occurs in real time as objects change. Its use is usually governed by network impact, available replica storage, and overhead on the server.

What if we replicate only the block changes? Well, that’s being done today, with VERITAS Volume Replicator, FalconStor’s IPStor, EMC, Hitachi, and other solutions. What if we were able to back up only those changes for an infinite recovery level based on the retention of those blocks written to tape? Taking the block-level replication to the next level may include an option to integrate with the backup software that allows only those incremental changes to be written to tape, either continuously or scheduled. In the future, we may have the ability to recover a particular file from a particular point in time from blocks that are backed up or archived to tape after being migrated from the disk-based solution, providing an infinite level of recovery.

The challenges that we will continue to face will be the backup of these very large databases and filesystems, and how to best protect this critical data while ensuring we have a more than reasonable recovery time in the event of online data loss. The trade-off with this type of solution is the dependence on the potentially proprietary nature of the data written to tape depending on the backup software with which this solution was integrated. However, in this solution, disk would be the primary backup medium and the tape backup would only be for the backup server’s purposes.