When it comes to disaster-recovery planning, what constitutes a disaster? The answer might seem obvious, but you'd probably have a hard time identifying everything that you could construe a disaster. Natural disasters such as fires, earthquakes, and floods are easy to identify, but a disaster can also result from unusual circumstances. For example, I live in the Washington, DC area, and I've met dozens of individuals whose business productivity during the past 2 years has been affected because of quarantines and evacuations related to the threat of terrorist attacks, biological warfare, or criminal activity. Clearly, these types of circumstances are situations that most IT administrators might overlook when planning for a disaster.
After talking with people who've faced these situations, I developed my own definition of a disaster: Any event that keeps business users away from business data for an unacceptable length of time (sometimes permanently), thereby putting the viability of the organization at risk. I'll admit that my definition can be overly broad—even a simple situation such as a failed hard disk might meet those criteria. However, depending on the quantity and the type of data affected and the probability of being able to recover that information in a timely fashion (if at all), some organizations might easily consider a hard disk failure to be a disaster. To help you better design solutions for disaster recovery, you should begin thinking about disaster-recovery planning as a means to minimize the amount of time that your users are separated from business data, regardless of the circumstances. Let's look at a sample disaster scenario to see how Microsoft Dfs can play a part in your disaster-recovery plan and help you minimize the time you spend reconnecting users to certain types of data.
Preparing for Disaster
Imagine that your chief information officer (CIO) has asked you to develop a disaster-recovery plan (or, its newer, hipper cousin, the business continuity plan) for your organization to use in the event of a catastrophe. Your company has offices in New York and London, and the IT infrastructure between those locations consists of servers, desktops, routers, and switches. This infrastructure provides the foundation for several applications in your organization, including collaborative applications (e.g., email), vertical line of business (LOB) applications, enterprise resource planning (ERP) applications, database applications, and file storage. Given that terrorists have targeted both locations during the past decade, your CIO has asked you to plan for the worst—the loss of one of the offices for an indefinite time period.
A comprehensive disaster-recovery plan clearly will need to cover many areas to ensure business continuity through such a catastrophe. One of the most important items to consider is making the data from the impaired office available to staff members in the remaining office as soon as possible. Handing off this information lets the staff members at the remaining office carry the load and keep the business running while new facilities for the affected office are brought online.
The types of data in use in the organization typically consist of documents and files, database data, and custom-application data stores. Through the use of Dfs, you can make the first data category (i.e., documents and files) highly available during a disaster. With a bit of careful planning and minimal ongoing effort, Windows 2000 can store your data in multiple locations and make sure it's always up-to-date.
A Dfs Primer
Dfs is a core part of Win2K, but the name is misleading. Dfs isn't a true file system like NTFS or FAT, nor is it a means of organizing the way you store data on a magnetic or optical storage device. Rather, Dfs is a mechanism for organizing the way you present shared data to users, and (optionally) keeping replicated copies in multiple locations.
In a nutshell, Dfs lets you build virtual file shares on your network and point those shares to physical file shares, possibly across multiple servers. End users can connect to these virtual file shares as if they were connecting to physical file shares. When users connect to these virtual file shares, Dfs directs them to a copy of the data that's available in their location or to any one of several replicated copies available on the network.
The plumbing behind this magic is known as the File Replication Service (FRS). The FRS is built into Win2K and doesn't require any setup (Dfs is the only component that I discuss that you must configure). Let's look at a sample Dfs configuration suitable for disaster-recovery purposes.
Prev. page
[1]
2
3
4
next page 
