Know Thy Backups – Part II | Futurist Transhuman News Blog

In Know Thy Backups – Part I, we started discussing the most common strategies of backing up your data, and before we continue that discussion, I should clarify that we’re not talking about hardware configurations like RAID or backup products like Evault and Data Protection Servers. These backup schemes can be executed without spending a dime on additional equipment or resources. While there are best practices and recommendations for making backups and keeping them safe, if your budget is limited, you can protect and preserve your data using one of these schemes on your local workstation or on a secondary drive in your server.

When we looked at the full server and simple incremental backups in our previous post, we noticed a significant limitation: losing a single backup can be catastrophic to restoring data. In the next two schemes, we’ll evaluate solutions that protect us from this vulnerability.

Differential Incremental Backups

A differential scheme requires a full backup reference point and then makes a backup of all changes to the server from that reference point on each subsequent backup. This method requires more storage space than incremental backups but generally doesn’t need as much space as a full backup.

Based on the volume of changes made between the first backup, the reference point and the current backup, differential incremental backups may require additional server resources than an incremental backup. Simple and multi-level incremental backups constantly update the reference point with minimal load, while differential backups update the reference point with a new full backup.

Example: Differential Incremental Backups

As in the previous example, I am using a schedule of backups that starts with a full backup on Sunday, with additional backups on the following days. This time, I’m using differentials. Let’s say that on Thursday I find some inconsistencies in the database when compared to the paper files I received from a vendor. After investigating, I find that my database is corrupted. I determine that I will not be able to recover the database as it is, so I review my backups.

Somehow, I cracked the DVD that my Tuesday backup was stored on, but all of the other discs are here. I start by restoring the Sunday backup and then the Wednesday backup, hoping the corruption occurred after the backup was made. Thankfully, the restoration works, and we are up and running again after losing minimal data. If I had been using simple incremental backups, I would have been able to restore only up to Monday because Tuesday’s backup disc was broken.

Multi-level Incremental Backups

There’s a more granular and robust backup scheme that is less vulnerable than simple incremental backups and less server-intensive than differential backups: The multi-level incremental backup. Multi-level increments assign a level to each backup and then make a comparison against the last lower-level backup made. Only the changes between the reference point and the current data are saved.

This arrangement allows you to design a backup scheme around your needs and the capabilities of your server, and you can decide how many backups you will need for a full restoration to the latest restore point. You will control the number of backups required for a given restore by determining the number of levels in the system. In the event of a disaster, you need a single backup of each level, and each higher level backup must use the lower level as its reference point.

Example: Multi-Level Incremental Backups

This time I am in charge of a Sendmail server that is always under heavy stress. Because this server is extremely important to my business, I need to ensure both its availability and responsiveness at all times. I also need to maintain archives of the e-mail on the server. To do this, I decide to implement a multi-level incremental backup scheme since I need more granular backup configuration that does not generate a great deal of load on the server. This scheme meets that need. It still retains the weakness of incremental backups, but I partially mitigate those weaknesses with scheduling.

At the first of every month, a full backup is scheduled. This is my Level 0 backup, and it is named level0.name of the month. The following day I run a Level 1 backup. This backup holds only the changes since the most recent Level 0 copy called level1.first.name of the month. The subsequent days of that week, I create a Level 2 backup called level2.first.day of the week.name of the month. This process continues until the Sunday after the first Level 2 backup.

On the next Sunday, I make another Level 1 backup called level1.second.name of the month. The subsequent days of that week, I make Level 2 backups called level2.second.day of the week.name of the month. I continue in this vein with every Sunday being a Level 1 backup and the rest of the week being Level 2 backups until the end of the month. On the first day of the next month, I start all over with another Level 0 copy.

I make certain to save multiple copies of the files after I test the archive. I also check to be certain it’s not corrupted, to minimize the risk of data loss through a faulty archive. This scheme allows me to restore to any point within the month in just three steps, as long as all of the archived backups work.

If I need to restore the data from April 17, 2009, I would need the archives for level0.april, level1.third.april, and level2.friday.third.april. I would restore them in sequence from Level 0 to Level 1 to Level 2.

Choosing Your Backup Scheme

As I said in the beginning of this post, these backup schemes are available to you without the use of an additional server or any expensive backup management software. All of the above are viable options for making your backups; however, not every scheme is perfect for every situation. You should review your requirements and the available resources to determine which scheme best fits your needs.

-Ben