In this chapter, I look at backup and recovery. Every Microsoft Windows Server 2003 system on your network represents a major investment in time, resources, and money. It requires a great deal of planning and effort to deploy a new server successfully. It requires just as much planning and effort—if not more—to ensure that you can restore a server when disaster strikes. Why? Because you not only need to plan and implement backup for each and every server on your network, you also need to perform backups regularly and test the backup process and procedures to ensure that when disaster strikes you are prepared.
Backups are insurance plans plain and simple—and every administrator should see them that way. When disaster strikes, your backup implementation will either leave you out of harm's way or drowning without a life preserver. Trust me: you don't want to be drowning when it should be your moment to shine. After all, if you've implemented a well-thought-out backup plan and practiced the necessary recovery procedures until they are second nature, a server that has stopped working is nothing more than a bump in the road that you can smooth out even if you have to rebuild a server from scratch to do it.
So where to start? Start by outlining a backup and recovery plan that describes the servers and the data that need to be backed up. Ask yourself the following questions:
How important is the role that the server is performing?
How important is the data stored on the server?
How often does the data change?
How much data in total is there to back up?
How quickly do you need to recover the data?
How much historical data do you need to store?
Do you have the equipment needed to perform backups?
Do you need to store backups off site?
Who will be responsible for performing backups?
The answers to these questions will help you develop your backup and recovery plan. Often you'll find that your current resources aren't enough and that you'll need to obtain additional backup equipment. It may be one of the ultimate ironies in administration, but you'll often need more justification for backup equipment than for any other type of equipment. Fight to get the backup resources you need and do so without reservation. If you have to make incremental purchases over a period of several months to get the backup equipment and supplies, do so without hesitation.
In most cases, your backup strategy should involve performing some type of backup of every server daily and full backups of these servers at least once a week. You should also regularly inspect the backup log files and periodically perform test restores of the data to ensure that data is being properly written to the backup media.
Tip
It's all about the data
Much of your backup strategy depends on the importance of the data, the frequency of change, and the total amount of data to back up. Data that is of higher importance or frequently changed needs to be backed up more often than other types of data. As the amount of data you are backing up increases, you will need to be able to scale your backup implementation. If you are starting out with a large amount of data, you will need to consider how much time a complete backup of the data set will take. To ensure that backups can be performed in a timely manner, you might have to purchase faster equipment or purchase backup devices with multiple tape drives.
Plan separate backup strategies for system files and data files.
System files are used by the operating system and applications. These files only change when you install new components, service packs, or patches. They include system state data.
Data files are created by applications and users. Application files contain configuration settings and data. User files contain the daily work of users and can include documents, spreadsheets, media files, and so on. These files change every day.
Administrators often back up an entire machine and dump all the data into a single backup. There are several problems with this strategy. First, system files don't change that often but data files change frequently. Second, you'll typically need to recover data files more frequently than system files. You recover data files when documents are corrupted, lost, or accidentally deleted. You recover system files when you have serious problems with a system and typically are trying to restore the whole machine.
Look at the timing of backups as well. With Microsoft Windows 2000 and earlier versions of the Microsoft Windows operating systems, you are often concerned about the time that backups are performed. You want backups to be performed when the systems usage is low, so that more resources are available and few files are locked and in use. With the advances in backup technology made possible by the Shadow Copy API built into Windows Server 2003, the backup time is less of a concern than it was previously. Any backup programs that implement the Shadow Copy API allow you to back up files that are open or locked. This means that you can perform backups when applications are using files and no longer have to worry about backups failing because files are being used.
When it comes to backup, there is no such thing as a one-size-fits-all solution. Often you'll implement one backup strategy for one system and a different backup strategy for a different system. It will all come down to the importance of the data, the frequency of change, and how much data there is to back up on each server. But don't overlook the importance of recovery speed. Different backup strategies take longer to recover than others and there may be differing urgencies involved in getting a system or service back online. Because of this, I recommend a multipronged backup strategy that is optimized on a per-server basis.
Key services running on a system have backup functions that are unique. Implement and use those backup mechanisms as your first line of defense against failure. Remember that a backup of the System State includes a full backup of a server's Registry, and that system configuration includes the configuration of all services running on a system. However, if a specific service fails, it is much easier and faster to recover that specific service than to try to recover the whole server. You'll have fewer problems, and it is less likely that something will go wrong.
Specific backup and recovery techniques for key services are as follows:
With Dynamic Host Configuration Protocol (DHCP), you should periodically back up the DHCP configuration and the DHCP database as discussed in the sections entitled "Saving and Restoring the DHCP Configuration," and "Managing and Maintaining the DHCP Database," respectively.
With the Windows Internet Name Service (WINS), you should periodically back up the WINS database as discussed in the section entitled "Maintaining the WINS Database".
With Domain Name System (DNS), your backup strategy will depend on whether you are using Active Directory-integrated zones, standard zones, or both. When you are using Active Directory-integrated zones, DNS configuration data is stored in Active Directory. By default, when you are using standard zones, DNS configuration data is stored in the %SystemRoot%System32DNS folder and backups of zone data are stored in the %SystemRoot%System32DNSackup folder.
With Group Policy, you should periodically back up the Group Policy Object (GPO) configuration as discussed in the section entitled "Maintaining and Troubleshooting Group Policy".
With printer servers, you should periodically back up the printer configuration as discussed in the section entitled "Preparing for Print Server Failure".
With file servers, you should implement Volume Shadow Copy (VSS), as discussed in Chapter 22, for all network file shares. This makes it easier to restore previous versions of files. In addition, you should back up all user data files on the file server regularly.
The disaster preparation techniques discussed in the section entitled "Predisaster Preparation Procedures", are your next line of defense. Every system should have periodic Automated System Recovery (ASR) backups as well as a boot disk. This way you can recover a system to a bootable state and fix startup issues without having to rebuild a system from scratch.
Finally, you will also need to perform regular backups of both system and user data. Most backup programs, including Windows Backup, which is included in Windows Server 2003, support several types of backup jobs. The type of backup job determines how much data is backed up and what the backup program does when it performs a backup.
Inside Out: How backup programs use the archive bit
Most backup operations make use of the archive attribute that can be set on files. The archive attribute, a bit included in the directory entry of each file, can be turned on or off. In most cases, a backup program will turn off (clear) the archive attribute when it backs up a file. The archive bit is turned on (set) again when a user or the operating system later modifies a file. When the backup program runs again, it knows that only files with archive attributes that are set need to be backed up—because these are the only files that have changed.
The basic types of backups include the following:
Normal A normal backup is a full backup of all the files and folders you select, regardless of the archive attribute's setting. When a file is backed up, the archive attribute is turned off.
Copy A copy backup is a full backup of all files and folders you select, regardless of the archive attribute's setting. Unlike a normal backup, the archive attribute on files isn't turned off by the backup. This means that you can use a copy backup to create an additional or supplemental backup of a system without interfering with the existing backup strategy.
Incremental An incremental backup is used to create a backup of all files that have changed since the last normal or incremental backup. As such, an incremental backup is a partial backup. The backup program uses the archive attribute to determine which files should be backed up and turns off the archive attribute after backing up a file. This means that each incremental backup contains only the most recent changes.
Differential A differential backup is used to create a backup of all files that have changed since the last normal backup. Like an incremental backup, in a differential backup the backup program uses the archive attribute to determine which files should be backed up. However, the backup program does not change the archive attribute. This means that each differential backup contains all changes.
Daily A daily backup uses the modification date on a file rather than the archive attribute. If a file has been changed on the day the backup is performed, the file will be backed up. This technique doesn't change the archive attributes of files and is useful when you want to perform an extra backup without interfering with the existing backup strategy.
As part of your backup strategy, you'll probably want to perform normal backups on a weekly basis and supplement this with daily, differential, or incremental backups. The advantage of normal backups is that they are a complete record of the files you select. The disadvantage of normal backups is that they take longer to make and use more storage space than other types of backups. Incremental and differential backups, on the other hand, use less space and are faster because they are partial backups. The disadvantage is that recovery of systems and files using incremental and differential backups is slower than when you only have to perform a normal backup. To see why, consider the following backup and recovery examples:
Normal backup with daily incremental backups You perform a normal backup every Sunday and incremental backups Monday through Saturday. Monday's incremental backup contains changes since Sunday. Tuesday's incremental backup contains changes since Monday, and so on. If a server malfunctions on Thursday and you need to restore the server from backup, you would do this by restoring the normal backup from Sunday, the incremental backup from Monday, the incremental backup from Tuesday, and the incremental backup from Wednesday—in that order.
Normal backup with daily differential backups You perform a normal backup every Sunday and differential backups Monday through Saturday. Monday's differential backup contains changes since Sunday as does Tuesday's differential backup, Wednesday's differential backup, and so on. If a server malfunctions on Thursday and you need to restore the server from backup, you would do this by restoring the normal backup from Sunday and then the differential backup from Wednesday.
As part of your backup strategy, you might also want to use copy backups to create extended backup sets for monthly and quarterly use. You may also want to use a media rotation scheme to ensure that you always have a current copy of your data as well as several previous data sets. The point of a media rotation scheme is to reuse tapes in a consistent and organized manner. If you use a media rotation scheme, monthly and quarterly media sets can simply be media sets that you are rotating to offsite storage. Consider the following media rotation scenarios:
Media rotation with three weekly media sets and one monthly media set In a 24/7 environment, you use a total of 14 tapes as a media set. Seven of those tapes contain your normal weekly backups for a set of servers. The other seven tapes contain your daily incremental backups for that set of servers—one tape for each day of the week. Three weekly media sets are maintained on site. Once a month, you rotate the previous week's media set to offsite storage.
Media rotation with three weekly media sets, one monthly media set, and one quarterly media set In a 9 to 5 environment, you use a total of 14 tapes as a media set. Nine of those tapes contain your normal weekly backups for a set of servers. The other five tapes contain your daily incremental backups for that set of servers—one tape for each workday. Three weekly media sets are maintained on site. Once a month, you rotate the previous week's media set to offsite storage. Once a quarter, you rotate the previous week's media set to offsite storage.