了解备份 Team Foundation Server
通过为 Visual Studio Team Foundation Server 所依赖的数据库创建定期备份计划，可以帮助防止部署丢失数据。 若要在发生故障时完全还原 Team Foundation 的部署，必须先备份 Team Foundation Server 的所有数据库。 如果部署包括 SharePoint 产品或 SQL Server Reporting Services，则还必须备份 Team Foundation Server 在这些组件中使用的数据库。 必须将所有备份同步到同一时间戳，以防止出现同步错误或数据不匹配错误。 确保同步的最简单方法是使用标记的事务。 通过在每个 Team Foundation 数据库中定期标记相关事务，可在数据库中建立一系列公用恢复点。
备份数据库
可以创建 Team Foundation Server 使用的数据库的备份，以作为防止 Team Foundation 部署丢失的重要措施。 下表及随附的插图显示了必须备份的数据库，并提供这些数据库在部署中的物理分布方式的示例。
数据库类型 |
产品 |
是否为可选组件？ |
|---|---|---|
配置数据库 |
Team Foundation Server |
否 |
仓库数据库 |
Team Foundation Server |
否 |
团队项目集合数据库 |
Team Foundation Server |
否 |
SharePoint 产品数据库 |
SharePoint 产品 |
是 |
报告数据库 |
SQL Server Reporting Services |
是 |
分析数据库 |
SQL Server Analysis Services |
是 |
部署拓扑
根据部署配置，需要备份的所有数据库可能位于同一物理服务器上，如此示例拓扑所示。 此示例不包括 SharePoint 产品或 Reporting Services，因此您不必备份与报告、分析或 SharePoint 产品相关联的任何数据库。
.png "简单数据库拓扑")
或者，这些数据库也可能分布在许多服务器和服务器场上。 在此示例拓扑中，您必须备份六台服务器或六个服务器场上的以下数据库：
配置数据库
仓库数据库
位于 SQL Server 群集上的团队项目集合数据库
位于运行 SQL Server 的独立服务器上的集合数据库
SharePoint Web 应用程序的 SharePoint 产品管理数据库和网站集数据库
位于运行 Reporting Services 的服务器上的数据库
位于运行 Analysis Services 的服务器上的数据库
.png "示例：数据库的复杂分发")
在这两个示例中，您不必备份连接到服务器的任何客户端。 然而，您可能需要在客户端计算机上手动清除 Team Foundation Server 的缓存，客户端计算机才能链接到还原的部署。
要备份的数据库
下面的列表提供有关必须备份的数据库的其他详细信息，具体取决于部署资源。
警告
下面的列表中的所有数据库都是 SQL Server 数据库。 尽管您可以使用 SQL Server Management Studio 随时备份各个数据库，但应尽量避免使用此类个别备份。如果从个别备份还原，则可能会遇到意外结果，这是因为 Team Foundation Server 使用的数据库全都相关。 如果仅备份一个数据库，则该数据库中的数据将与其他数据库中的数据不同步。
Team Foundation Server 的数据库 Team Foundation Server 的逻辑数据层包括若干 SQL Server 数据库，其中包括配置数据库、仓库数据库以及部署中每个团队项目集合的数据库。 这些数据库可能位于同一台服务器上、分布在同一 SQL Server 部署中的若干实例上或是分布在多台服务器上。 无论其物理分布如何，您都必须将所有数据库备份到同一时间戳，以帮助确保防止数据丢失。 可手动执行数据库备份，也可使用按特定时间或时间间隔运行的维护计划来自动执行备份。
警告
Team Foundation Server 的数据库列表不是静态的。 每次创建集合时都会创建新数据库。 创建某个集合时，请确保将该集合的数据库添加到用于备份 SQL Server 中的 Team Foundation Server 数据库的维护计划中。
SharePoint 产品的数据库 如果部署使用 SharePoint 产品承载团队项目门户网站，则您必须备份多个数据库。 这些数据库包括部署使用的每个 SharePoint Web 应用程序的管理数据库以及承载团队项目门户网站的网站集数据库。理想情况下，部署已配置为对部署中的每个团队项目集合使用单独的网站集。 就像团队项目集合可以作为 Team Foundation Server 中的单元进行备份和还原一样，网站集可以在 SharePoint 产品中进行备份和还原。 如果部署中的一个或多个集合使用站点或子站点（而非网站集）作为其根站点，则您可能无法完全备份和还原这些集合。 有关更多信息，请参见使用团队项目集合组织服务器。
提示
您可能认为必须备份团队项目门户网站页的数据库和网站。 但是，SharePoint 产品从数据库动态生成网站。 因此在备份数据库时，还会备份团队项目中显示为网站的那些部分。 如果在 SharePoint 产品内但在 Team Foundation 外创建了自定义站点集、站点模板或 Web 部件，则必须单独备份它们。 有关更多信息，请参见 Microsoft 网站上的以下页面：Choose backup and recovery tools (Windows SharePoint Services)（选择备份和还原工具 (Windows SharePoint Services)）。
**Reporting Services 和 Analysis Services 的数据库 **如果部署使用 SQL Server Reporting Services 或 SQL Server Analysis Services 为 Team Foundation Server 生成报表，则必须备份报告数据库和分析数据库。 然而，您仍必须在还原之后重新生成某些数据库。
报表服务器的加密密钥 报表服务器具有一个加密密钥，您必须备份该密钥。 此密钥保护存储在报表服务器数据库中的敏感信息。 可使用 Reporting Services 配置工具或命令行工具来手动备份此密钥。 有关更多信息，请参见备份 Reporting Services 加密密钥。
备份的事先准备
部署 Team Foundation 时，应记录所创建的帐户以及所指定的任何计算机名称、密码和设置选项。 还应在安全的位置保留所有恢复资料、文档以及数据库和事务日志备份的副本。 为了预防灾难（例如火灾或地震）的发生，应将服务器备份的副本存放在服务器位置之外的其他位置上。 此策略将有助于防止丢失关键数据。 最佳做法是保存三份备份媒体副本，应至少将其中一份副本保存在远离现场的受控环境中。
.gif "重要说明") 重要事项 |
|---|
定期执行试验性数据还原，以验证您的文件是否已正确备份。 试验性还原可以发现软件验证所不能发现的硬件问题。 |
备份和还原数据库时，必须将数据备份到媒体上（例如磁带和磁盘）。 您的备份计划中应包括管理媒体的规定，例如下列策略：
存储和回收备份集的跟踪和管理计划。
覆盖备份媒体的时间表。
在多服务器环境中，决定是使用集中备份还是使用分布式备份。
跟踪媒体的可用生命周期的方法。
将丢失备份集或备份媒体（例如磁带）的影响降低到最小的步骤。
决定是现场存储备份集还是远离现场存储备份集，并分析此决定对恢复时间有何影响。
因为 Team Foundation 数据存储在 SQL Server 数据库中，所以不必备份安装了 Team Foundation 客户端的计算机。 如果出现涉及到这些计算机的媒体故障或灾难，则可以重新安装客户端软件并重新连接到服务器。 通过重新安装客户端软件，您的用户可具有更加整洁且更加可靠的方法，以替代从备份还原客户端计算机。
通过在 SQL Server 中使用维护计划来备份与 Team Foundation 部署相关的数据库，可以备份服务器。 Team Foundation Server 数据库相互关联，因此应同时备份和还原这些数据库。 有关备份数据库的策略的更多信息，请参见 Microsoft 网站上的以下页面：Introduction to Backup and Restore Strategies in SQL Server（SQL Server 中的备份和还原策略简介）。
备份类型
完全数据备份（数据库） 为了部署的可恢复性，有必要进行完全数据库备份。 完全备份包括一部分事务日志，以便可以恢复完全备份。 完全备份是独立的，这是因为这些备份表示整个数据库在备份时的情况。 有关更多信息，请参见 Microsoft 网站上的以下页面：Full Database Backups（完全数据库备份）。
差异数据备份（数据库） 差异数据库备份仅记录自上次完全数据库备份（称为差异基准）以来发生更改的数据。 与完全数据库备份相比，差异数据库备份体积更小，速度也更快。 此选项可节省备份时间，但会以增加复杂性为代价。 对于大型数据库，进行差异备份的间隔可以比数据库备份更短，从而可降低丢失工作的可能性。 有关更多信息，请参见 Microsoft 网站上的以下页面：Full Database Backups（完全数据库备份）。
还应定期备份事务日志。 使用完全数据库备份模型时，恢复数据需要这些备份。 如果备份事务日志，则可以将数据库恢复到故障时间点或其他特定时间点。
事务日志备份 在事务日志中连续记录数据库中发生的所有修改以及执行每次修改的事务。 事务日志记录每个事务的启动、数据更改，必要时还记录用于撤消在该事务中所做修改的足够信息。 随着数据库中记录的操作的增多，日志也不断增大。
通过备份事务日志，可以将数据库恢复到以前的某个时间点。 例如，可以将数据库还原到输入不需要的数据之前的某个时间点，或是还原到某个故障时间点。 除数据库备份之外，恢复策略也必须包括事务日志备份。 有关更多信息，请参见 Microsoft 网站上的以下页面：Working with Transaction Log Backups（使用事务日志备份）。
事务日志备份所使用的资源通常比完全备份少。 因此，创建事务日志备份可以比创建完全备份更加频繁，从而降低丢失数据的风险。 不过，有时事务日志备份要比完全备份还大。 例如，数据库可能具有很高的事务比率，从而导致事务日志迅速增大。 在这种情况下，应更加频繁地创建事务日志备份。 有关更多信息，请参见 Microsoft 网站上的以下页面：Troubleshooting a Full Transaction Log（解决事务日志已满的问题）。
可执行以下类型的事务日志备份：
纯日志备份只包含某个时间段的事务日志记录，不包括任何批量更改。
批量日志备份包含由批量操作更改的日志和数据页。 不允许执行时间点恢复。
尾日志备份是从可能损坏的数据库中提取出来的，以捕获尚未备份的日志记录。 在发生故障后提取尾日志备份，以防止工作丢失，该备份中可以包含纯日志数据也可以包含批量日志数据。
因为数据同步对于 Team Foundation Server 的成功还原至关重要，所以您应将标记的事务用作备份策略的一部分。 有关更多信息，请参见备份 Team Foundation Server。
服务备份（应用层）
必须对逻辑应用层执行的唯一备份是 Reporting Services 的加密密钥。 您可能认为必须备份用作团队项目门户网站的网站。 如果您将 SharePoint 产品集成为 Team Foundation Server 部署的一部分，则这些门户网站会作为 Team Foundation Server 和 SharePoint 产品数据库备份的一部分进行备份。 但是，如果您指定的网站不是使用集成的 Web 应用程序创建的，则您必须手动备份和还原这些站点。 另外，如果具有对 SharePoint 产品或服务的任何自定义，则还必须备份这些自定义，或用其他方法记录这些自定义以便可以在新服务器上进行重现。
尽管备份应用层比备份数据层更加容易，但在还原应用层时必须执行许多步骤。 必须为 Team Foundation 安装其他应用层、重定向团队项目集合以使用新的应用层并重定向团队项目的门户网站。