“It’s all about recovery” is a favorite mantra of backup marketing material. The truth is that it is not all about recovery. In fact, it is easy to make a case that recovery is the easy part. The actual backup and the storing of the protected data is the hard part. A recent study conducted by StorageCraft reveals that 51% of organizations are not confident in their ability to recover data rapidly, 43% are struggling with data growth and believe it is going to get worse, and 51% think they would benefit from a more frequent backup. Two out of the three top concerns have to do more with backup than recovery.
Improving Backup Frequency
Every organization wants to recover data rapidly. But rapid recovery has two parts; how quickly can data be positioned for recovery and how much data is lost as part of the recovery effort. The first problem is solved by the various live and instant recovery features that vendors claim to have. The second problem is solved by capturing data more frequently so that less of it is lost.
The backup application should capture data in relation to how quickly the data changes. For example, a production database updated constantly throughout the day should be protected as often as possible, potentially every 15 minutes or less. Data that is modified occasionally throughout the day only needs protection once per day.
Increasing backup frequency can be done by many methods. The key to frequent data backup is to identify the data that changed and copy only it to the backup device. Block level incremental backup and change block tracked backup not only recognizes the data that has been changed, but they also make sure only the smallest element of data is moved to the data protection device.
The Problem with Frequent Backups
The downside of frequent backup is the backup software has to interface with the backup application more frequently. The application has to be placed in backup mode, have its changed components copied to protection storage and then move back into production mode. All of these steps impact performance of the production application, so IT needs to use caution as to how often it executes the backup and pay attention to how efficient the backup software is at interfacing with the application. Hot backup is not a checkbox item. IT should test it and compare the results with other backup applications.
The other problem with frequent backups is how that data is stored on protection storage. When using a block level or change block methodology, the software will typically create a full image of whatever it is protecting and then store a succession of files that reflects the changes captured during each successive backup. With some solutions, the number of incremental files can create a performance bottleneck on recovery because so many files have to have components pulled from them in order to restore the database or file system back to what it looked like before failure.
With most incremental or change block backup solutions a consolidation job is required to reduce the number of files that are linked together. The consolidation job creates a new master from all of the existing incremental files. It can take longer to create this new master than it does to create a new master via a full backup.
Other solutions perform more of a reverse incremental. When a block level or change block tracked backup is performed, instead of storing those files separately the incremental immediately merges into the master file. The data it replaces moves to a separate file. The master essentially becomes the latest working copy, and external files are for point in time historical recoveries.
The difference between the two methods is performance. The method of separately storing all the incremental jobs leads to faster backup performance. The reverse incremental backup method leads to faster recoveries and eliminates the need for time-consuming consolidation jobs.
Backup frequency can be improved. The block level and change block backup methods are proven. IT just needs to consider the potential downsides of the various methods and choose the method that makes the most sense. In either situation, the upside of not losing data far outweighs the downsides.