Block-Level Backup and Restore

The one backup technology that can provide comprehensive restore while bridging the performance and capability gaps left open by file backups is the block-level backup. Block-level backup, as opposed to file-level backup, does not backup any files. Block-level backup works on the storage elements that lie immediately beneath your files, called allocation units or “blocks.” At this level, the backup software can work directly with your raw storage irrespective of anything else going on in the system. This makes configuration very simple and operations very robust.

This backup technique has some inflexibilities that come with it, and for those reasons it is a poor substitute for file-level backup for the same reasons that a file-level backup is not a substitute for a block-level backup. However, they compliment each other impeccably as parts of achieving the overall data protection goals of an organization.

File-level backups operate on a granular, microscopic level, while block-level backups function on a more comprehensive macroscopic level. Put simply, file-level backups are better at protecting you from data loss, and block-level backups are better at protecting you from downtime.

In the past this technology was referred to as “bare metal backup,” “BMR,” or “volume-level backup” among other names. As adoption of virtualization technologies increased and became the norm for IT infrastructure, the “bare metal” of computer hardware became meaningless and the colloquial usage has shifted to simply “image backup” because the backup data is stored as a series of “images” that are representations of a production computer, server, or hard disk.

While we all prefer the term image backup, we will sometimes use it interchangeably with block-level backup to emphasize the difference from file-level backup and to avoid confusion with other data types that are also called images.

When you restore an image backup, the resulting data is identical at the block level to the volume that was backed up. This means that any operating system, application, or file system residing on the volume at the time of backup will be restored identically.

At a minimum, a good image backup will give you at least all of the following capability:

• Create full and incremental backups of your volumes on separate full and incremental backup schedules
• Compress the backup data to conserve backup storage
• Provide a bootable recovery environment that can restore your images to volumes on any type of hardware
• Retain a history of past image backup series for however long you want
• Send you an email report of backup progress/status

While a great image backup will give you even more capability and flexibility:

• Have some form of CBT (changed block tracking) for creation of incremental backups very rapidly and very often
• Provide a means of sending the images to cloud storage for recovery of machines in a cloud or secondary site
• Let you pre-stage a restore of your images to hardware you may have on standby in order to minimize downtime
• Let you treat the image backup as a virtual disk and boot the image as a VM or mount it in an existing machine
• Provide a means of executing custom programs, commands, or scripts before and after the backup
• Provide a (automated) means of checking the integrity of your image series
• Provide a centralized management where you can monitor and administer all of your backups in one place

The high performance of image backup, and more importantly image restore, comes from 2 fundamental differences from other types of backup.

First, unlike other backups, an image backup is actually capable of fully restoring a functioning computer or server operating system and whatever applications were in use, complete with all of their data and configuration. While that is not a performance metric, it is impossible to ignore the fact that installing and configuring systems and programs from scratch takes time. It means that you are spending a lot of precious downtime waiting for a human being to manually complete their setup tasks before you can even begin to restore your data.

The ability to skip all of that will save at least an hour of labor and an hour of downtime per system. In a complete disaster recovery scenario, the kind of time savings you can get from immortalizing very complex systems and recovering them in parallel at the block level adds up quickly and is nothing short of colossal.

Second, there is no speed limit imposed by the overhead of too many atomic file system operations during an image restore. The file table and volume information are restored from the image along with the rest of the volume data, and it’s all done at the same speed. The two example data sets mentioned in the previous section that would have utterly confounded a file-level restore would also both restore at virtually the same speed. During a block-level restore, your data transfer rate will only be limited by whatever performance your storage or network hardware can provide.

However, the relationship between how fast you can transfer data and how long it takes you to get back into production is a complex one, and image backup is not a miracle product. It is possible to configure an image backup in such a way that does not give acceptable restore performance. It is also possible, just like with a file backup, for bad setup and bad organization in production to become performance penalties during an image restore.

Remember, block-level backups don’t backup files, they backup blocks. While a block-level backup is running, it cannot see your files. It doesn’t even know what a file is, so it also can’t see what a file isn’t. All it can do is backup all the allocated blocks on a volume during the initial (or full) backup, and thereafter, it will backup whatever blocks are different than what they were originally to a subsequent image called an incremental image, and that incremental image will even include references to blocks that are no longer used.

Block-level backup has been around for many decades and it is a recent development that some block-level backup products can ignore empty space during a backup. In the absence of that capability, we relied on data compression to minimize the footprint of empty space in our image backups. Many modern products can now ignore empty space during the initial full backup, but any changes to any blocks that occur afterward become part of the image series.

Additionally, empty space must always be “restored,” meaning you cannot restore an image of a 500 GB volume directly onto a 499 GB or smaller disk. Image restores require at least the same amount of allocated space on the destination disk that the originating disk had.

Some tools may allow you to change the dimensions of a partition in an image, but that can be difficult or impossible if you have sprayed data over a large allocated space and you don’t want to risk truncating it.

For this reason, you want to avoid hoarding too much empty space on your production disks, because it can complicate matters when restoring to dissimilar hardware.

To perform a restore, you must first restore the full image, and then whatever incrementals occurred will be restored afterward in the same order that they were created. You can approximately consider the full image to contain all the used blocks on the volume, and think of each incremental image as a log of changed blocks for a given time period.

A full image restore performs at its very best when you have the fewest and smallest incrementals possible, and you achieve this in two ways.

The first way is to keep that “log of changes” as small as you reasonably can. Like we have discussed in the preceding sections, there are considerable benefits to good storage organization in disaster recovery planning and execution.

For example, if a server’s system volume becomes littered with user profiles, file shares, database software, and automatically generated maintenance data like database dumps and local backups, desktop backups, file history backups, and so on, you will have a lot of writes, and a ton of change, occurring all the time on that volume, and that will result in large incrementals. Unnecessarily large incrementals will increase your restore time no matter how fast you can transfer data.

In that very common example, most of those writes will not be production writes, and none of that data should all have the same restore priority in your recovery plan, so why have that much unrelated data all on the same volume?

Put another way, if in that same example your server came direct from the manufacturer with one big “C:” drive, it is not because they want you to use it that way. Only you can know how to organize the storage correctly for your use case.

Storage volumes that are dedicated to one purpose and organized strictly in accordance with your disaster planning and restore priorities will simply be faster, easier, and more parallel to work with in backup and restore operations.

While planning and preparing for block-level backup and restore, your storage layout must support your data protection goals, reflect your restore priorities, and meet your recovery performance requirements. This can only be assured through regular testing of your disaster recovery procedures.