Bases de datos, topologías de implementación y copia de seguridad

Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

Nota

Azure DevOps Server anteriormente se denominaba Visual Studio Team Foundation Server.

Puede ayudar a proteger su implementación frente a la pérdida de datos mediante la creación de una programación periódica de copias de seguridad de las bases de datos de las que depende Azure DevOps Server. Para restaurar la implementación de Azure DevOps Server por completo, realice primero una copia de seguridad de todas las bases de datos Azure DevOps Server.

Si la implementación incluye SQL Server Reporting Services, también debe hacer una copia de seguridad de las bases de datos que Azure DevOps usa dentro de esos componentes. Para evitar errores de sincronización o de no coincidencia de datos, tiene que sincronizar todas las copias de seguridad en la misma marca de tiempo. La manera más sencilla de garantizar la sincronización correcta es usar transacciones marcadas. Al marcar rutinariamente las transacciones relacionadas en todas las bases de datos, se establece una serie de puntos de recuperación comunes en las bases de datos. Para obtener instrucciones paso a paso sobre cómo realizar una copia de seguridad de una implementación de un solo servidor que usa informes, vea crear una programación y un plan de copia de seguridad.

Si la implementación incluye SQL Server Reporting Services o productos de SharePoint, también debe hacer una copia de seguridad de las bases de datos que Azure DevOps usa dentro de esos componentes. Para evitar errores de sincronización o de no coincidencia de datos, tiene que sincronizar todas las copias de seguridad en la misma marca de tiempo. La manera más sencilla de garantizar la sincronización correcta es usar transacciones marcadas. Al marcar rutinariamente las transacciones relacionadas en todas las bases de datos, se establece una serie de puntos de recuperación comunes en las bases de datos. Para obtener instrucciones paso a paso sobre cómo realizar una copia de seguridad de una implementación de un solo servidor que usa SharePoint Foundation y que también usa informes, vea crear una programación y un plan de copia de seguridad.

Copias de seguridad de bases de datos

Proteja su implementación de DevOps de Azure contra la pérdida de datos mediante la creación de copias de seguridad de base de datos. En la tabla siguiente y en las ilustraciones complementarias se muestran las bases de datos de las que se va a realizar una copia de seguridad y se proporcionan ejemplos de cómo se podrían distribuir físicamente esas bases de datos en una implementación.

Tipo de base de datos Producto ¿Es necesario el componente?
Base de datos de configuración Azure DevOps Server
Base de datos de almacén Azure DevOps Server
Bases de datos de colección de proyectos Azure DevOps Server
Bases de datos de informes SQL Server Reporting Services No
Bases de datos de análisis SQL Server Analysis Services No
Tipo de base de datos Producto ¿Es necesario el componente?
Base de datos de configuración Azure DevOps Server
Base de datos de almacén Azure DevOps Server
Bases de datos de colección de proyectos Azure DevOps Server
Bases de datos de informes SQL Server Reporting Services No
Bases de datos de análisis SQL Server Analysis Services No
Bases de datos de productos de SharePoint Productos de SharePoint No

Topologías de implementación

En función de la configuración de su implementación, todas las bases de datos que necesiten copia de seguridad podrían estar en el mismo servidor físico, como en esta topología de ejemplo.

Nota

En este ejemplo no se incluyen Reporting Services o productos de SharePoint, por lo que no es necesario realizar una copia de seguridad de las bases de datos asociadas a informes, análisis o productos de SharePoint.

Estructura de base de datos de Azure DevOps Server simple

Como alternativa, las bases de datos podrían estar distribuidas en varios servidores y granjas de servidores. En esta topología de ejemplo, debe hacer copia de seguridad de las siguientes bases de datos, escaladas en seis servidores o granjas de servidores:

  • la base de datos de configuración

  • la base de datos de almacén

  • las bases de datos de colección de proyectos que se encuentran en el clúster de SQL Server

  • la base de datos de la colección que se encuentra en el servidor independiente que ejecuta SQL Server

  • las bases de datos que se encuentran en el servidor que está ejecutando Reporting Services

  • la base de datos que se encuentra en el servidor que está ejecutando Analysis Services

  • las bases de datos administrativas de productos de SharePoint y las bases de datos de colección de sitios para las dos aplicaciones Web de SharePoint

    Si las bases de datos de SharePoint se escalan en varios servidores, no puede usar la característica copias de seguridad programadas para realizar copias de seguridad de las mismas. Debe configurar manualmente las copias de seguridad de las bases de datos y asegurarse de que esas copias de seguridad se sincronizan con las copias de seguridad de las bases de datos de Azure DevOps Server. Para más información, consulte Realización de una copia de seguridad manual en Azure DevOps Server.

Estructura de base de datos de Azure DevOps Server compleja

En ambos ejemplos, no es necesario que haga copia de seguridad de los clientes que conectan al servidor. Sin embargo, es posible que tenga que borrar manualmente las memorias caché de Azure DevOps Server en los equipos cliente para que puedan volver a conectarse a la implementación restaurada.

Bases de datos cuya copia de seguridad se va a realizar

En la lista siguiente se proporcionan detalles adicionales sobre lo que debe hacer copia de seguridad, en función de los recursos de implementación.

Importante

Todas las bases de datos de la siguiente lista son bases de datos de SQL Server. Aunque puede usar SQL Server Management Studio para realizar copias de seguridad de bases de datos individuales en cualquier momento, debe evitar el uso de dichas copias de seguridad individuales siempre que sea posible. Puede experimentar resultados inesperados si restaura a partir de copias de seguridad individuales, ya que todas las bases de datos que Azure DevOps usa están relacionadas. Si realiza una copia de seguridad de una sola base de datos, es posible que los datos de esa base de datos no estén sincronizados con los de las otras bases de datos.

  • Bases de datos para Azure DevOps Server : la capa de datos lógica para Azure DevOps Server incluye varias bases de datos de SQL Server, como la base de datos de configuración, la base de datos de almacén y una base de datos para cada colección de proyectos de la implementación. Estas bases de datos pueden estar todas en el mismo servidor, distribuidas en varias instancias en el mismo SQL Server implementación o distribuidas en varios servidores. Independientemente de su distribución física, debe hacer copias de seguridad de todas las bases de datos en la misma marca de tiempo a fin de contar con garantías frente a la pérdida de datos. Puede realizar las copias de seguridad manual o automáticamente mediante planes de mantenimiento que se ejecuten en momentos o a intervalos específicos.

    Importante

    La lista de bases de datos de Azure DevOps no es estática. Se crea una nueva base de datos cada vez que crea una colección. Al crear una colección, asegúrese de agregar la base de datos de dicha colección al plan de mantenimiento.

  • Bases de datos para Reporting Services y Analysis Services : Si la implementación usa SQL Server Reporting Services o SQL Server Analysis Services para generar informes de Azure DevOps Server, debe realizar una copia de seguridad de las bases de datos de informes y análisis. Sin embargo, tendrá que volver a generar ciertas bases de datos tras la restauración, como el almacén.
  • Clave de cifrado para el servidor de informes : el servidor de informes tiene una clave de cifrado de la que se debe realizar una copia de seguridad. Esta clave protege información confidencial almacenada en la base de datos del servidor de informes. Puede realizar una copia de seguridad manual de esta clave mediante la herramienta de configuración de Reporting Services o una herramienta de la línea de comandos.
  • Bases de datos para productos de SharePoint : Si la implementación usa productos de SharePoint para hospedar portales de proyecto, debe realizar una copia de seguridad de varias bases de datos. Estas bases de datos incluyen la base de datos de administración para cada aplicación Web de SharePoint que la implementación usa y las bases de datos de colección de sitios que hospedan portales de proyecto. Preferiblemente, la implementación se ha configurado para usar una colección de sitios independiente para cada colección de proyectos de la implementación. Del mismo modo que se puede hacer una copia de seguridad y restaurar las colecciones de proyectos como una unidad en Azure DevOps Server, se puede realizar una copia de seguridad de las colecciones de sitios y restaurarlas en productos de SharePoint. Si una o más colecciones de su implementación están usando sitios o subsitios en lugar de colecciones de sitios como sitio de raíz, es posible que no pueda realizar copias de seguridad completas ni restaurar las colecciones. Para obtener más información, vea organizar el servidor con colecciones de proyectos.

    Nota

    Podría suponer que debe realizar una copia de seguridad de las bases de datos y los sitios web de las páginas del portal del proyecto. Sin embargo, los productos de SharePoint generan dinámicamente los sitios web a partir de las bases de datos. Por lo tanto, al realizar una copia de seguridad de las bases de datos, también se realiza una copia de seguridad de las secciones del proyecto que aparecen como sitios Web. Si ha creado colecciones de sitios personalizadas, plantillas de sitios o elementos Web en productos de SharePoint pero fuera de Azure DevOps Server, debe realizar una copia de seguridad de ellos por separado. Para obtener más información, vea copia de seguridad (SharePoint Foundation).

Preparación preliminar de las copias de seguridad

Al implementar DevOps de Azure, debe mantener un registro de las cuentas que cree y de los nombres de equipo, contraseñas y opciones de configuración que especifique. También debería conservar una copia de todos los materiales, documentos y bases de datos de recuperación, así como de las copias de seguridad del registro de transacciones, en una ubicación segura. Para protegerse frente a un desastre, como un incendio o un terremoto, debería conservar duplicados de las copias de seguridad del servidor en una ubicación distinta a la de los servidores. Esta estrategia le ayudará a protegerse frente a la pérdida de datos críticos. Como procedimiento recomendado, debería conservar tres copias de los soportes de copias de seguridad y al menos una copia fuera de las instalaciones en un entorno controlado.

Importante

Realice periódicamente una restauración de prueba de los datos para comprobar que la copia de seguridad de los archivos es correcta. Una restauración de prueba puede revelar problemas de hardware que no aparecen con una comprobación de solo software.

Cuando realiza una copia de seguridad y restaura una base de datos, debe hacer la copia de seguridad de los datos en soportes con una dirección de red (por ejemplo, cintas y discos compartidos como unidades de red). El plan de copia de seguridad debe incluir disposiciones para administrar soportes, como las siguientes tácticas:

  • Un plan de seguimiento y administración para almacenar y reciclar los conjuntos de copias de seguridad.
  • Un programa para sobrescribir los soportes de copias de seguridad.
  • En un entorno multiservidor, la decisión de utilizar copias de seguridad centralizadas o distribuidas.
  • Una manera de realizar el seguimiento de la vida útil de los soportes.
  • Un procedimiento para minimizar los efectos de la pérdida de un conjunto de copias de seguridad o de soportes de copias de seguridad (por ejemplo, una cinta).
  • La decisión de almacenar conjuntos de copias de seguridad en las instalaciones o fuera de ellas, y un análisis de cómo puede afectar esta decisión al tiempo de recuperación.

Dado que los datos de DevOps de Azure se almacenan en bases de datos de SQL Server, no es necesario realizar copias de seguridad de los equipos en los que están instalados los clientes de Azure DevOps. Si se produjera un error o desastre multimedia que implicara a esos equipos, puede volver a instalar el software cliente y volver a conectarse al servidor. Al volver a instalar el software cliente, los usuarios tendrán una alternativa más limpia y confiable para restaurar un equipo cliente desde una copia de seguridad.

Puede realizar una copia de seguridad de un servidor mediante las características copias de seguridad programadas disponibles o creando manualmente planes de mantenimiento en SQL Server para realizar copias de seguridad de las bases de datos relacionadas con la implementación de Azure DevOps. Las bases de datos de Azure DevOps funcionan en relación con otra y, si crea un plan manual, debe realizar una copia de seguridad de ellos y restaurarlos al mismo tiempo. Para obtener más información sobre las estrategias para realizar copias de seguridad de bases de datos, vea copia de seguridad y restauración de basesde datos de SQL Server.

Tipos de copias de seguridad

Comprender los tipos de copias de seguridad disponibles le ayuda a determinar las mejores opciones para realizar copias de seguridad de la implementación. Por ejemplo, si trabaja con una implementación de gran tamaño y desea protegerse frente a la pérdida de datos a la vez que usar eficazmente los recursos de almacenamiento limitado, puede configurar copias de seguridad diferenciales y copias de seguridad de todos los datos. Si usa SQL Server AlwaysOn, puede realizar copias de seguridad de la base de datos secundaria. También puede probar a usar la comprensión de copias de seguridad o la división de estas en varios archivos. A continuación se incluye una breve descripción de cada una de las opciones de copia de seguridad:

Copias de seguridad completas (bases de datos)

Se necesita una copia de seguridad completa de la base de datos para la recuperación de la implementación. Una copia de seguridad completa incluye parte del registro de transacciones para que se pueda recuperar la copia de seguridad completa. Las copias de seguridad completas son autónomas, ya que representan la base de datos completa tal como era al hacer la copia de seguridad. Para obtener más información, vea copias de seguridad completas de bases de datos.

Copias de seguridad diferenciales (bases de datos)

Una copia de seguridad diferencial solo registra los datos que han cambiado desde la última copia de seguridad completa de la base de datos, que se denomina base diferencial. Las copias de seguridad diferenciales son más pequeñas y rápidas que las copias de seguridad completas. Esta opción ahorra tiempo a costa de una mayor complejidad. En las bases de datos grandes, las copias de seguridad diferenciales se pueden realizar a intervalos más cortos que las copias de seguridad completas, lo que reduce el riesgo de pérdidas de trabajo. Para obtener más información, vea copias de seguridad diferenciales de bases de datos.

También debería hacer copias de seguridad de sus registros de transacciones con regularidad. Estas copias de seguridad son necesarias para recuperar los datos al utilizar el modelo de copias de seguridad completas de bases de datos. Si realiza una copia de seguridad de los registros de transacciones, puede recuperar la base de datos hasta el momento del error o hasta un momento anterior.

Copias de seguridad del registro de transacciones

El registro de transacciones es un registro en serie de todas las modificaciones que se han producido en una base de datos además de la transacción que realizó cada modificación. El registro de transacciones registra el inicio de cada transacción, los cambios efectuados en los datos y, si fuera necesario, información suficiente para deshacer las modificaciones realizadas durante esa transacción. El registro crece continuamente al ir registrándose operaciones en la base de datos.

Al realizar copias de seguridad de los registro de transacciones, puede recuperar la base de datos en un momento anterior en el tiempo. Por ejemplo, puede restaurar la base de datos a un punto anterior a la entrada de datos no deseados o a un error. Además de las copias de seguridad de la base de datos, las copias de seguridad del registro de transacciones deben formar parte de su estrategia de recuperación. Para obtener más información, vea copias de seguridad de registros de transacciones (SQL Server).

Las copias de seguridad del registro de transacciones utilizan generalmente menos recursos que las copias de seguridad completas. Por consiguiente, puede crear copias de seguridad del registro de transacciones con más frecuencia que copias de seguridad completas, lo que reduce el riesgo de pérdida de datos. Sin embargo, a veces una copia de seguridad del registro de transacciones es mayor que una copia de seguridad completa. Por ejemplo, una base de datos con una tasa de transacciones alta hace que el registro de transacciones crezca rápidamente. En este caso, debería crear copias de seguridad del registro de transacciones más a menudo. Para obtener más información, vea solucionar problemas de un registro de transacciones lleno (Error 9002 de SQL Server).

Puede realizar los siguientes tipos de copias de seguridad del registro de transacciones:

  • Una copia de seguridad pura del registro sólo contiene registros del registro de transacciones para un intervalo, sin ningún cambio masivo.
  • Una copia de seguridad masiva del registro incluye el registro y las páginas de datos cambiadas por operaciones masivas. No es posible la recuperación a un momento dado en el tiempo.
  • Se toma una copia de seguridad del registro de cola de una base de datos posiblemente dañada para capturar los registros del registro de los que no se ha hecho aún una copia de seguridad. Una copia de seguridad del registro de cola se toma después de un error para evitar la pérdida de trabajo; esta copia puede contener datos de un registro puro o de un registro masivo.

Dado que la sincronización de datos es fundamental para una correcta restauración de Azure DevOps Server, debe usar transacciones marcadas como parte de la estrategia de copia de seguridad si va a configurar las copias de seguridad manualmente. Para obtener más información, vea crear una programación de copia de seguridad y planear y realizar una copia de seguridad manual Azure DevOps Server.

Copias de seguridad del servicio de capa de aplicación

La única copia de seguridad necesaria para la capa de aplicación lógica es para la clave de cifrado de Reporting Services. Si usa la característica Copias de seguridad programadas para hacer copias de seguridad de la implementación, se creará una copia de seguridad de dicha clave como parte del plan. Podría suponer que debe realizar copias de seguridad de sitios web usados como portales de proyecto.

Si ha integrado productos de SharePoint como parte de la implementación de Azure DevOps Server, se realizará una copia de seguridad de los portales como parte de la copia de seguridad de las bases de datos de Azure DevOps Server y productos de SharePoint. Sin embargo, si ha especificado un sitio web que no se creó mediante una aplicación web integrada, debe realizar copias de seguridad y restaurar esos sitios manualmente. Además, si tiene personalizaciones en productos de SharePoint o servicios, también debe hacer una copia de seguridad de ellas o registrarlas de otro modo para que se puedan reproducir en un nuevo servidor.

Aunque puede realizar una copia de seguridad de una capa de aplicación más fácilmente que una capa de datos, todavía hay varios pasos para restaurar una capa de aplicación. Debe instalar otra capa de aplicación para Azure DevOps Server, redirigir las colecciones de proyectos para que usen la nueva capa de aplicación y redirigir los sitios de portal para los proyectos.

Nombres de bases de datos predeterminadas

Si no personaliza los nombres de las bases de datos, puede utilizar la siguiente tabla para identificar las bases de datos utilizadas en la implementación de Azure DevOps Server. Como se mencionó anteriormente, no todas las implementaciones tienen todas estas bases de datos. Por ejemplo, si no configuró Azure DevOps Server con Reporting Services, no tendrá las bases de datos ReportServer o ReportServerTempDB. Del mismo modo, no tendrá la base de datos de System Center Virtual Machine Manager (SCVMM), VirtualManagerDB, a menos que configure Azure DevOps Server para admitir Lab Management. Además, las bases de datos que usa Azure DevOps Server pueden estar distribuidas en más de una instancia de SQL Server o en más de un servidor.

Nota

De forma predeterminada, el prefijo TFS_ se agrega a los nombres de las bases de datos que se crean automáticamente al instalar Azure DevOps Server o mientras está funcionando.

Base de datos Descripción
TFS_Configuration La base de datos de configuración para Azure DevOps Server contiene el catálogo, los nombres de servidor y los datos de configuración de la implementación. El nombre de esta base de datos podría incluir caracteres adicionales entre TFS_ y la configuración, como el nombre de usuario de la persona que instaló Azure DevOps Server. Por ejemplo, el nombre de la base de datos podría ser TFS_UserNameConfiguration
TFS_Warehouse La base de datos de configuración contiene los datos para compilar el almacén que emplea Reporting Services. El nombre de esta base de datos podría incluir caracteres adicionales entre TFS_ y Warehouse, como el nombre de usuario de la persona que instaló Azure DevOps Server. Por ejemplo, el nombre de la base de datos podría ser TFS_UserNameWarehouse.
TFS_CollectionName La base de datos de una colección de proyectos contiene todos los datos de los proyectos de esa colección. Estos datos incluyen código fuente, configuraciones de compilación y configuraciones de Lab Management. El número de bases de datos de colección será igual que el número de colecciones. Por ejemplo, si tiene tres colecciones en su implementación, debe hacer una copia de seguridad de estas tres bases de datos de colección. El nombre de cada base de datos podría incluir caracteres adicionales entre TFS_ y CollectionName, como el nombre de usuario de la persona que creó la colección. Por ejemplo, el nombre de una base de datos de colección podría ser TFS_UserNameCollectionName.
TFS_Analysis La base de datos de SQL Server Analysis Services contiene los orígenes de datos y los cubos para la implementación de Azure DevOps Server. El nombre de esta base de datos podría incluir caracteres adicionales entre TFS_ y el análisis, como el nombre de usuario de la persona que instaló Analysis Services. Por ejemplo, el nombre de la base de datos podría ser TFS_UserNameAnalysis.
Nota: puede hacer una copia de seguridad de esta base de datos, pero debe recompilar el almacén desde la base de datos de TFS_Warehouse restaurada.
ReportServer La base de datos de Reporting Services contiene los informes y la configuración de informes para la implementación de Azure DevOps Server.
Nota: si Reporting Services está instalado en un servidor independiente de Azure DevOps Server, es posible que esta base de datos no esté presente en el servidor de capa de datos para Azure DevOps Server. En ese caso, debe configurar, realizar una copia de seguridad y restaurarlo por separado de Azure DevOps Server. Debe sincronizar el mantenimiento de las bases de datos para evitar errores de sincronización.
ReportServerTempDB La base de datos temporal de Reporting Services almacena información de forma temporal cuando se ejecutan informes concretos.
Nota: si Reporting Services está instalado en un servidor independiente que Azure DevOps Server, es posible que esta base de datos no esté presente en el servidor de capa de datos para Azure DevOps Server. En este caso, debe configurar, realizar una copia de seguridad y restaurarlo por separado de Azure DevOps Server. Sin embargo, debe sincronizar el mantenimiento de las bases de datos para evitar errores de sincronización.
VirtualManagerDB La base de datos de administración de SCVMM contiene la información que ve en la Consola de administrador de SCVMM, como máquinas virtuales, hosts de máquina virtual, servidores de biblioteca de máquinas virtuales y sus propiedades.
Nota: si SCVMM se instala en un servidor independiente que Azure DevOps Server, es posible que esta base de datos no esté presente en el servidor de capa de datos para Azure DevOps Server. En ese caso, debe configurar, realizar una copia de seguridad y restaurarlo por separado de Azure DevOps Server. Sin embargo, debe utilizar transacciones marcadas y sincronizar el mantenimiento de las bases de datos para evitar errores de sincronización.

Nombres de base de datos predeterminada de productos de SharePoint

Nota

No debe utilizar transacciones marcadas si realiza una copia de seguridad o restauraciones manuales de las bases de datos que utiliza SharePoint Products. Sin embargo, para ayudar a evitar errores de sincronización, debe intentar sincronizar las programaciones de copia de seguridad y restauración de los productos y Azure DevOps Server de SharePoint. Para obtener más información, vea crear un plan de copia de seguridad para SharePoint Foundation.

Base de datos Descripción
WSS_Config La base de datos de configuración para productos de SharePoint contiene una lista de todos los sitios, como las bases de datos de contenido, las plantillas de sitio, los elementos Web personalizados y otras opciones de configuración de administración central de SharePoint.
WSS_Content La base de datos de contenido para productos de SharePoint contiene el contenido real de los portales del proyecto.
Nota: el nombre de esta base de datos variará en función de la versión de productos de SharePoint que esté instalada y de si la persona que la instaló personalizó el nombre.
WSS_AdminContent La base de datos de administración de productos de SharePoint contiene la información de seguridad para los usuarios, los roles y las bases de datos.