Bases de datos, topologías de implementación y copia de seguridad
Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019
Puede ayudar a proteger la implementación frente a la pérdida de datos mediante la creación de una programación regular de copias de seguridad para las bases de datos de las que depende Azure DevOps Server. Para restaurar completamente la implementación de Azure DevOps Server, primero realice una copia de seguridad de todas las bases de datos de Azure DevOps Server.
Si la implementación incluye SQL Server Reporting Services, también debe realizar una copia de seguridad de las bases de datos que Azure DevOps usa en esos componentes. Para evitar errores de sincronización o errores de coincidencia de datos, debe sincronizar todas las copias de seguridad con la misma marca de tiempo. La manera más fácil de garantizar la sincronización correcta es mediante transacciones marcadas. Al marcar periódicamente las transacciones relacionadas en cada base de datos, se establece una serie de puntos de recuperación comunes en las bases de datos. Para obtener instrucciones paso a paso para realizar copias de seguridad de una implementación de servidor único que usa informes, consulte Creación de una programación y un plan de copia de seguridad.
Copias de seguridad de bases de datos
Proteja la implementación de Azure DevOps contra la pérdida de datos mediante la creación de copias de seguridad de base de datos. En la tabla siguiente y 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 esas bases de datos se pueden distribuir físicamente en una implementación.
| Tipo de base de datos | Producto | ¿Componente requerido? |
|---|---|---|
| Base de datos de configuración | Azure DevOps Server | Sí |
| Base de datos de almacenamiento | Azure DevOps Server | Sí |
| Bases de datos de colecciones de proyectos | Azure DevOps Server | Sí |
| Bases de datos de informes | SQL Server Reporting Services | No |
| Bases de datos de análisis | SQL Server Analysis Services | No |
Topologías de implementación
En función de la configuración de implementación, todas las bases de datos que requieren 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 ni Productos de SharePoint, por lo que no es necesario realizar copias de seguridad de ninguna base de datos asociada a informes, análisis o Productos de SharePoint.
Como alternativa, las bases de datos se pueden distribuir entre muchos servidores y granjas de servidores. En esta topología de ejemplo, debe realizar una copia de seguridad de las siguientes bases de datos, que se escalan entre seis servidores o granjas de servidores:
la base de datos de configuración
la base de datos de almacenamiento
las bases de datos de colección de proyectos que se encuentran en el clúster de SQL Server
la base de datos de recopilación que se encuentra en el servidor independiente que ejecuta SQL Server.
las bases de datos que se encuentran en el servidor que ejecuta Reporting Services
la base de datos que se encuentra en el servidor que ejecuta Analysis Services
las bases de datos administrativas productos de SharePoint y las bases de datos de la colección de sitios para las 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. Debe configurar manualmente las copias de seguridad de esas bases de datos y asegurarse de que esas copias de seguridad se sincronizan con las copias de seguridad de base de datos de Azure DevOps Server. Para más información, consulte Realización de una copia de seguridad manual en Azure DevOps Server.
En ambos ejemplos, no es necesario realizar una copia de seguridad de ninguno de los clientes que se conectan al servidor. Sin embargo, es posible que tenga que borrar manualmente las memorias caché de Azure DevOps Server en los equipos cliente para poder volver a conectarse a la implementación restaurada.
Bases de datos de las que se va a realizar una copia de seguridad
En la lista siguiente se proporcionan detalles adicionales sobre lo que debe realizar una copia de seguridad, en función de los recursos de implementación.
Importante
Todas las bases de datos de la lista siguiente 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 estas copias de seguridad individuales siempre que sea posible. Es posible que experimente resultados inesperados si restaura desde copias de seguridad individuales porque todas las bases de datos que usa Azure DevOps están relacionadas. Si solo realiza una copia de seguridad de una base de datos, es posible que los datos de esa base de datos no se sincronicen con los datos de las otras bases de datos.
- Bases de datos para Azure DevOps Server : el nivel de datos lógico 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 almacenamiento y una base de datos para cada colección de proyectos de la implementación. Estas bases de datos pueden estar en el mismo servidor, distribuirse entre varias instancias de la misma implementación de SQL Server o distribuirlas entre varios servidores. Independientemente de su distribución física, debe realizar una copia de seguridad de todas las bases de datos en la misma marca de tiempo para ayudar a garantizar la pérdida de datos. Puede realizar copias de seguridad de base de datos de forma manual o automática mediante planes de mantenimiento que se ejecutan en momentos o intervalos específicos.
Importante
La lista de bases de datos de Azure DevOps no es estática. Cada vez que se crea una colección, se crea una nueva base de datos. Al crear una colección, asegúrese de agregar la base de datos de esa 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 para Azure DevOps Server, debe realizar una copia de seguridad de las bases de datos de informes y análisis. Sin embargo, debe volver a generar determinadas bases de datos después de la restauración, como el almacenamiento.
- Clave de cifrado para el servidor de informes : el servidor de informes tiene una clave de cifrado de la que debe realizar una copia de seguridad. Esta clave protege la 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 línea de comandos.
Preparación avanzada para copias de seguridad
Al implementar Azure DevOps, debe mantener un registro de las cuentas que cree y cualquier nombre de equipo, contraseñas y opciones de configuración que especifique. También debe conservar una copia de todos los materiales de recuperación, documentos y copias de seguridad del registro de transacciones y bases de datos en una ubicación segura. Para proteger contra un desastre, como un incendio o un terremoto, debe mantener duplicados de las copias de seguridad del servidor en una ubicación diferente de la ubicación de los servidores. Esta estrategia le ayudará a protegerse frente a la pérdida de datos críticos. Como procedimiento recomendado, debe conservar tres copias del medio de copia de seguridad y debe mantener al menos una copia fuera del sitio en un entorno controlado.
Importante
Realice una restauración de datos de prueba periódicamente para comprobar que los archivos están correctamente respaldados. Una restauración de prueba puede revelar problemas de hardware que no aparecen con una comprobación solo de software.
Al realizar una copia de seguridad y restaurar una base de datos, debe realizar una copia de seguridad de los datos en medios con una dirección de red (por ejemplo, cintas y discos que se han compartido como unidades de red). El plan de copia de seguridad debe incluir disposiciones para administrar medios, como las siguientes tácticas:
- Un plan de seguimiento y administración para almacenar y reciclar conjuntos de copia de seguridad.
- Programación para sobrescribir medios de copia de seguridad.
- En un entorno de varios servidores, una decisión de usar copias de seguridad centralizadas o distribuidas.
- Una forma de realizar un seguimiento de la vida útil de los medios de comunicación.
- Procedimiento para minimizar los efectos de la pérdida de un conjunto de copia de seguridad o un medio de copia de seguridad (por ejemplo, una cinta).
- Decisión de almacenar conjuntos de copia de seguridad en el sitio o fuera del sitio y un análisis de cómo esta decisión podría afectar al tiempo de recuperación.
Dado que los datos de Azure DevOps 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 produjo un error de medios o un desastre que implicaban 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 de copias de seguridad programadas disponibles o mediante la creación manual de 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 entre sí y, si crea un plan manual, debe realizar una copia de seguridad de ellas y restaurarlas al mismo tiempo. Para obtener más información sobre las estrategias para realizar copias de seguridad de bases de datos, consulte Copia de seguridad y restauración de bases de 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 está trabajando con una implementación grande y desea protegerse frente a la pérdida de datos, al tiempo que usa recursos de almacenamiento limitados, puede configurar copias de seguridad diferenciales, así como copias de seguridad de datos completas. Si usa SQL Server AlwaysOn, puede realizar copias de seguridad de la base de datos secundaria. También puede intentar usar la compresión de copia de seguridad o dividir las copias de seguridad en varios archivos. Estas son breves descripciones de las opciones de copia de seguridad:
Copias de seguridad de datos completas (bases de datos)
Se necesita una copia de seguridad completa de la base de datos para la capacidad de recuperación de la implementación. Una copia de seguridad completa incluye parte del registro de transacciones para que pueda recuperar la copia de seguridad completa. Las copias de seguridad completas están autocontenidas en que representan toda la base de datos tal como existía cuando se hizo una copia de seguridad de ella. Para más información, consulte Copias de seguridad completas de bases de datos.
Copias de seguridad diferenciales de datos (bases de datos)
Una copia de seguridad diferencial de la base de datos registra solo 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 de bases de datos son más pequeñas y más rápidas que las copias de seguridad completas de la base de datos. Esta opción ahorra tiempo de copia de seguridad a costa de una mayor complejidad. En el caso de las bases de datos grandes, las copias de seguridad diferenciales pueden producirse a intervalos más cortos que las copias de seguridad de base de datos, lo que reduce la exposición a la pérdida de trabajo. Para más información, consulte Copias de seguridad diferenciales de bases de datos.
También debe realizar copias de seguridad de los registros de transacciones con regularidad. Estas copias de seguridad son necesarias para recuperar datos cuando se usa el modelo de copia de seguridad completa de la base de datos. Si realiza una copia de seguridad de los registros de transacciones, puede recuperar la base de datos al punto de error o a un momento anterior.
Copias de seguridad de registros de transacciones
El registro de transacciones es un registro 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 en los datos y, si es necesario, suficiente información para deshacer las modificaciones realizadas durante esa transacción. El registro crece continuamente a medida que se producen operaciones registradas en la base de datos.
Al realizar una copia de seguridad de los registros de transacciones, puede recuperar la base de datos a un momento dado anterior. Por ejemplo, puede restaurar la base de datos a un punto antes de que se especificaran datos no deseados o se produjera un error. Además de las copias de seguridad de base de datos, las copias de seguridad del registro de transacciones deben formar parte de la estrategia de recuperación. Para obtener más información, consulte Copias de seguridad del registro de transacciones (SQL Server).
Las copias de seguridad del registro de transacciones suelen usar menos recursos que las copias de seguridad completas. Por lo tanto, puede crear copias de seguridad del registro de transacciones con más frecuencia que las copias de seguridad completas, lo que reduce el riesgo de perder 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 esta situación, debe crear copias de seguridad del registro de transacciones con más frecuencia. Para más información, vea Solución de 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 de registros pura solo contiene registros de registro de transacciones durante un intervalo, sin cambios masivos.
- Una copia de seguridad masiva del registro contiene páginas de registro y datos que han cambiado mediante operaciones masivas. No es posible la recuperación a un momento dado en el tiempo.
- Se toma una copia de seguridad del final del registro de una base de datos posiblemente dañada para capturar los registros de los que aún no se ha realizado una copia de seguridad. Una copia de seguridad del final del registro se realiza después de un error para evitar la pérdida de trabajo y puede contener datos de registro puros o de registro masivo.
Dado que la sincronización de datos es fundamental para la restauración correcta 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 más información, consulte Creación de una programación y un plan de copia de seguridad y copia de seguridad manual de Azure DevOps Server.
Copias de seguridad de servicio de nivel de aplicación
La única copia de seguridad necesaria para el nivel de aplicación lógica es para la clave de cifrado de Reporting Services. Si usa la característica Copias de seguridad programadas para realizar copias de seguridad de la implementación, esta clave se realizará automáticamente como parte del plan. Puede suponer que debe realizar una copia de seguridad de los sitios web que se usan como portales de proyecto.
Aunque puede realizar una copia de seguridad de un nivel de aplicación más fácilmente que un nivel de datos, todavía hay varios pasos para restaurar un nivel de aplicación. Debe instalar otro nivel de aplicación para Azure DevOps Server, redirigir colecciones de proyectos para usar el nuevo nivel de aplicación y redirigir los sitios del portal para proyectos.
Nombres de base de datos predeterminados
Si no personaliza los nombres de las bases de datos, puede usar la tabla siguiente para identificar las bases de datos usadas 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 distribuirse 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 funciona.
| Base de datos | Descripción |
|---|---|
| TFS_Configuration | La base de datos de configuración de Azure DevOps Server contiene los datos de catálogo, de servidor y de configuración de la implementación. El nombre de esta base de datos puede incluir caracteres adicionales entre TFS_ y 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 almacenamiento contiene los datos para crear el almacenamiento que usa Reporting Services. El nombre de esta base de datos puede 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 administración de laboratorio. El número de bases de datos de recopilación será igual al número de colecciones. Por ejemplo, si tiene tres colecciones en la implementación, debe realizar una copia de seguridad de estas tres bases de datos de recopilación. El nombre de cada base de datos puede 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 cubos para la implementación de Azure DevOps Server. El nombre de esta base de datos puede incluir caracteres adicionales entre TFS_ y Analysis, 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 realizar una copia de seguridad de esta base de datos, pero debe recompilar el almacenamiento a partir de la base de datos de TFS_Warehouse restaurada. |
| ReportServer | La base de datos de Reporting Services contiene los informes y la configuración del informe 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 restaurarla 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 para Reporting Services almacena temporalmente información al ejecutar informes específicos. 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 restaurarla 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 se ve en la consola de administrador de SCVMM, como máquinas virtuales, hosts de máquinas virtuales, servidores de biblioteca de máquinas virtuales y sus propiedades. Nota: Si SCVMM 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 ese caso, debe configurar, realizar una copia de seguridad y restaurarla por separado de Azure DevOps Server. Sin embargo, debe usar transacciones marcadas y sincronizar el mantenimiento de las bases de datos para evitar errores de sincronización. |