Backing Up the Team Foundation Server

  • Article

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. For more information about strategies for backing up databases, see Choosing the Recovery Model for a Database.

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. For more information, see Full Database Backups.

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. For more information, see Working with Transaction Log Backups.

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. For more information, see Troubleshooting a Full Transaction Log (Error 9002).

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. For information about how to create log backups, see Creating Transaction Log Backups.

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.

In This Section

See Also

Tasks

How to: Back Up a Team Foundation Server

Concepts

Planning for Backup and Restore

Other Resources

Backing Up and Restoring Team Foundation Server Data
Full Database Backups
Working with Transaction Log Backups
Creating Transaction Log Backups