Developing a Backup Strategy

Developing the backup strategy involves planning the logistics of backing up the necessary information or data either via backup software and media or documentation, but usually as a combination of both. Other aspects of a backup strategy include assigning specific tasks to individual IT staff members so that the best person is in charge of backing up a particular service or server and ensuring that documentation is accurate and current.

Creating a Master Account List

Creating a master account list is a controversial subject because it contradicts what some security organizations call a best practice; however, many organizations follow this procedure. A master account list contains all the usernames and passwords with root privileges or top-level administrator privileges for network devices, servers, printers, and workstations. Not to be morbid, but a server restore may be required because of a disaster in a site that removed the server and the server administrator from accessibility. Without knowing the organizational-level password, site-level password, or server-level password on a system, an organization might be prevented from recovering server information.

The master account list can be printed and stored in a sealed envelope in a safe at the office or in an electronically encrypted copy. This list should be used only when the assigned IT staff members are not available, recovering from a failure is necessary, and only one of the accounts on the list has the necessary access. After the list is used, depending on who needed the temporary access, all the passwords on the list should be changed for security purposes, and another sealed list should be created.

Assigning Tasks and Designating Team Members

Each particular server or network device in the enterprise has specific requirements for backing up and documenting the device and the service it provides. To make sure that a critical system is being backed up properly, IT staff should designate a single individual to monitor that device and ensure the backup is completed and documentation is accurate and current. Assigning a secondary staff member who has the same set of skills to act as a backup if the primary staff member is unavailable is a wise decision, to ensure that there is no point of failure among IT staff.

Assigning only primary and secondary resources to specific devices or services helps improve the overall security and reliability of the device. By limiting who can back up and restore data ”and even who can manage the device ”to just the primary and secondary qualified staff members, the organization can rest assured that only competent individuals are working on systems they are trained to manage. Even though the backup and restore responsibilities lie with the primary and secondary resources, the backup and recovery plans should still be documented and available to the remaining IT staff.

Creating Regular Backup Procedures

Creating a regular backup procedure helps ensure that the entire enterprise is backed up consistently and properly. When a regular procedure is created, the assigned staff members soon become accustomed to the procedure. If there is no documented procedure, certain items might be overlooked and not be backed up, which can be a major problem if a failure occurs. For example, a regular backup procedure for an Exchange 2003 server could back up the Exchange databases on the local drives every night, and perform an Automated System Recovery (ASR) backup once a month and whenever a hardware change is made to a server.

Creating a Service-Level Agreement for Each Critical Service

A service-level agreement (SLA) defines the availability and performance of a particular device or service. This is usually linked to a failure. For example, a generic SLA could state that for the Exchange server EX01, if a failure occurs, it can be recovered and available on the network in four hours or less. SLAs are commonly defined specifically within disaster recovery solutions; sometimes the SLA is the basis for the disaster recovery solution. For example, if a company cannot be without its database for more than one hour , a disaster recovery solution must be created to meet that SLA.

Before an SLA can be defined, the IT staff member responsible for a device must understand what is necessary to recover that device from any type of failure. That person also must limit the SLA to only the failure types planned for in the approved disaster recovery solution. For example, suppose there is no plan for a site outage . The SLA might state that, if the device fails, it can be recovered using spare hardware and be back online in two hours or less. On the other hand, if a site failure occurs, there is no estimated recovery time because offsite backup media might need to be collected from an outside storage provider and hardware might need to be purchased or reallocated to re-create the device. The more specific the SLA is, the better chance of covering every angle.

Determining a Reasonable SLA

An SLA cannot be created until an IT staff member performs test backups and restores to verify that disaster recovery procedures are correct and that the data can be restored in the desired time frame. When an SLA is defined before the disaster recovery solution, the IT staff member needs to see whether a standard recovery procedure will meet the SLA; otherwise , a creative, sometimes expensive, custom solution might be necessary.

Selecting Devices to Back Up

Each device could have specific backup requirements. The assigned IT staff members are responsible for researching and learning the backup and recovery requirements to ensure that the backup will have everything that is necessary to recover from a device failure. As a rule of thumb for network devices, the device configuration should be backed up; on servers, local and shared storage data, operating system files, and operating system configurations should be backed up. Some backups consist of documentation and a few settings in a text file.

Creating a Windows Server 2003 Boot Floppy

In previous versions of Windows, if RAID 1 volumes were created using the operating system, instead of a hardware-based RAID volume, the administrator needed to create a specific boot disk. This disk pointed to the remaining disk to boot the server if the primary disk in the volume failed. Windows Server 2003 removes this dependency because it adds an additional line in the boot.ini file that points to the second disk's volume, enabling the server to boot properly using the remaining disk. The only caveat is that the administrator needs to select the correct option when the boot.ini file displays the boot options on the screen. The mirrored volume is referred to as a secondary subsystem secondary plex in the following boot.ini file information:

 [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="C: Microsoft Windows Server _  2003 Enterprise Server" /fastdetect multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Boot Mirror C: - secondary plex" 

The preceding example is taken directly from a boot.ini file on a Windows Server 2003 system using software-level RAID 1 arrays for the system partition. The secondary subsystem is just a reference, but the disk controller and disk volume information point the boot loader to connect to the correct remaining partition.

Sometimes a boot floppy is necessary, especially if the boot and system volumes are different and the boot files are inaccessible. In a situation like this, a boot floppy is priceless. To create a boot floppy, format a floppy disk. From the local server console, copy the boot.ini , NTLDR , and NTDETECT files to the floppy disk. When the BIOS cannot locate the boot loader files, this floppy can be used to boot the system and point the system to the correct volume containing the operating system files.