Windows Windows

Document Sample
Windows Windows Powered By Docstoc
					                                                     ITPro       ™
                                                                  SERIES




    A Guide to
    Windows

    Disaster
    Recovery
    and
        Backup
           by Bob Chronister, Jerry Cochran, Kalen Delaney, Paul Robichaux,
                  Ed Roth, John Savill, Bill Stewart, and Alan Sugano

Sponsored by
                                                                                                                                                                                                                                i




Contents
Chapter 1: 10 Steps to Building a Sound Disaster Recovery Plan . . . . . . .                                                                                                                                               1
      By Alan Sugano
  1. Review Your Backup Strategy . . . . . . . .                                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    1
  2. Make Lots of Lists . . . . . . . . . . . . . . . .                                .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    2
  3. Diagram Your Network . . . . . . . . . . . .                                      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    2
  4. Go Wireless . . . . . . . . . . . . . . . . . . . .                               .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
  Sidebar: Planning for a Hack Attack . . . . .                                        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    5
  5. Assign a Disaster Recovery Administrator                                          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    6
  6. Assemble Teams . . . . . . . . . . . . . . . . .                                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    6
  7. Create a Disaster Recovery Web Site . . .                                         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
  Sidebar: Surviving the Worst . . . . . . . . . . .                                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
  8. Test Your Recovery Plan . . . . . . . . . . .                                     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8
  9. Develop a Hacking Recovery Plan . . . .                                           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
  10. Make the DRP a Living Document . . . .                                           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11

Chapter 2: Back Up Key XP and Win2K Clients . . . . . . . . . . . . . . . . . . . . 12
      By Ed Roth
  Configuring Backup Jobs . . . . . . . . . .                                  ...         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   12
  Scheduling Backup Tasks . . . . . . . . . .                                  ...         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   14
  Creating User Shortcuts to Back Up Jobs                                       ..         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   14
  File Restoration and System Recovery .                                       ...         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   15
  A Well-Suited Solution . . . . . . . . . . . .                               ...         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   16

Chapter 3: Fine-Tune Your Backup Strategy . . . . . . . . . . . . . . . . . . . . . . . 17
      By Jerry Cochran
  Better Technology . .       ..   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   17
  Improving the Facility       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   18
  Reducing the Data Set        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   18
  Make Your Life Easier        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   19
ii    A Guide to Windows Certification and Public Keys



Chapter 4: Disaster Prevention: Preparing for the Worst . . . . . . . . . . . . . . 20
         By Kalen Delaney
     Strategies for Disaster Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   20

Chapter 5: Backup and Recovery Tips & Tricks . . . . . . . . . . . . . . . . . . . . . 24
     Setting Up a Disaster-Recovery Location . . . . .            ..............................                          24
     —Bob Chronister
     Setting NTBackup to Not Use VSS . . . . . . . . .            ..............................                          25
     —Bob Chronister
     Backing Up and Restoring User Profiles . . . . .             ..............................                          25
     —John Savill
     Running NTBackup from the Command Line . .                   ..............................                          27
     —Bill Stewart
     A Weekend of Downtime . . . . . . . . . . . . . . .          ..............................                          28
     —Paul Robichaux
     Welcome to the Danger Zone . . . . . . . . . . . .           ..............................                          29
     —Paul Robichaux
     Dealing with a System Restore–Related Problem                ..............................                          30
     —Bob Chronister
     Backing Up the System State . . . . . . . . . . . . .        ..............................                          31
     —John Savill
     Speed Up an Authoritative Restore . . . . . . . . .          ..............................                          32
     —Brian Taché
     Solving a Restore Problem . . . . . . . . . . . . . . .      ..............................                          32
     —Bob Chronister
     Performing an Authoritative Restoration of AD .              ..............................                          33
     —John Savill
     Command-Line Syntax for a Backup . . . . . . . .             ..............................                          34
     —John Savill
     Is True Recovery Always Possible? . . . . . . . . .          ..............................                          35
     —Kalen Delaney
                                                                                                                            1


Chapter 1:

10 Steps to Building a Sound Disaster
Recovery Plan
—By Alan Sugano

You need only take a quick look at the news on any given day to remind you of why your company
needs a disaster recovery plan. Chances are, you won’t ever experience a Level Four disaster, such as
a terrorist bombing or natural disaster like a hurricane or flood. But even the smaller-scale Level One,
Two, or Three disasters that you’ll more likely encounter, such as power outages and server malfunc-
tions, can paralyze business operations unless you’ve developed a plan for rapidly restoring IT ser-
vices. Table 1 lists and describes the four disaster levels. You probably already have a disaster
recovery plan, but it’s wise to review it periodically and update it to accommodate changes in your
business. Drawing on my experience in developing disaster recovery plans for clients, I’ve compiled a
list of the 10 steps an organization of any size should follow when creating a new disaster recovery
plan or revising an existing plan.

Table 1: Disaster Levels
Level      Downtime            Typical Causes                    Business Location          Number of         Business Impact
                                                                 Available?                 People Affected
One        4 hours or less    Single workstation failure         Yes                        Three or fewer    Low
Two        24 hours or less   Server failure,                    Yes                        Four or more      Low
                              WAN disruption
Three      72 hours or less   Water leak,                        No                         10 or more        Moderate
                              extended power failure
Four       More than 72 hours Earthquake, flood,                 No                         10 or more        High
                              terrorist attack, war



1. Review Your Backup Strategy
I generally recommend that clients perform full daily backups of all essential servers and data
resources. Stay away from incremental and differential backups. In an emergency, you don’t want to
have to search for not only the last good full backup but also the five incremental backups necessary
to complete the restore.
    If you’re running Microsoft Exchange Server or Microsoft SQL Server, consider making hourly
backups of transaction logs so that you’ll be able to restore your system to within 1 hour of when it
crashed. One-step restore backup solutions are useful, but make sure you know how to manually
recover the server should you have to restore your data on a different server platform. Store at least
one tape off site weekly and store on-site tapes in a data-approved fireproof safe. Always ensure that



                                     Brought to you by Symantec and Windows IT Pro eBooks
2   A Guide to Windows Disaster Recovery and Backup


you have on hand a new tape drive that can read your existing tapes. You don’t want to discover
that you no longer have a tape drive that can read your outdated tape format. Consider leveraging
built-in features of Windows Server 2003 and Windows 2000 Server—such as Microsoft Remote
Installation Services (RIS), offline folders, Microsoft Volume Shadow Copy Service (VSS), and
Windows Server Update Services (WSUS)—to aid in the recovery process and help get your network
up and running again.

2. Make Lots of Lists
Your disaster recovery plan can’t have too much documentation. To recover gracefully from a
disaster, you need to adequately document equipment, network layouts, applications, and technical
and business procedures that you’ll need to reconstruct your business. Here are some items you
should document and make available and accessible to those who need this information (employees,
consultants, service providers):
      Business locations. Document the business address, phone number, fax number, and building
management contact information. I suggest including a map to the business’s location(s) that includes
surrounding geographic areas.
      Equipment list. Compile an inventory listing of all the network components at each business
location. Include the model, manufacturer, description, serial number, and cost for each network
component. Many software products are available that can help you create and maintain such an
inventory. Often this type of list is necessary for insurance purposes, so it might already exist at your
company (e.g., in the financial department). Should a disaster affect your company, this list will be
useful for determining what IT will need to order to replace damaged equipment.
      Application list. Make a list of business-critical applications running at each location. If neces-
sary, include in this list specific recovery instructions for ERP applications. For major applications,
include technical support contact information, account numbers, and—for applications that have a
maintenance agreement—service contract information.
      Essential vendor list. Compile a list of essential vendors—that is, those necessary for your
business operations. Consider establishing lines of credit with these vendors in case bank funds aren’t
readily available after a disaster occurs.
      Critical customer list. Compile a list of customers for whom your company provides business-
critical services. Designate someone in your company to notify these customers of your business
status after a disaster has occurred and provide estimates of when your firm will become fully
operational.

3. Diagram Your Network
Use a software package such as Microsoft Office Visio 2003 to draw detailed diagrams for all
networks in your organization, including both LANs and WANs.
    LAN diagram. Construct a detailed diagram of the network layout for each business location,
such as the sample diagram that Figure 1 shows. Make sure the diagram corresponds to the physical
layout of the office (as opposed to a logical diagram of the network) to make it easier for someone
who’s unfamiliar with the office layout to find items. This diagram should show all network compo-
nents and briefly describe each component and the OS version.




                                  Brought to you by Symantec and Windows IT Pro eBooks
                                         Chapter 1 10 Steps to Building a Sound Disaster Recovery Plan 3



                                                    Figure 1
                                           Sample LAN diagram




     WAN diagram. If your company has a WAN, this diagram should include all WAN locations,
similar to the WAN diagram in Figure 2. If you’re on a VPN, the diagram should include the IP
address, model, serial number, and firmware revision of the firewalls; WAN default gateway; VPN
policies; and local IP subnet. Also document the firewall configuration(s) in both electronic and hard-
copy form. If your company uses frame relay, be sure to document all the router configurations elec-
tronically and in hard copy. Make sure you’ve recorded all the Data Link Connection Identifier (DLCI)
and circuit number information. On the diagram, also include information about the WAN carrier,
including the carrier’s name, technical support phone number, account number, and circuit ID.




                                 Brought to you by Symantec and Windows IT Pro eBooks
4   A Guide to Windows Disaster Recovery and Backup



                                                    Figure 2
                                          Sample WAN diagram




4. Go Wireless
If a disaster makes it impossible for your business to operate in its regular location, consider using
wireless equipment to restore the network quickly. Be sure to purchase equipment that supports the
Wi-Fi Protected Access (WPA2) security standard because you probably won’t have the infrastructure
in place to perform full-blown Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)
authentication.




                                 Brought to you by Symantec and Windows IT Pro eBooks
                                        Chapter 1 10 Steps to Building a Sound Disaster Recovery Plan 5



                          Planning for a Hack Attack
     It’s unlikely that your company will be hit by a Level Three or Level Four disaster during the
next year, but what about a hack attack? The threat of hackers breaching your company’s network
and computer systems is a real and present danger, and an attack could cause serious problems for
your IT infrastructure and, as a result, interfere with business operations. Therefore, a hacking
recovery plan should be part of any comprehensive disaster recovery plan. Here are some steps that
should be included in your hacking recovery plan.
     1. Disconnect external lines. If you suspect that a hacker has compromised your network,
disconnect any external WAN lines coming into the network. If the attack came from the Internet,
taking down external lines will make it harder for the hacker to further compromise any machines
and with luck prevent the hacker from compromising remote systems.
     2. Perform a wireless sweep. Wireless networking makes it relatively simple for a hacker to set
up a rogue Access Point (AP) and perform hacks from the parking lot. You can use a wireless sniffer
such as Airscanner Mobile Sniffer, AirSnort, Airosniff, ApSniff, or NetStumbler to perform a wireless
sweep and locate APs in your immediate area. Install the sniffer on a laptop or another mobile
device before you need to use it to make sure it’s working properly. You should install the sniffer on
a NIC that supports all the current wireless standards (e.g., 802.11a, 802.11b, and 802.11g).
     3. Scan for compromised machines. A hack attack could compromise multiple machines. Make
sure you check every machine that could potentially be hacked for compromises. For example, use
the Autoruns utility from Sysinternals (http://www.sysinternals.com/ntw2k/freeware/autoruns.shtml) to
check for unknown programs that are set up to automatically run. Also check whether root kits and
other hacking tools are installed on the computer.
     4. Disable or delete rogue users. Examine Active Directory (AD) for rogue (i.e., unauthorized)
users, and disable or delete such users as necessary.
     5. Change passwords. Change all passwords for every account on the network. This especially
includes the Administrator account and accounts that are used to start services on the server.
Consider using 15-character pass phrases for enhanced security.
     6. Preserve the data. If possible, buy replacement hard drives for the hacked computers, so that
you can preserve the hacking activity on the compromised computer. After you’ve restored the
network, you can review this information to gain more valuable information about the hack.
     7. Identify and address the vulnerability. This is often easier said than done. Make sure you
know how the hacker accessed the network in the first place. If you don’t address the vulnerability,
you face being attacked again.
     8. Rebuild the machine. After a machine has been hacked, it’s almost impossible to completely
clean it of all hacking tools; all a hacker needs is one to gain access to the machine. The only way
to make sure the machine is clean is to format the hard drives and rebuild the computer from
scratch. If you have to restore data on the computer, make sure you don’t accidentally restore any
previously installed hacking tools. Don’t restore the registry, any OS files, or programs from tape.
Install all applications manually; don’t restore them from tape.
     9. Bring the network back up. Reconnect the WAN lines and carefully monitor them. Make sure
you’ve closed all holes on your network, to prevent the hacker from returning.


                                Brought to you by Symantec and Windows IT Pro eBooks
6   A Guide to Windows Disaster Recovery and Backup



      10. Perform forensic analysis on the hard drives. After the network is running again, you might
 want to install the hacked drives on a standalone computer to gain more information about the hack.
 Although hackers often spoof their IP addresses, for tracking down the source of the hack, the IP
 address is a good place to start. You can get a list of IP address allocations from the Internet Assigned
 Numbers Authority (IANA) at http://www.iana.org. Document each hacking tool that you find on a
 computer. It’s very difficult to track down hackers, especially if they’ve covered their tracks. Often
 you must catch a hacker while the hack is occurring. You might want to leave tracking the hacker to
 the appropriate authorities.
      11. Notify law enforcement. Most FBI field offices have Cyber Action Teams and run the
 Internet Fraud Complaint Center (http://www.ifccfbi.gov/index.asp) for reporting suspicious activity on
 the Internet. To contact your local FBI office, refer to the list at http://www.fbi.gov/contact/fo/fo.htm.
 No one likes to admit he or she has been hacked, but notifying the appropriate authorities is the first
 step to prevent a hacker from doing more damage. The more information you can provide about the
 attack, the more likely the FBI can capture the hacker.

      During a hack attack, it’s difficult to think clearly. Having a game plan for dealing with hack
 attacks will help you to bring up your network quickly and preserve the hacked computer for future
 analysis.


5. Assign a Disaster Recovery Administrator
I suggest you assign a primary and secondary disaster recovery administrator for each business
location. Each disaster recovery administrator should have the other’s contact information. Ideally the
disaster recovery administrators should live close to the office location so they can easily reach the
office in the event of a major disaster. The administrators are responsible for declaring the disaster,
defining the disaster level, assessing and documenting damage, and coordinating the recovery effort.
The administrators should have a good overall understanding of business operations, know how to
prioritize office services, and be familiar with all operational aspects of the business location.

6. Assemble Teams
When a major disaster strikes, expect confusion, panic, miscommunication, disruption in services, and
other uncontrollable forces that will counter your efforts to get your company up and running. You
can minimize many of these challenges through sound disaster planning and communicating the plan
to employees before disaster strikes. Verify that everyone involved with disaster recovery is aware of
your business’s disaster plan and knows their role in disaster recovery. The disaster recovery adminis-
trator should divide up business-recovery tasks that will need to be performed and assign employees
to teams that will carry out those tasks. Here are some suggested teams; you should develop your
own list of disaster recovery teams that cover areas of responsibility specific to your business.
     Damage assessment/notification team—collects information about the initial status of the
damaged area and communicates this information to appropriate members of staff and management.
This team compiles information from all areas of the business, including accounting, business
operations, IT, vendors, and customers. Following the assessment, the team oversees any salvage


                                  Brought to you by Symantec and Windows IT Pro eBooks
                                         Chapter 1 10 Steps to Building a Sound Disaster Recovery Plan 7


operations, such as salvaging equipment, office supplies, and backed-up tapes. Team members
should be authorized to purchase replacements for equipment and supplies damaged during the
disaster. This team will become the replacement team after the salvage operations are finished.
     Office space/logistics team—assists disaster recovery administrator in locating temporary office
space in the event of a Level Four disaster. Team members are responsible for transporting
co-workers and equipment to the temporary site and are authorized to contract with moving
companies and laborers as necessary to relocate to the temporary site.
     Employee team—oversees employee issues, such as staff scheduling, payroll functions, and staff
relocation.
     Technology team—orders replacement equipment and restores computer systems; reestablishes
telephone service and Internet and VPN connections.
     Public relations team—communicates with the public about estimated reopening time and
rescheduling of private-party appointments.
     Safety and security team—ensures the safety of all employees during the entire disaster
recovery process. This team decides who will and won’t have access to the affected location and is
responsible for notifying employees of any safety hazards that exist in the building and ensuring that
the site is secure to prevent looting.
     Office supplies team—orders new furniture, office supplies, and forms that are necessary to
resume normal business operations.

7. Create a Disaster Recovery Web Site
Consider developing a Web site where employees, vendors, and customers can obtain up-to-date
information about the company after a disaster. This Web site should be a mirrored site that’s
cohosted at two geographically separate business locations. On the Web site, the disaster recovery
team will post damage assessments for business locations, each location’s operational status, and
when and where employees should report for work. The Web site should also include an interface
where the disaster recovery administrator can post timestamped messages about the recovery effort.
You might choose to make some of this information publicly accessible, but a majority of these pages
should require a logon and should be protected with a Secure Sockets Layer (SSL) certificate. This site
should also contain the latest copy of the disaster recovery plan in PDF format.

8. Test Your Recovery Plan
Most IT pros face Level One and Two disasters regularly and can quickly respond to such events.
Level Three and Four disasters include “acts of God” and other factors that are out of your control.
To respond to these more serious disasters, your disaster recovery plan should carefully organize and
assign whatever resources you do have control over in such situations. Once you’ve devised a dis-
aster recovery plan, you should test it regularly and revise it as necessary. When you test the plan,
create different scenarios that simulate Level One through Level Four Disasters. You might find it
helpful to discuss your plan with other IT pros to learn what worked and didn’t work in their disaster
recovery plans.




                                 Brought to you by Symantec and Windows IT Pro eBooks
8   A Guide to Windows Disaster Recovery and Backup




                                 Surviving the Worst
It’s 2:00 A.M. on a Monday morning, and your cell phone rings. The water fountain on the floor
directly over your server room has malfunctioned, and your organization’s servers and routers are
standing in water, as are most of your employees’ workstations. The office opens at 8:00 A.M. What
do you do in the meantime?
      Situations like this one separate IT departments that have planned for disaster from those that
haven’t. For the latter group, the situation I’ve described is more than a disaster—it’s an absolute
disaster. When total data loss is possible, the absence of a disaster recovery program can put a
business at risk, particularly small-to-midsized businesses (SMBs), which often don’t have the
financial wherewithal to survive unexpected catastrophic events. Although disasters are inevitable
and, to a degree, unavoidable, being prepared for them is completely within your control.
Increasingly, IT has become the focal point of many companies’ disaster planning. Creating a
program to preserve business continuity and recover from disaster is one of the central value
propositions that an IT department can contribute to an organization.

A 6-Step Plan
In the terminology of disaster planning, two phrases are common: Business Continuity Planning
(BCP) and Disaster Recovery Planning (DRP). Although many people use these phrases
interchangeably, they represent different concepts. BCP traditionally defines planning that ensures an
organization can continue operating when faced with adverse events. DRP is actually a subset of
BCP and traditionally focuses on recovering information and systems in the event of a disaster. As an
example, the failure of a hard disk in a database server is an event that potentially affects business
continuity but doesn’t result from a disaster. However, a water-pipe break that floods a server room
and submerges the database server is a threat to business continuity and within the scope of disaster
recovery planning.
     BCP and DRP can be complex; in fact, large organizations dedicate groups of people to them.
But without getting into detailed risk analyses and other complexities that usually accompany BCP
and DRP in large companies, all organizations can benefit by following six steps to create a program
that will preserve business continuity and facilitate recovery in the event of disaster.

Step 1: Identify Critical Business Activities
The first step in BCP and DRP is to identify your organization’s critical business activities—those
things that must occur on a daily basis in order for your business to stay in business. For example, a
customer service call center must be able to receive calls, look up customer records, and create new
incident records for customers calling in. A law firm will need to be able to access client information
and electronic schedules, send and receive email, research online law libraries, and make and
receive telephone calls. As you work through this step, you’ll need to partner with your
organization’s key business decision makers to identify the activities that are essential to your
organization’s continued functioning. Your organization’s BCP will center on preserving continuity of
operations by recovering these services.


                                Brought to you by Symantec and Windows IT Pro eBooks
                                         Chapter 1 10 Steps to Building a Sound Disaster Recovery Plan 9




Step 2: Map IT Systems to Critical Business Activities
With the identification of your organization’s key business activities, you can determine which IT
systems these activities depend on. For example, to enable the customer service call center to look
up customer records and create new records for incoming calls, the database servers that store the
records and the line-of-business applications that access them must be available. In turn, some
degree of core network infrastructure will also need to be operable for this critical business activity to
take place. These are the IT systems that you must be able to keep operating by quickly recovering
them after a disaster.

Step 3: Model Threats Posed by Predictable and Plausible Events
Nearly all disasters and failures in business continuity are predictable to a certain degree of precision
and plausible within a certain degree of reason. Such events can be natural, such as an earthquake
or flooding; human-caused, such as an accidental fire or deliberate sabotage; or mechanical, such as
a hard disk failure or a water pipe bursting. For example, if a customer service call center is located
in Wakita, Oklahoma, it is plausible that the center’s IT systems could be in the direct path of a
tornado. Likewise, for any company that relies on technology, it is predictable that computer
hardware will eventually fail.
     After you identify your critical IT systems, you can begin modeling the threats posed to these
systems by predictable and plausible events. Threat modeling lets you apply a structured approach to
identifying threats with the greatest potential impact to your business continuity and their mitigation.
List all the ways that critical IT systems might be disrupted and which events must happen for each
threat to be realized. For example, something that would disrupt the call center’s business continuity
might be the customer record database’s inaccessibility. Events that could cause such inaccessibility
include computer hardware failure, a power failure, or something more severe, such as destruction
of the data center by a tornado.

Step 4: Develop Plans and Procedures for Preserving Business Continuity
Now that you’ve listed your critical business activities, identified the IT systems your business
depends on for carrying out those activities, and brainstormed the possible and plausible events that
could disrupt IT services, you can use your threat model to determine countermeasures to preserve
business continuity. Four primary BCP countermeasures exist: fault tolerance and failover, backup,
cold spares and sites, and hot spares and sites.
     Fault tolerance and failover. This countermeasure relies on the use of redundant hardware to
enable a system to operate when individual components fail. In IT, the most common fault tolerance
and failover solutions for preserving IT operations are hard disk arrays, clustering technologies, and
battery or generator power supplies.
     Backup. On- and offsite backup programs are a core countermeasure in DRP. Backup gives you
the ability to restore or rebuild recent data to a known good state in the event of data loss.
     Cold spares and sites. Cold spares are offline pieces of equipment that you can easily prepare to
take over operations. For example, you might maintain a set of servers that aren’t connected to your


                                 Brought to you by Symantec and Windows IT Pro eBooks
10   A Guide to Windows Disaster Recovery and Backup



network and that have your company’s standard OS installed and configured. In the event of an
emergency, you can complete the configuration and restore or copy necessary data to resume
operation. Similarly, a cold site is a separate facility that you can use to resume operation if a disaster
befalls your primary facility. Often, a cold site is nothing more than a large room that can
accommodate desks and chairs. For most SMBs, cold sites aren’t cost-effective.
     Hot spares and sites. Hot spares are pieces of equipment that are ready for immediate use after
a disaster. For example, you might continuously replicate a critical database’s data to remote facilities
so that client applications can be redirected to the data replicas if necessary. Hot sites are facilities
that let you resume operations in a very short amount of time—typically, a hot site is operational
within the time it takes for employees to arrive at the facility. Hot sites have real-time or near real-
time replicas of data and are always operational. Because hot spares and sites are expensive to
maintain, only organizations that must be operational in a disaster, such as a public safety
organization, use them.

Step 5: Develop Plans and Procedures for Recovering from Disaster
Not all events are predictable or plausible. There is perhaps no better example of this kind of event
than the September 11, 2001, attack on the World Trade Center. For these types of disastrous circum-
stances, as well as for other severe disasters in which total data or service loss from primary systems
is possible, you must create plans and procedures for recovering systems. Because recovering from a
disaster is stressful, having well-documented, tested, and practiced procedures in place beforehand is
essential. Similarly, rehearsing recovery procedures can help you verify that the data on backup
media is usable and restorable. Be sure to store copies of your DRP procedures offsite with your veri-
fied backups. For most organizations, bank safe deposit boxes are the most effective, affordable, and
secure remote storage solution for verified backups and DRP plans.

Step 6: Test Business Continuity Plans and Practice Disaster Recovery
Test, test, test. When it comes to BCP and DRP, the very nature of the circumstances that necessitate
their existence dictates that the plans, procedures, and technologies you use to preserve business
continuity must work when they are required. Conduct planned and spontaneous drills to test your
BCP and DRP. These drills might include failing over cluster nodes on a monthly basis, restoring cold
spare servers periodically, or even conducting full cold- or hot-site disaster simulations. At an abso-
lute minimum, perform DRP restoration of critical data from offsite backup media periodically. Off-
site backup media is your last line of defense against total data loss.

6 Steps Away from Disaster
By following these steps, you can help your organization create a BCP and DRP program that will
shield it from the risk of natural, human-caused, and mechanical disasters. When the cell phone
rings at two in the morning, the last thing you want to be doing is brainstorming ways to recover
data from a server and backup tapes that have been under water for 30 hours or, even worse,
recovering from the physical destruction of your data center after disastrous circumstances.



                                  Brought to you by Symantec and Windows IT Pro eBooks
                                       Chapter 1 10 Steps to Building a Sound Disaster Recovery Plan 11



9. Develop a Hacking Recovery Plan
Hack attacks fall within the scope of a disaster recovery plan. For a discussion about some special
considerations for addressing hack attacks in your disaster recovery plan, see the sidebar “Planning
for a Hack Attack.”

10. Make the DRP a Living Document
Review the disaster recovery plan at least once a year. If your company or network changes fre-
quently, you should probably review the plan semiannually or even quarterly. Remember, an out-of-
date disaster recovery plan is almost as useless as no disaster recovery plan at all.




                                 Brought to you by Symantec and Windows IT Pro eBooks
12    A Guide to Windows Disaster Recovery and Backup



Chapter 2:

Back Up Key XP and Win2K Clients
—By Ed Roth

Many organizations don’t have a strategy for backing up their desktop computers. If your users store
data files on a network volume that you back up as part of your file-server backup strategy, you
might decide that you don’t need to back up your workstations. When a user’s desktop system
crashes or dies, you can install the OS and applications from scratch or from a system image and
reestablish the connection to the unharmed data on the network. For most users, this approach
provides a sensible balance between manageability and data security.
     However, some desktop systems might merit special attention because of a user’s position in the
company or the nature of his or her job. For these special cases, you can choose from a variety of
backup solutions, including system imaging, local backups, and third-party remote backup agents.
     Win2K’s Backup 5.0 introduced the ability to back up to a file without a local tape drive. This
functionality offers the advantages of using a real backup application—including scheduling daily,
incremental, and differential backups—without the management overhead or expense of distributed
tape backup devices. You can later use your server backup mechanism to back up this file to
removable media and benefit from the media rotation and offsite storage strategy you’ve implemented
for your server backups. This type of client backup routine can range from very simple to relatively
easy, depending on the level of user involvement you desire and your environment’s data-protection
requirements.
     At the simplest end of the spectrum, you can train appropriate users to run Backup and perform
complete backups to a network volume; on the opposite end of the spectrum, you can completely
script and schedule backup operations so that user intervention isn’t required. Let’s consider a
combined solution in which backups run on an automated schedule and users can conduct a manual
backup when they feel that one is warranted. To implement this solution, you must have XP or
Win2K clients and a mapped network volume that has adequate storage capacity. You must also
have administrative authority on the client systems.

Configuring Backup Jobs
To run Backup, click Start, Programs, Accessories, System Tools, Backup. If you use XP, switch to Advanced
Mode by clearing the Always start in wizard mode check box, then click the underlined Advanced Mode link.
Click the Backup tab and select the System State check box and the check boxes for any drives and folders
that you want to back up. System State objects include boot files, the COM+ class registration database, and
the registry, all of which are necessary to recover a system. To avoid unnecessary network traffic and space
consumption, select only local drives when choosing items to back up. Save the backup selections in a file to
use to create additional backup jobs and manually executable shortcuts. From the Job menu, select Save
Selections As and save the file in a directory that all the system users can access (e.g., Documents and
Settings, All Users).


                                   Brought to you by Symantec and Windows IT Pro eBooks
                                                                 Chapter 2 Back Up Key XP and Win2K Clients 13



     From the Tools menu, select Options, then click the General tab to set options for your environment.
Because you’re not concerned about removable media, you can ignore these settings. Clear the Back up the
contents of mounted drives check box to avoid redundant and wasteful traffic. Click the other tabs and ensure
that Backup is configured to behave appropriately for the task at hand. On the Exclude Files tab, you’ll see the
default list of files that the tool will ignore during the backup procedure. This list is adequate for most systems,
but you can add or remove files from the list as necessary.
     After you configure the options, you must specify the name and location of the backup file.
Browse to and select a destination, as Figure 1 shows, or manually enter a path. Make sure the
location and filename you provide don’t compromise your data-protection needs. For example,
choose a location on a network volume that’s accessible to the user but that has enough security to
thwart unauthorized access. As an added precaution, choose a location that your server backup
strategy encompasses.

                                                        Figure 1
                             Selecting the name and location of a backup file




     User home folders provide an adequate backup file location if you allot adequate space; however, if you
want to be able to restore data remotely, choose a location to which you have adequate access without having
to take ownership of the file. If storage space isn’t abundant on your server, consider placing backup files in a
compressed folder—but don’t ignore the burden that this option will create for the processor on the server that


                                     Brought to you by Symantec and Windows IT Pro eBooks
14    A Guide to Windows Disaster Recovery and Backup



hosts the folder. From the Backup tab, click Start Backup to open the Backup Job Information screen and
provide a descriptive name for the backup job.
     Because replacing a backup file is inherently destructive, I prefer to build in a safeguard. For example,
you can use the Append this backup to the media option to create a backup file without overwriting an earlier
version and then run a simple Delete command after every weekly or monthly backup of your destination
server to tape. To configure additional options, click Advanced. Select the option to automatically back up
system-protected files, and, unless you use Remote Storage on the client system, make sure that option is
cleared. You can disable verification, but you should run at least one backup with the feature enabled to make
sure that your process is working properly. From the Backup Type drop-down box, select the type of backup
you want to perform. After you make your selections, click OK to return to the Backup Job Information dialog
box. You have the option to start the backup or schedule it.

Scheduling Backup Tasks
On the Backup Job Information dialog box, click Schedule and specify an account under which the backup
application will run. Use an account that belongs to the Administrators group or Backup Operators group. Pro-
vide a name for the backup job and click Properties to edit the schedule settings. After you click OK to
approve the schedule, you’ll return to the main Backup interface. Repeat this process to configure and
schedule other backup jobs.
     From the Job menu, select Load Selections to reload your selections. Verify the options and settings,
making sure you select the proper Backup Type and Append/Replace parameters and that you specify the
correct destination file.
     Next, click Start, Programs, Accessories, System Tools, Scheduled Tasks and verify that operations are
scheduled correctly and that they’ve run. Scheduled jobs run silently in the background, regardless of whether
the user is logged on. The Scheduled Tasks service gives you some latitude for power management and idle
time detection to ensure that backups occur consistently and without interrupting the user.

Creating User Shortcuts to Back Up Jobs
You can create a shortcut to let a user manually launch a predefined backup job. On the Scheduled Tasks
window, which Figure 2 shows, right-click a task and choose Properties to view details about the task, then
copy the command and arguments that appear in the Run field on the Task tab into a shortcut that’s accessible
to the user. Be aware, however, that the number of characters in the command string might exceed the
maximum number of characters that the system permits for a shortcut.




                                   Brought to you by Symantec and Windows IT Pro eBooks
                                                                 Chapter 2 Back Up Key XP and Win2K Clients 15



                                                        Figure 2
                                            Scheduled Tasks window




File Restoration and System Recovery
File restoration is intended to bring back lost or damaged contents, and recovery is intended for a catastrophic
failure that necessitates a system rebuild. In either case, you must locate the appropriate backup file and cat-
alog its contents before you can restore anything. To do so, run Backup, click the Restore tab, click the File
icon, and choose Catalog file. Enter the location of your backup file and click OK to catalog the file. Next,
select the files that you want to restore and specify the options the system should adhere to when it restores the
files. By default, Backup restores files to their original locations, but you can select other options, as Figure 3
shows. The Alternate location option lets you catalog a user’s backup file from your desktop computer and
restore the contents to that user’s system. However, be aware that the path you specify is relative and the
folder structure of what you’re restoring will remain intact. For example, if you restore a file that originally
existed in C:\files\october\reports and you specify that directory on the user’s system as the alternate location,
the utility will restore that file to C:\files\october\reports\files\october\reports.




                                     Brought to you by Symantec and Windows IT Pro eBooks
16    A Guide to Windows Disaster Recovery and Backup



                                                      Figure 3
                                           The Backup Restore tab




     When you use Backup to perform a complete system recovery, you must perform a clean installation of
the OS on the system you want to recover. You can then restore the entire contents of the backup to the
system, overwriting the interim OS installation.

A Well-Suited Solution
The functionality that Task Scheduler provides is well suited for backing up data on XP and Win2K clients.
Backing up to a network volume affords some interesting options for bolstering data security without breaking
your budget or creating an inordinate administrative burden.




                                   Brought to you by Symantec and Windows IT Pro eBooks
                                                                   Chapter 3 Fine-Tune Your Backup Strategy 17



Chapter 3:

Fine-Tune Your Backup Strategy
—By Jerry Cochran

IT administrators are always looking for ways to revamp their backup strategies. Today’s exciting
technologies and capabilities provide an added incentive to take a fresh look at backup procedures.
To identify and take advantage of these advancements, consider these recommendations for making
the most of these technologies and for devising a sound Windows backup strategy.

Better Technology
During the past few years, two key developments have changed the landscape for performing
backups of Windows and Windows applications such as Microsoft Exchange Server and Microsoft
SQL Server. The first development is new hardware capabilities. We’ve come a long way from the
8mm helical scan tape devices I used for server backups 10 to 15 years ago. Today’s new technolo-
gies, such as AIT, Linear Tape-Open (LTO), and SuperDLT (SDLT), have capacities and transfer
speeds of a few hundred gigabytes per tape—equal to the performance and capacities of the hard
disks we used 10 years ago. But the advances in high-speed and high-capacity backup facilities
haven’t kept up with our voracious storage appetites. On the hardware side, advances in Network
Attached Storage (NAS) and Storage Area Network (SAN) technologies have provided new storage
options in the form of hardware-based snapshots and clones and data-replication technologies such
as the HP StorageWorks Data Replication Manager (DRM) and EMC’s Symmetrix Remote Data Facility
(SRDF). But without an OS- and application-supporting framework on which to build these technolo-
gies, none of the new hardware advances can handle the Windows backup challenge.
     The second development is new Windows technologies such as Microsoft Virtual Disk Service
(VDS) and Microsoft Volume Shadow Copy Service (VSS), which let Windows and Windows applica-
tions leverage hardware capabilities natively. Both VDS and VSS let third-party vendors support
Windows-based, state-of-the-art backup-and-recovery and storage-management technologies. Now
open and Microsoft-supported solutions are available that both vendors and customers endorse.
     These two developments can help you get a better handle on backups (and ultimately provide
improved recovery as well). Of course, you need Windows Server 2003 and new hardware to take
advantage of most of these advances. But if you can provide the business justification, their benefits
should be worth the technology investment. For additional information about using Windows 2003 to
reduce the complexities and costs of managing your storage infrastructure, see the Microsoft Storage
Web site (http://www.microsoft.com/windows/storage).
     Many organizations use business drivers to determine which disaster-recovery service level agree-
ments (SLAs) to adopt. The SLAs then determine how extensive the backup strategy needs to be. But
even if your SLAs and backup strategy are firmly in place, you might discover that improvements in
technology provide good reasons to overhaul or at least fine-tune your strategy. Administrators must
reduce backup-and-restore windows while keeping up with ever-growing data sets. To accomplish
these seemingly contradictory tasks, you either have to improve your storage capabilities or minimize

                                 Brought to you by Symantec and Windows IT Pro eBooks
18   A Guide to Windows Disaster Recovery and Backup


the amount of data you back up. Therefore, as you reexamine your backup strategy, concentrate on
two primary goals: improving the facility and reducing the data set.

Improving the Facility
To improve your backup-and-restore capabilities, concentrate on hardware and software technologies
that increase backup-and-restore rates and the facility’s capacity. For example, if your servers have
one DLT drive that stores 50GB of data on tape at a rate of 10GB per hour during backup, consider
technologies that let you back up 100GB at 20GB per hour. You might need to upgrade to a new
DLT drive, select a new tape technology, or make the leap to SAN- or VSS-based data cloning or
replication. You must also consider how your backup window affects recovery time. If you can back
up all your data in 4 hours, you probably have discovered that restore times can be as long as 6 to 8
hours.
     Many administrators concentrate on recovery time rather than backup time, which is a smart
move. With NAS and SAN becoming more widely deployed and disk-storage costs decreasing (while
capacities increase), some administrators are turning to backup-to-disk technology to shrink backup-
and-restore windows and are using the technology as a complement or even a replacement for tape-
based backups. This popular method has huge advantages over traditional techniques. My favorite
procedure is a hybrid approach that leverages backup-to-disk technology for recent backup sets (e.g.,
T minus 2 days) and stores older (e.g., T minus 28 days) backup sets on tape so that I can rotate
them off site. Whichever approach you use to improve your facility, identifying the measures
(according to your business constraints and requirements) you can use to more quickly back up and
restore more data is of paramount importance.

Reducing the Data Set
Improving the facility and reducing the data set are closely related tasks, but the latter is a more chal-
lenging problem. If you increase your facility capability, the need to reduce the data set decreases
(and vice versa). By reducing the size of your recovery unit, you can manage that unit within your
business constraints and requirements. This scenario doesn’t address whole-server recovery but con-
centrates on the most important part of the equation—the data. One way to manage or reduce the
size of your recovery unit is to impose quotas. You could also increase the number of manageable
recovery units and thereby reduce the size of each unit. For example, for Exchange Server 2003, you
could divide your 50GB Information Store (IS) into five 10GB stores and reduce the time it takes to
back up and restore each unit (doing so doesn’t actually reduce the amount of data; it simply divides
the data into more manageable units). Although this approach increases complexity, it concentrates
on manageable units of recovery that affect smaller populations of users.
     Data grooming or archiving is another technique that’s used to reduce recovery-unit size. This
approach lets you concentrate on the most important or mission-critical portions of your data and
migrate the less important data to alternative storage locations, such as tape or optical media. When it
comes to implementation, data grooming is similar to Remote Storage Service (RSS) for Windows, in
which files are migrated to near-line storage according to policies. Exchange and SQL Server also use
similar database archival and grooming techniques. But don’t be fooled: If you relocate less-crucial
data to an alternative storage location, you still need to figure out which level of protection to
provide for that data or you could compound your problems. Whichever approach you use, reduce
the amount of data in the primary storage location.

                                  Brought to you by Symantec and Windows IT Pro eBooks
                                                                  Chapter 3 Fine-Tune Your Backup Strategy 19



Make Your Life Easier
During the past few years, backup software vendors and OS and application vendors have brought
us many improvements in hardware and software technology, which should be reason enough to
take a fresh look at how you protect your organization’s data. If you’ve already employed some of
these new technologies, you might want to think about how you can reduce or optimize your
recovery-unit size. If you can maximize your facility and minimize the data you must back up and
restore, your job as an administrator will be much easier.




                                Brought to you by Symantec and Windows IT Pro eBooks
20    A Guide to Windows Disaster Recovery and Backup



Chapter 4:

Disaster Prevention:
Preparing for the Worst
—By Kalen Delaney

Many people break the subject of high availability into two parts—disaster prevention and disaster
recovery—and discuss the topic as if every step in a high-availability solution fits neatly into one
arena or the other. However, while I was planning for this chapter and trying to determine which
activities constitute disaster prevention and which constitute disaster recovery, I found that the line
between the two isn’t a neat one. I also realized that to distinguish between disaster prevention and
disaster recovery, you need a clear definition of “disaster” for your organization.
     If you define disaster as something outside the technical realm, such as a flood or earthquake,
then preventing disaster isn’t possible, at least for the IT staff. In such a case, you’d focus on disaster
preparedness. But if you concentrate on disasters directly involving technology, drawing the line
between prevention and recovery is difficult. For example, if you define the loss of your SQL Server
as a disaster, you might implement a clustered SQL Server environment so that a SQL Server on
another machine automatically takes over for the failed server. That failover lets you recover from the
disaster of losing your primary SQL Server. However, most people think of a clustering solution as
disaster prevention.
     Similarly, most people think of backup-and-restore strategies as disaster recovery. However, if
you define a disaster as a loss of data and if a complete restore from backups prevents data loss
because of a disastrous event, did the disaster occur, or did you prevent it? Because you need good
backups to perform a complete restore and you have to perform backups before a disaster occurs,
you can think of an effective backup strategy as a disaster-prevention technique.
     So what exactly constitutes a disaster? For the purpose of this chapter, a disaster is a loss of pro-
duction data or downtime that causes a loss of productivity. For your own purposes, if you think a
particular event is a disaster for your business, it’s a disaster.
     When I distinguish between disaster prevention and disaster recovery, I suggest that prevention is
what you can do before something happens and recovery is what you do after. The “something”
could be an event that’s preventable, such as multiple disk failures, or it could be an event that’s
unpreventable, such as an earthquake. In the latter case, you don’t look for ways to prevent the
event; you look for ways to be prepared and prevent the event from causing an unacceptable loss of
data or productivity. Let’s look at some best practices that will help you prepare for the worst.

Strategies for Disaster Prevention
Dealing with disaster takes many forms, but I’ve come up with my top five best practices for disaster
prevention. Adhering to these practices will help you plan and implement a disaster-prevention plan
for your organization.


                                  Brought to you by Symantec and Windows IT Pro eBooks
                                                    Chapter 4 Disaster Prevention: Preparing for the Worst 21


      Make a list of possible disasters. No matter how ridiculous or improbable an event might
seem, if it could cause downtime or loss of data, list it and think about what you would do if it
happened. Some improbable examples might be a meteor demolishing your entire site or the entire
IT staff coming down with food poisoning at the company picnic. I always put this step first because
keeping these possibilities in mind will help you decide how to carry out each of the other strategies
I suggest.
      After planning for—or at least considering—the worst possible disasters and determining what
steps you can take to minimize the risk, evaluate the cost-benefit ratio of taking those steps. If
protecting your data against a catastrophic but low-probability event—such as a meteor strike—
would cost a lot, you might decide to take the risk and not provide specific protection for that event.
Document your decision so that coworkers and successors know that you at least considered the
possibility. However, you might discover that protecting your data against some low-probability
events doesn’t cost much. For example, you might already store database backups in a location
across town, but what would happen if the meteor destroyed the entire town? If your company
already ships regular backups for another system or application to another town, the cost of adding
tapes of your SQL Server backups to that shipment might be negligible. So although the likelihood of
a meteor strike might be small, the cost to save your data if that unlikely event occurs might also be
small.
      Also, be sure to plan for the infamous “user error” in your list of possible disasters. User errors
can be the most difficult disasters to prevent and can take the longest to recover from. Users commit
such errors as accidentally deleting data rows, tables, or an entire database. SQL Server makes it easy
for users with high levels of privilege to do lots of damage. Although referential integrity, schema
binding, and triggers can help prevent inadvertent deleting of rows or dropping of tables, SQL Server
provides little protection against dropping an entire database. Unlike in earlier SQL Server releases, in
which the DROP DATABASE command didn’t actually remove the physical files from the file system,
when you drop a database in SQL Server 2000 or 7.0, SQL Server deletes the disk files holding the
data, so the database is really gone.
      Users can also create havoc by implementing the wrong procedure. Many procedures have
similar names, and if a typing error causes a user or an application to call the wrong procedure, you
might not notice the damage for some time. You’ll lose more time while you track down the
problem, and even more time before you start correcting the problem and undoing the damage.
      Note that ineffective security can foster user errors. Weak or nonexistent passwords, along with
allowing too many users too much privilege, can compromise system and data integrity. Accidental
deletions are also more likely when users have higher permission levels than they need.
      Create effective operational processes. Document all your planning decisions (including your
list of possible disasters) and recovery procedures, and store copies of the documentation off site.
Remember that high system availability involves people and processes as much as it involves tech-
nology. If you don’t clearly define the processes for disaster prevention and disaster recovery, or if
the people involved don’t understand the processes, all the technology in the world won’t help you.
      After you’ve created operational processes, you need to verify that your processes do what you
need them to do. Make sure your test servers are configured exactly like your production machines—
with the same hardware and the same workload—so that the test machines can accurately predict the
capabilities of the production machines in the event of a disaster. When you run simulations of com-
plete system failure and measure how long a complete system rebuild and restore takes, be sure that

                                  Brought to you by Symantec and Windows IT Pro eBooks
22   A Guide to Windows Disaster Recovery and Backup


the time the test machines take to complete the operations is an accurate predictor of how long the
operations will take on your production system.
      Understand and implement technologies to prevent downtime. Learn everything you can
about the technologies available to prevent or reduce downtime. Learn about redundant hardware
solutions such as clustering, and investigate companies that offer split-mirror backup technology or
other types of fast backup-and-restore solutions. The only downtime that fast-backup and split-mir-
roring solutions need is the time it takes to perform a restore. And with split-mirror backup, the
restore happens almost immediately after an administrator requests it.
      Many solutions for avoiding downtime depend on your hard-disk system. The disks are the most
active part of any system—and no system is foolproof. Even if you implement the best RAID system,
the hardware system could still fail and make the entire array unavailable. With RAID, you also need
to remember that fault tolerance might apply to only one drive failure, so you have to consider the
possibility of a second drive failing. Don’t get complacent and think that the chance of a second drive
failing soon after the first is remote. If you purchased all your drives at the same time, the other
drives are the same age as the failed drive and might also be nearing failure. And remember that
even the most redundant drive system won’t protect you against user errors. If a user accidentally
drops a production table, all the redundant drives will reflect that drop. If you don’t know a drive has
failed and you don’t replace the drive before a second failure occurs, you risk complete system
failure. Make sure that you regularly check your logs for a message in the log that tells you a drive
has failed or that you receive automatic notifications when failures occur.
      Consider warm-standby solutions. In solutions that prevent downtime almost completely by
using redundancy, the redundant hardware is called a hot standby. Another solution that isn’t as
costly but provides comparable protection is called a warm standby. Unlike a hot-standby system
such as a clustered SQL Server, a warm standby requires human intervention at the application level
to make the switch from the failed system to the standby system.
      The two most common warm-standby solutions are log shipping and replication. A great feature
of both of these solutions is that they can have serendipitous performance benefits. For example, in
some cases, log shipping can provide a second read-only copy of your data that you can use to off-
load some of the reporting work from the production server. And depending on the type of replica-
tion you implement, you can frequently use replication to distribute your entire workload across more
systems so that each system performs more effectively.
      Plan your backup-and-recovery strategy. Although you could consider planning a backup-
and-recovery strategy as part of one of the previous best practices, I list this as a separate strategy
because it’s so crucial—even if you do nothing else, you must save the data. If your only manage-
ment experience with SQL Server is through Enterprise Manager, you might think backup is a simple
one-step operation or that once you define a maintenance task, you don’t need to think any more
about it. But if you want to be truly prepared to avoid disastrous loss of data or productivity, you
need to learn all you can about SQL Server’s backup and restore capabilities. SQL Server has three
recovery modes, each of which affects backup and restore operations in different ways. SQL Server
lets you back up the entire database, the transaction log, and individual files or filegroups. In
addition, you can make differential backups of the database that let you back up just the data that
has changed since the last full database backup. And in SQL Server 2000, you can also perform
differential file or filegroup backups. For information about all the factors to consider when planning
your backup strategy, read Microsoft SQL Server 2000 High Availability by Allen Hirt, et al (Microsoft

                                 Brought to you by Symantec and Windows IT Pro eBooks
                                                   Chapter 4 Disaster Prevention: Preparing for the Worst 23


Press, 2003). Kimberly L. Tripp’s Web-exclusive article “The Best Place for Bulk_Logged,”
http://www.sqlmag.com, InstantDoc ID 39782, is an excerpt from this book, and her article
“Recovering from Isolated Corruption,” InstantDoc ID 39657, explains how to recover from losing one
table’s data.
     No one solution or plan can provide complete disaster protection for your system, so you need
to put in place people, processes, and technology that combine to give your organization the greatest
possible chance for survival. These suggested practices can give you a place to start planning for the
survival of your organization’s precious data




                                 Brought to you by Symantec and Windows IT Pro eBooks
24    A Guide to Windows Disaster Recovery and Backup



Chapter 5:

Backup and Recovery Tips & Tricks
Setting Up a Disaster-Recovery Location
—Bob Chronister


Q   I’m setting up a business continuity/disaster recovery location and am looking for
    options to replicate LUNS on my Storage Area Network (SAN) between our primary and
disaster recovery sites. Our disaster recovery site is 150 miles from our primary office. How
do I estimate how much bandwidth will be required to move 5GB per hour?


A   You need to consider many things when putting together requirements for a disaster recovery site.
    Because I have limited space, I’ll respond in general concepts, but plenty of books on this subject
are available.
     First, you must determine which services and data you need to replicate to the remote site. Next,
consider what supporting information the services and data might require and determine whether the
data to be replicated is order-specific (e.g., don’t replicate B until A has finished replicating). You also
must consider tolerances for data synchronization. Can the remote site be in sync within 10 minutes?
20 minutes? An hour? This information helps you determine bandwidth requirements. After you’ve
made these determinations and considered the environmental and equipment concerns, you can
move on to the “how” of replication.
     As for bandwidth requirements, you can probably replicate 5GB per hour over a 10Mbps
connection. Depending on your area, many telecom carriers offer a higher-performance metropolitan
area network (MAN) solution, but this solution is often limited to sites located within 180 miles of
each other.
     The most common solution of this type is Ethernet over Synchronous Optical Network (SONET),
which essentially gives you a Layer 2 Ethernet handoff at each location. The advantages of this type
of solution over a time-division multiplexing (TDM) solution, in which multiple low-speed signals are
time-sliced into a high-speed transmission, are obvious—lower latency and no need for a dedicated
router. You can also look into Multiprotocol Label Switching (MPLS) or VPN options in your area.




                                  Brought to you by Symantec and Windows IT Pro eBooks
                                                                Chapter 5 Backup and Recovery Tips & Tricks 25



Setting NTBackup to Not Use VSS
—Bob Chronister


Q     I’ve noticed that in Windows Server 2003, you can disable NTBackup’s use of Microsoft
      Volume Shadow Copy Service (VSS). What are the ramifications of choosing this option?


A  Before Windows 2003, it was impossible to back up open files, regardless of how the file was
   opened. Third-party software partially solved the problem but slowed the backup process and
required a software purchase. VSS lets you back up open files. Consequently, you can back up open
databases, email messages, and so forth without first closing the file. I certainly wouldn’t disable VSS.


Backing Up and Restoring User Profiles
—John Savill


Q     How can I back up and restore user profiles when deploying a new OS via the Microsoft
      Systems Management Server (SMS) OS Deployment Feature Pack?


A   You can integrate User State Migration Tool (USMT) with the SMS OS Deployment Feature Pack to
    facilitate the backup of user profiles on a machine before you replace its existing OS with a new
disk image. You can then restore the profiles after the upgrade.
     To back up the user profiles, you first need to download USMT 2.6 (this version supports
backup of all user profiles on the OS, not just the currently logged-on profile), which is available at
http://www.microsoft.com/downloads/details.aspx?familyid=4af2d2c9-f16c-4c52-a203-
8daf944dd555&displaylang=en. Run the installation program, which by default installs USMT in the
C:\usmt folder. Next, create a share of the C:\usmt\bin folder and name it USMT. The share requires
only read permissions.
     Now you need to modify the OS program that you created for your OS image package so that it
uses USMT to back up the user profiles and restore them after you deploy the new OS. To do so,
perform these steps:
 1. Start the Microsoft Management Console (MMC) SMS Administrator Console snap-in (Start,
     Programs, Systems Management Server, SMS Administrator Console.)
 2.   Expand Image Packages, expand OS Package, and select Programs.
 3.   Right-click OS Program and select Properties.
 4.   Click the Advanced tab.
 5.   From the Phase drop-down menu select State Capture, then click Add.
 6.   Under Options, select Capture User State and click OK.
 7.   Enter the source folder for the USMT files (i.e., the share you created earlier that points to
      C:\usmt\bin), as the figure shows. By default, the files migism.inf and usmtdef.inf are included
      among the configuration files. Click Add and select migsys.inf (to retain the user settings),


                                   Brought to you by Symantec and Windows IT Pro eBooks
26    A Guide to Windows Disaster Recovery and Backup


     miguser.inf (to retain user files such as the contents of My Documents and My Pictures), and
     sysfiles.inf (to stop the scanning of core OS files). Finally, in the “Specify additional command
     line options” field, add “/all” to capture all profiles on the machine (without this switch the USMT
     execution will fail on Windows 2000 clients). Click OK.

                                                     Figure 1
                                        Entering the source folder




 8. From the Phase drop-down menu, select State Restore, and click Add.
 9. From the options, select Restore User State and click OK.
10. You shouldn’t need to modify the settings on the User State Restore page. Just confirm that the
    Source Folder points to the correct location and click OK, as the figure shows.




                                  Brought to you by Symantec and Windows IT Pro eBooks
                                                              Chapter 5 Backup and Recovery Tips & Tricks 27



                                                    Figure 2
                                          User State Restore page




11. Click OK to accept the program changes and close the dialog box.
12. You’ll be reminded to update the distribution points, which you do by right-clicking the Distribu-
    tion Points branch and selecting Update Distribution Points via the All Tasks context-menu item.

     When existing clients receive the new OS, they store the data in C:\minint\smsosd\statestore\
usmt2.unc. When the new OS is deployed to disk and the machine starts locally, the system restores
this user-state backup data so that existing files, desktop background, sounds, and other user settings
are maintained.


Running NTBackup from the Command Line
—Bill Stewart
When you create a scheduled NTBackup job, it creates a scheduled task that contains the Ntbackup
command. You can view all the available command-line options for the Ntbackup command by
opening the command-shell window and entering
ntbackup /?

at the command prompt, then pressing Enter. Most of the Ntbackup command’s options are self-
explanatory, and it’s easy to find their corresponding options in the Backup Wizard. However, several
command-line options merit an explanation.




                                 Brought to you by Symantec and Windows IT Pro eBooks
28   A Guide to Windows Disaster Recovery and Backup


     In the /j JobName option, JobName corresponds to the job name you’d specify when you use
NTBackup’s built-in scheduling feature to create a schedule for a job. This name is also used in the
Backup Reports window.
     In the /d SetDescription and /n MediaName options, SetDescription and MediaName correspond
to the Backup label and Media label text boxes, respectively, in the Backup Wizard’s Backup Label
page. If you’re scheduling a backup job that overwrites a tape (i.e., you’re not using the /a option)
and you don’t specify the /n option, NTBackup will label the tape with the date and time when the
job started.
     If you create a scheduled job that uses a prepared tape, the Ntbackup command includes the /g
GUIDName option. A globally unique identifier (GUID) is a statistically unique 32-bit number that
identifies each tape in the Removable Storage database. In the Removable Storage database, an allo-
cated tape can have several GUIDs. The /g option requires the logical media GUID for the allocated
side of the tape. If the specified tape isn’t in the drive when the job starts, the backup will fail.
     If you decide to manually create your own scheduled backup jobs, you can use the /t TapeName
option to specify a named tape. The tape name (i.e., TapeName) you specify with the /t option must
correspond to the Info field on the tape’s allocated side. To find out this name, open the Removable
Storage console, double-click the tape, and select the Side tab. As with the /g option, the specified
tape must be in the drive at the time the scheduled job runs.
     For networks that use Microsoft Exchange 2000 Server and later, you can back up Exchange’s
information store by using the /is ServerName option, where ServerName is the name of the
Exchange server. Note that to back up a remote Exchange server’s information store, you either
need to install Exchange System Manager (ESM) on the system running NTBackup or follow the
instructions in the Microsoft article “XADM: How to Use NTBackup from a Non-Exchange 2000
Computer” (http://support.microsoft.com/?kbid=275876). Also note that if you’re running Windows
Server 2003 and Exchange Server 2003, there’s a problem you need to know about. If you try to
back up both the system state and Exchange data in the same job, the backup will fail. To work
around the problem, you can use separate backup operations to back up the system state and
Exchange data or you can move the Exchange databases to a different drive. For more information
about this problem, see the Microsoft articles “Backup Operation Fails When You Back Up
Exchange Server 2003 Databases and System State Information at the Same Time”
(http://support.microsoft.com/?kbid=820272) and “Backup of the Exchange Server 2003 Information
Store and the Windows Server 2003 system state Data Does Not Complete Successfully and Event ID
8019 Is Logged”(http://support.microsoft.com/?kbid=820852).


A Weekend of Downtime
—Paul Robichaux

You’ve probably heard of George Santayana, but you might not have heard of David Sifry. Both men
have something valuable to teach us.
    Santayana (1863-1952) was a uniquely American philosopher and literary critic. Of his many
works, he’s best known for a single quote: “Those who do not learn from history are doomed to
repeat it.” Sifry is the inventor and developer who launched the popular Technorati Web site


                                Brought to you by Symantec and Windows IT Pro eBooks
                                                               Chapter 5 Backup and Recovery Tips & Tricks 29


(http://www.technorati.com). Technorati is, at heart, a search engine dedicated to searching Web logs
and exposing connections between them. The site has become exceptionally popular, in part because
of a cool feature that shows which sites are linked to other sites. So, what do these two men have in
common?
      Recently, Technorati was down for an entire weekend—from Friday night until Monday
morning—because of a chain of problems. Sifry detailed the outage, and his company’s response to
it, in his blog. If you adhere to Santayana’s philosophy, you can learn several lessons from Sifry’s
experience—and hopefully prevent a similar trauma yourself.
      Lesson 1 comes simply from the fact that Sifry took the unusual step of publicizing his experi-
ence. Most companies would rather die than admit that they’ve had an outage. The first lesson, there-
fore, is that being open about your availability problems can benefit others (although political
constraints might keep you from spilling all the beans).
      So, what happened to Technorati’s service? First, an electrical fire at the collocation facility that
houses Technorati’s servers cut power to the servers. The facility’s UPS units kicked in but the backup
generator didn’t (either the generator failed or was damaged by the fire). The UPS units eventually
ran out of power, and the servers shut down—ungracefully, leading to widespread data corruption.
Hence, lesson 2: Always have an emergency mechanism in place to gracefully shut down your
servers.
      The good news is that Sifry and his staff diligently kept daily backups, which they were able to
restore. The bad news is that they had to restore those backups on more than 100 servers. That
certainly isn’t how most of us would choose to spend a weekend and vividly illustrates lesson 3: Tier
1 hosting facilities are expensive, but the extra money buys you a much higher degree of insurance
against the kinds of problems Sifry experienced.
      The incident, says Sifry, sparked a comprehensive review of his company’s availability require-
ments and processes. His team had planned to implement a better shutdown system for their servers,
but decided to defer the implementation until after they’d moved the servers to a new collocation
facility. Lesson 4: Putting off disaster planning doesn’t pay.
      What if your servers were all down for an entire weekend? Would it put you out of business or
be just a minor inconvenience? For most of us, the answer is somewhere in between the two
extremes, but it’s a darned good idea to know the answer ahead of time, and find any holes in your
disaster recovery plan before disaster strikes.


Welcome to the Danger Zone
—Paul Robichaux

Every so often, I get the urge to write about disaster preparedness. This is probably because I grew
up in coastal south Louisiana, where hurricane season is frighteningly real. In the aftermath of Hurri-
canes Katrina and Rita, now seems like a good time to review some simple steps you can take to
help prepare your messaging system—and thus your organization—for disasters.
    I won’t insult your intelligence by telling you to make good backups. (That’s such a basic part of
messaging operations that no one needs to be reminded, right?) Instead, let me start by asking some
questions.


                                  Brought to you by Symantec and Windows IT Pro eBooks
30     A Guide to Windows Disaster Recovery and Backup


     First, where do you keep your backups? If they’re near your servers, anything bad that happens
to your servers will likely also happen to your backups. You don’t need to keep all your backups
offsite, but keeping at least some backup tapes in a secure offsite location is a good idea. Your safe
place can be as simple as a fire-rated media vault (not an ordinary fire safe, which won’t protect
tapes and disks) at your house or as elaborate as a secure facility operated by SunGard, Iron
Mountain, or another data-recovery/business-continuance company.
     Second, how will you tell your employees what to do when a disaster occurs? Surely everyone
who works in an area hit by a hurricane (or a fire, mudslide, earthquake, or tornado) will know
what’s happening outside, but they might not know what’s happening inside your organization. Is the
office open? Closed? Do certain employees need to report anyway (a common requirement in manu-
facturing environments in which plant machinery can be damaged or destroyed if not tended continu-
ally)? You probably can’t count on using your messaging system to get this kind of information out to
employees; your servers might be on fire, under water, flying through the air, or otherwise unavail-
able. One alternative is to use a system such as MessageOne’s Emergency Messaging System (EMS),
which lets you quickly send emergency notifications to preregistered alternate addresses and switch
your incoming MX records over to the vendor’s hosted server. That way, users can still send and
receive email without using your servers. Similar tools from Dialogic Communications (among others)
can automatically send prerecorded telephone messages. This approach is helpful for notifying
employees but doesn’t give you any ongoing messaging capability.
     Third, what about resuming operations? Will you continue operating in an alternate location? You
can plan for this in a variety of ways, ranging from setting up full-blown, geographically dispersed
clusters to planning to express-mail backup tapes to an alternate location and use Exchange Server
2003’s Recovery Storage Group feature to restore messaging service. Alternate-site recovery planning
involves too many considerations for me to cover here, but if you’re seriously interested in being able
to move your Exchange operations to an alternate site, I suggest you read Jerry Cochran’s excellent
book “Mission-Critical Microsoft Exchange 2003 Server: Designing and Building Reliable Exchange
Servers” (Digital Press, 2003). Then consider which technologies and tools make the most sense in
light of your availability requirements and budget constraints.
     As a final thought, don’t forget that your hardware and bandwidth service agreements probably
contain language about “acts of God,” so if your area is hit by a major disaster, don’t count on getting
the immediate service you’ve paid for. Have alternatives ready if such events are likely to be a
problem for you.


Dealing with a System Restore–Related Problem
—Bob Chronister


Q    I recently had to perform a system restore on a Windows XP computer, and now the
     system’s user can’t access our Windows Server 2003 domain. What happened?


A    System Restore has a few irritating quirks, and you’ve run into one of them. Fortunately, this one
     is easily resolved. By default, XP users must change their domain password every 30 days; my



                                  Brought to you by Symantec and Windows IT Pro eBooks
                                                               Chapter 5 Backup and Recovery Tips & Tricks 31


guess is that at least one password-change interval had passed on the system in question. When you
performed the restore, you returned the system to a restore point that was saved before the most
recent password change. This created a conflict with information stored in Active Directory (AD). In
your case, the password stored on the local system was probably reset to an earlier password. There-
fore, the password no longer matches the password stored in AD. Remove the user from the domain,
then add the user back to the domain. For more information about password-related problems that
can appear after you operate System Restore, see the Microsoft article “Issues with domain member-
ship after a system restore” (http://support.microsoft.com/?kbid=295049).


Backing Up the System State
—John Savill


Q   Why can’t I back up the system state on my Windows 2000 Server system?



A   The system state contains core system elements such as Active Directory (AD); the System Volume
    (Sysvol), the machine’s domain controller (DC) status (i.e., whether the system is a DC); the boot
files; the registry; and COM+ configuration information. To back up the system state, the user must
have “Back up files and directories” and “Restore files and directories” rights; otherwise, the option to
back up the system state might be unavailable in Windows Backup. To grant these rights, perform
the following steps:
  1. Log on to a DC.
  2. Start the Microsoft Management Console (MMC) Domain Security Policy snap-in (go to Start,
      Programs, Administrative Tools, and click Domain Security Policy).
  3. Expand the Security Settings, Local Policies, User Rights Assignment branches.
  4. Double-click the “Back up files and directories” policy.
  5. Select the “Define these Policy Settings” check box, then click “Add Users or Group.”
  6. Click Browse and locate the user you want to add (or a group that the user is in), then click OK.
  7. Click OK to return to the main policy dialog box.
  8. Repeat Steps 5, 6, and 7 for the “Restore files and directories” policy.
  9. After you finish Step 8, close the snap-in and force a refresh of the policies. To refresh the
      policies, open a command line and type
    secedit /refreshpolicy machine_policy /enforce

10. Log off and log on.




                                  Brought to you by Symantec and Windows IT Pro eBooks
32   A Guide to Windows Disaster Recovery and Backup



Speed Up an Authoritative Restore
—Brian Taché

My company recently needed to perform an authoritative restore because someone inadvertently
deleted an organizational unit (OU). A Directory Service (DS) restore was faster than manually
recreating the OU because the OU contained more than 80 user accounts.
     A concern when performing a DS restore, other than taking a production domain controller (DC)
offline, is global group handling. Deleting a user account also deletes the global group memberships.
When you then try to restore a user account—or, in our case, an OU that contains user accounts—
the global group memberships are missing.
     If we hadn’t performed an authoritative restore, we would have needed to know all the global
groups that the 80 user accounts belonged to, restored all the groups, ensured that the groups
replicated domainwide, then restored the user accounts. Alternatively, we could have performed a full
Active Directory (AD) restore—but we would have lost any AD changes that occurred after our last
full backup, and the restore would have caused bandwidth loss because the entire AD system would
have replicated to all 30 of our remote sites.
     We decided to slow intersite replication on one of our remote sites and use that site to restore
the OU and user accounts. We selected a site with few clients and with clients that don’t require
domainwide AD changes to be instantaneous. We then slowed intersite replication on that site from
every 15 minutes to every 2 days. We were then able to access the AD system on the remote site and
determine to which groups the 80 user accounts belonged. We manually readded the users to the
global groups to which they belonged. The whole process took less than an hour. The globally
unique identifiers (GUIDs) remained intact, so the AD objects we restored had the same permissions
they had before the object deletion.


Solving a Restore Problem
—Bob Chronister


Q  I have several Windows 2000 tape sets from which I can’t restore a file on the final tape.
   This restriction has proved disastrous on several occasions. How can I rectify the
problem?


A  During your restore operation, you need to disable Win2K’s Fast File Restore, which has been
   known to present the type of problem you describe. To do so, open a registry editor, go to the
HKEY_CURRENT_USER\Software\Microsoft\Ntbackup\Backup Engine\Use fast file restore registry
subkey, and change the value from 1 (enabled) to 0 (disabled). Perform your restore, then reset the
value to 1 to reenable Fast File Restore.




                                Brought to you by Symantec and Windows IT Pro eBooks
                                                              Chapter 5 Backup and Recovery Tips & Tricks 33



Performing an Authoritative Restoration of AD
—John Savill


Q   How can I perform an authoritative restoration of Active Directory (AD) in Windows
    Server 2003?


A  To perform an authoritative restoration, you must first recover AD from a backup by performing
   the following steps:
 1. Restart the domain controller (DC) of interest.
 2. When you see the menu to select the OS, press F8.
 3, From the Windows Advanced Options Menu, select Directory Services Restore Mode, then press
    Enter.
 4. Select the Windows 2003 OS, then press Enter.
 5. Use the restore mode password and log on as the administrator.
 6. Click OK to the confirmation that Windows is running in Safe mode.
 7. Start the Windows Backup application (go to Start, Programs, Accessories, System Tools, and
    click Backup).
 8. Select the Restore option, then select the media where the backup is stored and ensure that the
    System State is selected.
 9. Click OK to close any warning dialog boxes.
10. After the AD recovery is complete, click Close to the displayed dialog box and click Yes to restart
    the computer.

    When the machine restarts, you need to specify which parts of the restoration will be
authoritative by performing the following steps:
 1. When you see the menu to select the OS, press F8.

    From the Windows Advanced Options Menu, select Directory Services Restore Mode, then press
Enter.
 2. Select the Windows 2003 OS, then press Enter.
 3. Use the restore mode password to log on as the administrator.
 4. Click OK to the confirmation that Windows is running in Safe mode.
 5. Open a command prompt—go to Start, Run and type
    cmd

 6. Start the Ntdsutil utility.
 7. To access the authoritative restore mode, type
    ntdsutil: authoritative restore


                                 Brought to you by Symantec and Windows IT Pro eBooks
34    A Guide to Windows Disaster Recovery and Backup


 8. If you want to mark the entire database as authoritative, type
     authoritative restore: restore database

 9. If you want to mark only a certain object as authoritative (e.g., an organizational unit-OU), type
     authoritative restore: restore subtree <distinguished
     name--DN--of subtree, e.g. OU=sales,DC=savilltech,DC=com>

10. To exit Ntdsutil, type
     quit

11. Restart the DC as usual.

     If you perform an authoritative restoration of a backup that’s more than 14 days old, some trust
relationships might be broken because the passwords used by the trust would have been changed
twice (the directory stores both the current and previous password, which changes every 7 days). So,
for example, when restoring NT LAN Manager (NTLM) trusts, you would have to break the trust, then
recreate it.


Command-Line Syntax for a Backup
—John Savill


Q    How can I easily construct the command-line syntax for a backup job in Windows XP
     and later?


A   Because several switches and commands are available when performing a backup from the
    command line, keeping track of your backup configuration can get complex. Fortunately, you can
use the Backup Wizard to construct a dummy backup job that lets you see the equivalent command-
line options. To do so, perform the following steps:
  1. Start Windows Backup.
  2. Select the Schedule Jobs tab.
  3. Select a day, then click Add Job.
  4. Click Next on the first screen of the Backup Wizard page that appears.

     Select the files, folders, or drives that you want to back up, then click Next. (Depending on
which options you select, you might have to navigate through additional screens to manually select
the items you want to back up.)
  5. Select the destination for the backup, then click Next.
  6. Select the type of backup that you want to perform, then click Next.
  7. Select any options you want performed during the backup (e.g., “Verify data after backup”), then
     click Next.

                                 Brought to you by Symantec and Windows IT Pro eBooks
                                                              Chapter 5 Backup and Recovery Tips & Tricks 35


 8.   Select the backup overwrite options, then click Next.
 9.   Select when to run the backup, as this figure shows, give it a job name, then click Next.
10.   Enter the user account information necessary to perform the backup, then click OK.
11.   Click Finish.
12.   Windows Backup will create a new backup job. Right-click the new job to display the Properties
      dialog box, then click the Properties button. Select the Task tab to view the Ntbackup command
      that will be used to run the backup job. For example, the Backup Wizard constructed the fol-
      lowing Ntbackup command for my job:
      G:\WINDOWS\system32\ntbackup.exe backup “@G:\Documents and
      Settings\savijo\Local Settings\Application Data\Microsoft\Windows
      NT\NTBackup\data\Full system normal backup.bks” /n “backup.bkf created
      13/11/2003 at 13:50” /d “Set created 13/11/2003 at
      13:50” /v:no /r:no /rs:no /hc:off /m normal /j “Full system normal
      backup” /l:s /f “E:\backup.bkf”

13. Click Delete to remove the backup job. Easy! :-)


Is True Recovery Always Possible?
—Kalen Delaney

Despite what some advertisements lead you to believe, when a disaster strikes, you need more than
just a large insurance policy to get things back to normal. And in some cases, you simply can’t bring
a business back to where it was before the disaster.
     Mike Hotek, a principal mentor and colleague of mine at Solid Quality Learning, is one of the
world’s leading experts in SQL Server replication and high availability. As a consultant, Hotek works
with companies of all sizes, from Fortune 100 firms to organizations with only a dozen people.
Twelve of Hotek’s client companies were housed in the World Trade Center in New York on
September 11, 2001. Of those 12 companies, seven were destroyed that day. Although some data
might have survived, no people from those companies remained to care about the information.
     Survivors from each of the other five companies contacted Hotek for help. The first company
called 2 days after the attack. Hotek spent only half a day working with that company because every
piece of data the company owned and any information about how to recreate the data was lost
when the Twin Towers collapsed. The business didn’t survive. Two of the other four companies that
had survivors were in similar situations—they simply didn’t have anything left with which to restart
their businesses. The remaining two companies have survived—primarily because they implemented
Hotek’s suggestions for disaster prevention and preparedness. Hotek described to me his experiences
with these surviving businesses.
     During the first week after the attacks, Hotek slept at most an hour each night. Despite all the
disaster planning and preparation his clients had done, recovery took weeks of hard work. However,
both companies were minimally functional within a week because of a fortuitous coincidence. Both
companies had ordered new hardware before the attack, so in the week after September 11, they

                                 Brought to you by Symantec and Windows IT Pro eBooks
36   A Guide to Windows Disaster Recovery and Backup


contacted the hardware vendors and redirected the hardware to the companies’ new locations. Those
preexisting hardware orders became the starting point for their new systems. One company was fully
functional in about 18 days; the other was operating normally in about a month.
     The magnitude of this particular disaster made full site recovery different in two ways from other
disasters that require a complete system rebuild. First, because of the widespread devastation, no one
had any idea how fast the system might be back up. No company officers or stockholders were
breathing down the necks of Hotek and the survivors, asking “How much longer?” That the compa-
nies even had survivors was a miracle, so the news that the businesses might be operational again
was beyond anyone’s expectations. So no external pressures forced the companies to hurry their
recovery.
     The second reason this recovery was different from typical scenarios was more personal.
Although many disaster-prevention strategy lists specify making sure that more than one person has
all the system passwords and knows where the backups are stored, few people really plan for what
they would do if the entire IT staff was no longer available. Both surviving companies lost most of
their IT staffs, and the remaining people were in shock. Fortunately, in both cases, Hotek also had
most of the necessary information because he’d helped the companies set up their disaster-recovery
plans. For both companies, he was the one person who knew about the technology requirements of
the businesses—which is why he gave up sleep for a while. Although company officers and stock-
holders didn’t expect an immediate recovery, Hotek realized that he needed to help the companies
recover as quickly as possible. He took these six basic steps to get both businesses functioning again:
  1. Determined what skills were available among the survivors
  2. Procured funding for recovery efforts
  3. Found a new site and ordered new hardware for the most crucial systems
  4. Hired contractors to help rebuild the systems
  5. Located all the backups and process documents and determined what data was still available
  6. Got the surviving IT staff and the contractors working

     For both companies, part of the recovery effort involved planning a whole new information-
management infrastructure that built in disaster-prevention and recovery strategies, including both
hot- and warm-standby systems. Hotek explained that he became a replication expert because of all
the work he does for disaster preparedness. When he sets up a replicated system, he gains the
immediate benefit of having a distributed, scalable system, and he has a warm standby to turn to if
some systems are lost.
     Today, both companies are still in business and restaffed, although they are slightly smaller today
than they were before September 11. Hotek still works with the companies, performing checkups and
reviews. He still has specific knowledge about their systems that no one else knows because he
designed and implemented those systems. But he believes his role will phase out over the next year
or so, at which time he plans to turn over his knowledge to inhouse IT staff. Today, both companies
have redundant offsite hardware that they can bring in at short notice. They both have distance
clusters 25 miles from their main sites, and they use log shipping to keep the distance clusters in
sync with the main systems. Data-loss exposure is now limited to about 5 minutes. Ironically, both
companies had this level of redundancy in the planning stages 2 years ago and had expected to
begin implementation in October 2001.

                                 Brought to you by Symantec and Windows IT Pro eBooks
                                                             Chapter 5 Backup and Recovery Tips & Tricks 37


    I asked Hotek if he’d learned any lessons about disaster prevention from his experiences after
September 11. He said the most important lesson was that what he’d been telling his clients for years
was true—no scenario is too far-fetched to consider when preparing for disaster. As Hotek knew all
along, the factors that helped the surviving companies get back up and running were planning,
preparation, and perseverance.




                                Brought to you by Symantec and Windows IT Pro eBooks

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:9
posted:2/13/2012
language:English
pages:40