Planning for Backup and Restore

vstsuetb

January 10th, 20060 0

Creating a backup and restore plan is a critical part of any Team Foundation deployment. In order to create this plan, you need to understand the size and scope of your Team Foundation deployment, designate a person or a team of people to perform backups, determine a backup storage strategy, and consider what backup software might best meet the needs of your organization. You must also plan to test the integrity of your backups by performing trial restorations on a regular basis.

Backup Requirements and Considerations

This outlines data sources that must be backed up when backing up Team Foundation Server. Backup requires taking the server running Team Foundation Server offline for the period of time the backup takes to ensure a consistent backup. There are eight relational databases and one OLAP database that must be backed up. The NTBackup command-line utility can be used to back up Team Foundation Server computers. You must shut down and restart Internet Information Services (IIS) manually when backing up and restoring Visual Studio Team System. In addition, IIS data must be the first item you back up, and the last item you restore before restarting IIS and bringing Team Foundation Server back online.

Group Membership Information

Group membership information is stored in Active Directory Active Management (ADAM) files on the Team Foundation Server application-tier computer and requires special backup steps. You must first shut down IIS before starting the backup on the application-tier. You can then run NTBackup to back up the data in the Program FilesMicrosoft ADAMBISGSSdata folder.

Project Portal Data

Project portal data is stored in a SQL Server 2005 database on the Team Foundation Server application-tier computer and requires Windows SharePoint Service procedures to facilitate the back up. For more information on how to back up Windows SharePoint Services data, see the product documentation for Windows SharePoint Services.

Team Foundation Server Relational Databases

Team Foundation Server relational databases include work items, source code, build results, and reports. They are stored in SQL Server 2005 on the database server computer and require SQL Server backup procedures.

Team Foundation Server OLAP Database

The Team Foundation Server OLAP data warehouse is managed with SQL Server 2005 Analysis Services on the data-tier computer and requires SQL Server Analysis Services back up procedures.

Work Item Attachments

Work item attachments are stored in the file system on the data-tier computer and require you to first shut down IIS before starting the backup.

Considerations for Backing Up and Restoring Your Servers

There are several factors to consider when planning Team Foundation Server backups; such as when to schedule backups, what data to back up, and how to store the backups. Not all of the factors will lead you to the same conclusions, but a careful consideration of the whole will guide you in creating a backup plan that meets your organization’s current needs.

The most common considerations are discussed briefly below 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 creating your backup and restore plan.

Scope of Backups

Consider the servers and computers required for Team Foundation Server daily operations. You must regularly back up the data on these critical computers, including but not limited to build servers, test controllers, and Team Foundation Server. Because the Team Foundation servers will not be available while being backed up, you must also plan when to perform these backups to minimize disruption for your users. You can choose the frequency of these backups as well as the type. For example, you might choose to perform incremental backups of your application-tier and data-tier servers on a daily basis, and full backups on a weekly basis. You can also choose whether to back up just the data on these computers, or whether to back up the entire computer for easier recovery and restoration. For example, backing up the entire Team Foundation Server requires more storage space and more time, but when restoring the server you do not have to reinstall and reconfigure Team Foundation Server.

Responsibility for Backups

Consider who will be responsible for backing up your critical computers. Will it be one person or a team of people? If you are backing up critical computers after working hours, you might choose to automate your backups. If so, however, someone needs to make sure that the automated backups completed successfully. If you need to suddenly restore a server from backup, is there a way to contact these people after regular working hours? If a person is unavailable, can someone else back up or restore the data? How familiar are these people with the disaster recovery plan? Does everyone know where to find the disaster recovery plan?

Backup Storage and Retrieval

Consider how much data storage you will need and where you will store your backed up data. You should choose a media storage type that best suits your organization’s needs. You should plan on keeping at least one set of backups in an offsite location. For more information about backup storage, see Backing Up and Restoring Data (http://go.microsoft.com/fwlink?linkid=28310).

Backup Software

Consider whether you want to use the back up features of your operating system, or whether you want to invest in other backup software. You can choose to invest in integrated software and hardware backup systems. How much would a backup software solution cost your organization? How does that cost compare to the advantages of the feature set? Your backup software should provide the level of backup management that best suits the overall need of your organization.

Testing the Integrity of Backups

Consider testing the integrity of your backups on a regular basis. You should check the backup logs for any errors or events on a daily basis. If your backup software provides the option, you should run data integrity checks on your backed up data. You should also plan on practicing restorations, including restoring a server from incremental backups and restoring a server from full backups. Full scenario testing is the only way to ensure that your backups really provide the data coverage you expect.

Backing Up and Restoring Team Foundation Server Data

As a database administrator, you know that backups are required for successful recovery from data corruption or server failure. As a Team Foundation Server administrator, you must consider restoration of not only the data, but the application-tier services that use the data.

You can use backups to recover Team Foundation Server services in the following scenarios.

Data-only recovery for single server or dual server deployments If the Team Foundation data tier server becomes corrupted, you can use backups to restore the full database and the transaction logs to an uncorrupted state.
Server recovery for single server deployments If the computer fails and you have a second computer, you can set up another single server deployment and restore the full database and transaction logs.
Server recovery for a dual-server deployment If the Team Foundation data-tier server fails, you can set up another Team Foundation data-tier server and restore the full database and transaction logs.

The databases are the major component to restore. All other recovery steps configure the Team Foundation application-tier services to connect to that restored data. Typically, you restore to the original server and the services are already configured to use that server name. However, if you restore to a different server, you must perform additional configuration steps to update the services to connect to the new server.

Backing Up the Team Foundation Server

To restore your Team Foundation deployment in its entirety if a failure were to occur, Team Foundation deployment requires that you create backups for each location where data is stored. Creating backups is a key aspect of protecting your Team Foundation deployment against loss. The following list summarizes what you must back up for each tier.

Data tier The Team Foundation Server data tier includes several SQL Server databases, some of which serve the team project portal sites. You can perform database backups manually or automatically by using maintenance plans that run at a specific time or at specific intervals. Team Foundation Server, Windows SharePoint Services, and SQL Reporting Services store their data in databases in SQL Server on the data tier.

Warning Although SQL Server Management Studio allows you to back up individual databases at a time, restoring from such back ups can cause unexpected results because the databases are related and you risk restoring outdated versions.

Application tier The reporting services are located on the application tier and have an encryption key that you must back up. You can manually back up the Report Server encryption key using either the Report Services Configuration tool or a command-line tool. This key safeguards sensitive information stored in the report server database.

Note You might assume that you must back up both databases and Web sites for the team project portal pages. However, Windows SharePoint Services dynamically generates the Web sites from the databases. So when you back up the databases, the sections of the team project that you see as Web sites are backed up, too. If you have created custom site collections, site templates, or Web parts in Windows SharePoint Services but outside Team Foundation, you must back them separately. For more information, see “Backup and Restore Options for Windows SharePoint Services” in the n Windows SharePoint Services online documentation.

Advanced Preparation for Back Ups

When you deploy Team Foundation, keep a record of the accounts that you create, and any computer names, passwords, and setup options that you choose. Always keep a copy of all recovery materials, documents, and database and transaction log backups at an offsite location.

Important Perform a trial data restoration periodically to verify that your files are correctly backed up. A trial restoration can reveal hardware problems that do not appear with software verifications.

When you back up and restore a database, you must back up the data onto media, for example, tapes and disks. Your backup plan should include provisions for managing media, such as:

A tracking and management plan for storing and recycling backup sets.
A schedule for overwriting backup media.
In a multi-server environment, a decision to use either centralized or distributed backups.
A way of tracking the useful life of media.
A procedure to minimize the effects of the loss of a backup set or backup media, for example, a tape.
A decision to store backup sets onsite or offsite, and an analysis of how this might affect recovery time.

To safeguard against a disaster, such as a fire or an earthquake, keep duplicates of your server backups in a different location from the location of the servers. This will help protect you against the loss of critical data. As a best practice, keep three copies of the backup media, and keep at least one copy offsite in a properly controlled environment.

Because Team Foundation data is stored in SQL Server databases, you do not have to back up the computers on which Team Foundation clients are installed. If a media failure or disaster involving those computers were to occur, reinstalling Team Foundation provides a cleaner and more reliable alternative to restoring from a backup.

You can back up a server by using maintenance plans in Microsoft SQL Server 2005 to back up the databases related to your Team Foundation deployment. The Team Foundation Server databases work in relationship with one other and should be backed up at the same time and restored at the same time.

Full Data Backups (Databases) A full database backup is necessary for the recoverability of your deployment. A full backup includes part of the transaction log so that the full backup can be recovered. Full backups are self-contained; they represent the entire database at the time the backup completed.

Under the full database backup model, making regular backups of your transaction logs is necessary to recovering data. With transaction log backups, you can recover the database to the point of failure or to a specific point in time.

Transaction Log Backups The transaction log is a serial record of all modifications that have occurred in a database in addition to the transaction that performed each modification. The transaction log records the start of each transaction. It records the changes to the data and, if it has to, enough information to undo the modifications made during each transaction. The log grows continuously as logged operations occur in the database.

Transaction log backups let you recover the database to an earlier point in time, for example, before entering unwanted data, or to the point of a failure. Besides database backups, transaction log backups must be part of your recovery strategy.

Transaction log backups generally use fewer resources than full backups. Therefore, you can create transaction log backups more frequently than full backups, reducing your risk of losing data. However, sometimes a transaction log backup is larger than a full backup. For example, suppose a database has a high transaction rate; a high transaction rate causes the transaction log to grow quickly. In this situation, create transaction log backups more frequently.

You can perform three types of transaction log backups:

A pure log backup contains only transaction log records for an interval, without any bulk changes.
A bulk log backup includes log and data pages changed by bulk operations. Point-in-time recovery is not allowed.
A tail-log backup is taken from a possibly damaged database to capture the log records that have not yet been backed up. A tail-log backup is taken after a failure in order to prevent work loss and can contain either pure log or bulk log data.

The only time a full backup must be synchronized with transaction log backups is when you start a sequence of transaction log backups. Every sequence of transaction log backups must be preceded by a full backup or full differential backup. In SQL Server 2005, you can back up the log after the first full backup, while a full backup is running.

Backups for Services (Application Tier)

The only backup performed for the application tier is for the encryption key for the Reporting Services. You might assume that you must back up Web sites or the data warehouse. However, the SQL Server databases contain all the data including page specifications and report specifications that the services request and use to create the team portal pages and the reports.

Although you have fewer steps for backing up for the services, you have more to do during recovery on the application tier. You need to restore the portal sites for the team projects.