|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Planning for Disaster Recovery
Planning ahead is important for effective disaster recovery of a Team Foundation deployment. You should understand the size and scope of your Team Foundation deployment, know the maintenance and backup schedule for Team Foundation Server, and create a disaster recovery plan. You should also consider simulating a disaster recovery situation and step through your plan in order to test the effectiveness of your disaster recovery strategy.
Considerations for Disaster Recovery
In order to plan for disaster recovery, you must consider several factors, such as who will be responsible for initiating disaster recovery procedures, what servers and hardware are critical for your Team Foundation deployment, the frequency and scope of backups and where they are stored, and what the affect of Team Foundation Server unavailability will be on your organization. Not all the factors will lead you to the same conclusions, but a careful consideration of the whole will guide you in creating a disaster recovery plan that meets your organization's current needs.
The most common considerations are discussed briefly in the following sections and are intended as general guidelines to help you through the planning process. You might have additional factors you want to consider; such as clustering, offsite data storage, or mirrored servers. Remember to account for the unique features of your Team Foundation deployment when you are creating your disaster recovery plan.
Responsibility for Disaster Recovery
Consider who will be responsible for disaster recovery. Will it be one person or a team of people? How will these people be contacted? Is there a way to contact these people after regular working hours? If a person is unavailable, can someone else perform that person's tasks? How familiar are these people with the disaster recovery plan? Does everyone know where to find the disaster recovery plan? For more information, see.
Consider the hardware that is required for Team Foundation Server daily operations. Do you know what computers are critical? Do you have a list of server names and specifications? Do you restrict physical access to this critical hardware? You will have to regularly manage and maintain this critical hardware that includes controlling server access and performing regular maintenance on mission-critical components.
Backup Storage and Retrieval
Consider the frequency of Team Foundation Server backups and where those backups are stored. How frequently are the Team Foundation servers backed up? Are there incremental backups in addition to full backups? Do the users have files checked out to their local workspaces? Understanding the current state of your Team Foundation Server data is important when determining your restore point and the affect it will have on the users. For more information about backing up and restoring Team Foundation Server, seeand .
Mitigating Disaster Impact
Consider whether it might be cost-effective for your organization to mirror or cluster your Team Foundation servers and other mission-critical computers. How much would it cost your organization to mirror your Team Foundation servers? How does that cost compare to the potential cost of productivity if Team Foundation Server is unavailable to the users for a day or longer? For example, if you have a dual-server Team Foundation Server deployment and your data-tier server experiences a hard disk controller failure, you could redirect your application-tier server to a mirrored data-tier server that has minimal affect to the users. Is the cost of maintaining a mirrored server fiscally justifiable? You should provide the level of fault tolerance that best suits the overall need of your organization. For more information about fault tolerance and server availability, see.