Backup and Restore Practices

Backup and restore cannot be implemented in a haphazard manner. A clear strategy needs to be designed before any hardware is purchased or software is installed. A system architect's or administrator's strategies will be driven by the needs of the organization. Most policies and procedures are unique to an organization and its goals. Certain practices are common to most backup operations, however.

Single-Tape Backup

An all-too-common and unfortunate practice for backup is to stick a tape into a drive and overwrite it each night. Smaller companies with limited resources often fall back on this method. The behavior is rationalized as the only thing they can do, given the resources available. They tell themselves that at least they're doing backups. This is a strategy (or nonstrategy) doomed to failure. Media will wear out quickly and fail. If a time does come when data needs to be restored, and there is a failure of the tape media, the data is lost.

The bad part of this practice is that if the tape is taken off-site, it can easily be lost or forgotten, making the next day's backup impossible. At that point, a good practice off-site storage has turned into a bad one, namely leaving data unprotected. Worse still, if the tape is simply left in the tape drive and a disaster hits, the backup will be destroyed along with the original data store. So although it may seem convenient to keep a tape in the tape drive of a server, it is a very dangerous practice.

Rotating Backups

The best way to manage backups is to rotate the backup media. With this practice, a backup is performed, and the media is removed from the backup unit. A new set of media is then used the next day, and so on. At the end of some period of time, the media can be reused.

This rotation can happen in any period, but the longer, the better. Having backups that go far back in time not only keeps wear and tear on the media down, but also makes it possible to recover objects that have been lost since the last backup. If, for example, the backups are rotated on a weekly basis, files deleted as long as a week ago can be retrieved. The deleted files may not have been noticed as missing until days had gone by, and the backups from the past few days would not have the files on them. The backup from a week ago will have the files, however, and the "lost" data can be recovered. Backup schedules that rotate tapes monthly provide the same protection going back an entire month.

Typically, a monthly rotation is established. A backup is done each day often, an incremental backup and a full backup is performed each week. These backup sets are moved off-site at the end of each day and week until a month's worth of backup sets is created. At the end of the month, a monthly full backup is performed and moved off-site, and the media from four weeks ago is reused.

This rotation schedule provides a great deal of protection. Objects deleted as long as a month ago can be retrieved. The chance that data will be corrupted on all the backups is quite slim unless the original was corrupted a very long time ago. Even then, the monthly backup from the previous month might still have a good version of the object, which can then be restored.

There is a downside, of course: the number of media to manage. Let's take the previous example of the 160-gigabyte disk being backed up each day to tape. Assuming that daily incremental backups take only one tape, and that weekly and monthly ones each require two, more than two dozen tapes are needed each month. Each week, four tapes are used for incremental backups, two more for the weekly, and two each month for the monthly. In a typical month, that is 26 tapes (4 x 4) + (4 x 2) + (1 x 2) = 16 + 8 + 2 = 26 to manage.

In an enterprise with a large amount of data to back up, media management can become a real source of cost and error. With so many tapes to deal with, it is not unusual to have wrong tapes placed in tape drives, ruining entire weekly backup sets. Media can also get lost, losing entire weeks of backup protection. Certain backup units, such as tape libraries, mitigate the management problem by automating media management, but even this is not a complete solution, because problems can still occur when media is sent off-site.

Disk-to-disk backup systems can support a rotational backup schedule automatically. The backup unit has to provide enough disk space to accommodate the sheer amount of data that needs to be backed up usually a week's worth of backups. Because of the speed of disk-based systems, schedules based on hours can be accommodated, assuming that sufficient disk space is available for the data. These systems also make doing full backups each day easier to perform.

A disk-to-disk to tape system has some advantages over tape or disk-only systems, depending on how it's implemented. If the disks are copied to tape each night, it is likely that the media management problem will persist. It could get even worse. More tapes are often used, because incremental backups are being performed throughout the day, and a daily full backup is performed each day. On the other hand, if only weekly and monthly full backups are copied to tape and sent off-site, the media management problem will be somewhat alleviated. The tradeoff is that any problems with the disk-based backup system mean that data will have to be restored from tapes that are a week old. The potential for lost data goes up considerably.

Full and Incremental Backups

A full backup is just what it sounds like: All selected objects are copied to the backup media. The advantage to a full backup is that you get a complete copy at a point in time. When it becomes necessary for a restore operation to be performed, the full backup set will have all the information necessary to restore the system completely. Full backups take a long time and require more backup storage space, whether it is tapes, disk space, or other media. Overall full backups make restore easier and backup more difficult.

An incremental backup copies only those objects that have changed or that are new since the last backup. Other objects are not copied to the backup media. Much less data is created or changed on any given day than is stored in the primary storage. Even though large amounts of data may be read during a period of time, much less is written.

The advantage of an incremental backup is that it takes much less time to perform. There is simply less data to back up. For the same reason, incremental backups require fewer media. When it is time to restore data, however, incremental backups take more time. The last good full backup has to be restored first; then all incremental backups from that point on have to be loaded. The full backup has the system state at that point in time, and the incremental backups have all the changes after that. If a hard drive crashes on Day Five of the backup cycle, the previous week's full backup will be restored first. The four incremental backups will also have to be loaded to bring the system to its original state. The additional time to restore data to its last good state can be considerable.

The use of full and incremental backups together over the course of a week provides a balance between the advantages and disadvantages of each type of backup. This is why it is rare to perform only a complete backup each month and incremental backups thereafter. The number of tapes and amount of time needed to restore a system to its proper state are unreasonable.

Tip

A group of backups, incremental and full, is called a backup set. One full, weekly backup plus the four incremental backups are a weekly backup set. With the monthly backup added, it's a monthly backup set. A complete cycle is often called a complete backup set.

Selective Backup and Restore

Most backup processes center on backing up entire volumes and disks. The events that most commonly drive backup procedures are hardware system failure (especially hard drive crashes), wholesale disasters that destroy data centers (such as earthquakes and floods), and corruption of a volume's header information resulting in an unrecoverable volume. The best remedy for these situations is a restore of the entire disk or volume from a full backup.

Backing up entire volumes and disks is usually wasteful. Operating systems and application software come on CD-ROMs or DVD-ROMs that are nearly indestructible, if kept in a safe place, and that can be replaced quickly if necessary. A great deal of media, be it tape, disk space, or CD-RWs, is wasted backing up software that is on another media already. It's the data that needs protection, not the purchased software.

It also creates the "needle in the haystack" problem. The chance that a disk will fail is lower than the chance that an important file will be deleted or damaged accidentally. The more data on the media, the more difficult it is to restore a single object. The backup software has to sift through all the data just to find a single object that needs replacing.

One option is to back up only select objects, especially those that are most subject to change. It makes sense to back up the database every day, but not the actual database software. Even configuration files and databases do not change very often. They can be archived instead of being backed up every night. Some items change so often that a backup is not worth it. System log files, for example, are important to detecting and diagnosing problems. They change constantly, and the data in them is rarely necessary to the operations of a server. Making copies of log files during the analysis of a problem makes sense; keeping them around on a monthly backup is wasting backup storage space. The same is true for virtual memory space.

For those system administrators who have very limited backup resources, selective backup is a time- and money-saving option. Very sophisticated systems, especially disk-to-disk backup systems with advanced backup software, reduce the advantages of selective backup.

Snapshots

Although often looked at as part of backup strategies, snapshots are not backups. They are point-in-time virtual copies of the file system. No data is copied to a backup media. Instead, the state of the file system at a particular point in time is recorded. Similar to transaction tables in a database, snapshots allow the file system to be rolled back to a known good state if something is changed in an undesirable manner. Although snapshots are a good tool for managing data, they do not take the place of a backup.