Advanced Bit Backup Technology

BitBackup or "delta change" technology can substantially reduce the amount of time it takes to perform an online backup of a large file. It does this by identifying and archiving only the records within the file that have changed since the last time a complete backup of the file was performed. For example, consider the case where a critical database of customer records is updated daily. Over time, this file will tend to grow large. However, the amount of data added or deleted on any day may be just a few records.

With a traditional approach to backups, if even a single record in a file changes, a complete copy of the entire file must be transferred to the server. This complete backup could take many hours to perform and result in substantial usage of offsite storage for each copy of the file maintained.

BitBackups Are Different.

When performing a BitBackup, a complete file backup is performed the first time. But, on subsequent backups, the software determines the records that have changed since the initial backup and transmits only the changed records (plus some administrative information) to the offsite storage server. Since the size of the changed records is likely to be much smaller than the size of the entire file, a BitBackup may take just a few minutes to complete. In cases where multiple file copies are maintained, BitBackup technology reduces the use of disk space on the offsite storage server. BitBackup technology makes extensive use of a local reference disk cache. It also has built-in management intelligence to determine whether it is appropriate to transmit file changes, or to GÇ£roll forwardGÇ¥ and perform a complete backup of a data file. Databases, Outlook personal storage files (email), large documents and any other data files which change only modestly each day are ideal candidates for a BitBackup.

Step-by-Step Walkthrough Of A BitBackup

The diagram below provides an illustrated version of how BitBackup operates. Depicted is a single database file that is being backed up nine (9) times, presumably on nine consecutive days.

The first dayGÇÖs backup, illustrated above by the rectangle labeled GÇ£1GÇ¥ shows a complete backup of the database being transmitted to the offsite server. At the same time, a reference copy of the database is stored in a local cache on the client PC.

On day two, when the BitBackup ran, it detected that there were changes in the production database file. It then compared the database file in its reference cache to the current database in production on the PC. A small number of records were identified as actually changing. These records, along with some administrative information were then compressed, encrypted and transmitted to the backup server.

On day three there were more changes to the database. Once again, a comparison was made between the production database and the original reference copy in the local cache on the PC (from the backup performed on day one.) The number of changes was still relatively small and this data was transmitted to the offsite storage server.

On days four and five, the process repeated. However, four days have now passed and the version of the database in the local cache differs greatly from the version now in production use. The amount of changed data records being sent over to the server is now substantial since the changes have accumulated for several days.

On day six, more changes were made to the production database. However, because the number of changed records (from the original version) is now substantial, the BitBackup software has decided to perform a complete backup of the file versus sending a large number of change records. Note: We call the process of retransmitting the entire database file a GÇ£roll forward.GÇ¥ A complete backup is transmitted to the server and is also copied to the local reference cache GÇô replacing the version originally stored on day one.

On days seven, eight and nine, the process continues. Note that the change records transmitted now reflect differences in the production database when compared to the roll forward backup performed on day six.

By enabling BitBackup for this database file, and permitting use of a local reference cache on the client PC, we are able to significantly reduce the amount of offsite storage and reduce the overall time required to perform backups on most nights (except roll forward refreshes.)

Restoring a File Using BitBackup

The diagram below overviews the process of restoring file number eight (see example above) from the offsite storage server.

To BitBackup, file eight is actually reference file number six with changes from day eight applied. So in order to reconstitute the backup from day eight, the software restores change file eight and GÇ£parentGÇ¥ file number six. It then uses the administrative information in change file eight to combine files six and eight into the restored file eight. Please note that this is the technical explanation of how Bit Backup works. When using the program you don't deal with any of these steps, the remote backup program does it automatically. You just get the data back. Note: In some cases, it may be possible to restore your data files from the local reference cache without the need to retrieve the data from the offsite storage server which could be vital if your internet connection was down.