W. Curtis Preston - Modern Data Protection: Ensuring Recoverability of All Modern Workloads

There is no more basic concept of backup and recovery than to understand that the only reason we back up things is to be able to restore them. And the only way youll know whether you can restore the things youre protecting is to test your ability to do so. Regular recovery testing should be a fundamental part of your backup system.

Besides testing the validity of the backup system and its documentation, regular testing also helps train your personnel. If the first time theyre executing a big restore is when theyre doing it in production, such a restore will be a much more stressful situation and more likely to be error prone. If theyve done such a restore multitudinous times, they should just be able to follow their usual procedure.

You should regularly test the recovery of anything and everything you are responsible for. This includes small things and very large things. The frequency of testing of each thing should be related to how often a restore of such a thing happens. A few times a year might be appropriate for a big DR test, but you should be restoring individual files and VMs at least once a week per person.

The cloud has made all of this much easier, because you dont have to fight for the resources to use for recovery. You just have to configure the appropriate resources in the cloud and then restore to those resources. This is especially true of large DR resources; it should be very easy to configure everything you need to do a full DR test in the cloud. And doing this on a regular basis will make doing so in production much easier. Tests should also include restoring common things in SaaS services, such as users, folders, and individual files or emails.

Backup Levels

There are essentially two very broad categories of what the backup industry calls backup levels; you are either backing up everything (i.e., full backup) or you are backing up only what has changed (i.e., incremental backup). Each of these broad types has variations that behave slightly differently. Most of the backup levels are throwbacks to a bygone era of tape, but its worth going through their definitions anyway. Then Ill explain the levels that are still relevant in .

Traditional Full Backup

A traditional full backup copies everything from the system being backed up (except anything you specifically told it to exclude) to the backup server. This means all files in a filesystem (unstructured data) or all records in a database (structured data).

It requires a significant amount of input/output (I/O), which can create a significant performance impact on your application. This is especially true if you are pretending that your VMs are physical machines, and you happen to be performing multiple, simultaneous, full traditional backups on several VMs on the same hypervisor node.

shows a typical weekly full backup setup, with three types of incremental backups that I will discuss next.

Figure 4-1. Full and incremental backups

Traditional Incremental Backup

A traditional incremental backup will back up all filesystem files or database records that have changed since a previous backup. There are different types of incremental backups, and different products use different terminology for the different types. What follows is my best attempt to summarize the different types.

Unless otherwise specified, incremental backups are full-file incremental backups, meaning the system will back up a file if the modification time has changed or its archive bit has been set in Windows. Even if the user changed only one block in the file, the complete (i.e., full) file will be backed up. Block-level incremental and source-side deduplication backups (both of which are discussed later in this chapter) are the only incremental backups that do not behave this way.

Typical incremental backup

A typical.

Cumulative incremental backup

A cumulative incremental backup backs up all data that has changed since the last full backup. This requires more I/O of the backup client than a typical incremental, and requires more bandwidth to transmit and more storage to store (assuming youre not using deduplication). The advantage of this type of backup is that you only need to restore from the full backup and the latest cumulative incremental backup. Compare this with the typical incremental backup, when you need to restore from the full backup and each subsequent incremental backup. However, the advantage of this type of incremental really goes by the wayside if you are using disk as your backup target.

In , you can see a cumulative incremental backup being run on Saturday night. It backs up anything that has changed since the full backup on Sunday. This would happen regardless of which night it is run.

This type of backup is often called a differential, but I prefer not to use that term, because some backup software products use that term to mean something very different. Therefore, I use the term cumulative incremental.

Incremental backup with levels

This type of incremental backup uses the concept of levels, each specified by a number, where 0 represents a full backup, and 19 represents other incremental backup levels. An incremental backup of a certain number will back up everything that has changed since a previous backup one level down. For example, if you run a level 2 backup, it will back up everything that has changed since the last level 1 backup. You can mix and match these levels for various results.

For example, you might do a level 0 (i.e., full backup) on Sunday and then a level 1 every day. Each level 1 backup would contain all data that has changed since the level 0 on Sunday. You could also do a level 0 backup on the first day of the month, a level 1 every Sunday, and a series of backups with increasing levels the rest of the week (e.g., 2, 3, 4, 5, 6, 7). Each Sundays backup would be a cumulative incremental (i.e., all data changed since the level 0), and the rest of the backups would behave as typical incremental backups, just like in the top half of .

An interesting idea that uses levels is called the Tower of Hanoi (TOH) backup plan, which is illustrated in the bottom half of . Its based on an ancient mathematical progression puzzle of the same name. If youre still backing up to tape and are worried about a single piece of media ruining a restore, TOH can help with that.

The game consists of three pegs and a number of different-sized rings inserted on those pegs. A ring may not be placed on top of a ring with a smaller radius. The goal of the game is to move all the rings from the first peg to the third peg, using the second peg for temporary storage when needed.