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 it is a combination of both. Other aspects of a backup strategy include assigning specific tasks to individual IT staff members to make sure the best person is making sure that a particular service or server is being backed up regularly and 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. This list either should be kept printed in a sealed envelope in a safe at the office or electronically encrypted. 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 to 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 out sick or unavailable is a wise decision to ensure that there is no single point of failure among IT staff.

Assigning only primary and secondary resources to specific devices or services can help improve the overall security and reliability of the device. By limiting who can back up and restore data, and possibly 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 will soon become accustomed to the procedure, and it will become second nature. If there is no documented procedure, certain items may be overlooked and may not be backed up, which can turn out to be a major problem if a failure occurs. For example, a regular backup procedure for a Windows Server 2003 system could back up the user data on the local drives every night, and perform an Automated System Recovery backup once a month and whenever a hardware change is made to a server.

Creating a Service-Level Agreement for Each Critical Service

An 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 file server FP01, 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, or 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. Also, that person must limit the SLA to only the failure types planned for in the approved disaster recovery solution. For example, say a site outage is not planned for. The SLA may 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 may need to be collected from an outside storage provider and hardware may need to be purchased or reallocated to re-create the device. The more specific the SLA is, the better the 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 or a creative, sometimes expensive, custom solution may be necessary.

Determining Which Devices Need to Be Backed Up

Each device may 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, and servers, local and shared storage data, operating system files, and operating system configurations should be backed up. Some backups may simply 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 as opposed to a hardware-based RAID volume, the administrator needed to create a specific boot disk to point 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, allowing 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 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: Windows Server 2003, Enterprise" /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 from a Windows Server 2003 system using software-level RAID 1 for the system partition. The secondary plex 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, simply format a floppy disk, and then 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.