Block-Level Incremental Backup

Posted by
November 04, 2008

10:30 AM -- While Block-Level Incremental backup (BLI) is not exactly de-uplication, it is often compared to source-side de-duplication and it does reduce the amount of data that goes across the network.

BLI acceptance often comes down to overcoming a key negative that users need to decide whether they want to accept. The initial backup data set consumes as much capacity as the data you are backing up: essentially a 1:1 data cost on your first backup, compared to source-side de-dupe that, depending on the data set, may reduce the initial backup set as much as 3X or more.

From there, BLI gets interesting -- all subsequent backups are only the blocks that have changed since the first backup so data growth should slow dramatically. Typically, a snapshot is taken prior to subsequent backups to preserve a versioning capability. Testing has shown that the client-side impact of doing this backup is minimal and is fairly quick, taking less than five to ten minutes to transmit the data. Client-side impact is minimized since only changed blocks need to be identified; there is no comparison process with the backup target. This lack of client impact and slow additional growth means that multiple backups throughout the day are not out of the question.

Even though blocks are being backed up, recoveries can be granular to the file level, and, with proper integration to the backup application, those recoveries can be all driven from a single GUI.

In some systems, the backup target is also "active," meaning that the data being backed up is stored as a file system and is accessible outside of the backup application. The ability to amortize the backup data for more than just storing backups can dramatically improve the ROI of the backup process.

Related Reading

More Insights