Advanced Preparation for Backups
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.
.gif) Important Note: |
|---|
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 SQL Server 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 the following resources on the Microsoft Web site:
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 when the backup completed. For more information, see "Full Database Backups" for either SQL Server 2005 or SQL Server 2008 on the Microsoft Web site.
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.
By creating transaction log backups, you can recover the database to an earlier point in time. For example, you can restore the database to a point before unwanted data was entered 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" for either SQL Server 2005 or SQL Server 2008 on the Microsoft Web site.
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" for either SQL Server 2005 or SQL Server 2008 on the Microsoft Web site.
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, 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" for either SQL Server 2005 or SQL Server 2008 on the Microsoft Web site.