Copia de seguridad/restauración nativa de SQL Server

Las bases de datos Microsoft SQL Server dan soporte a operaciones de copia de seguridad y restauración nativas que utilizan archivos de copia de seguridad completa y diferencial (.bak) o restauraciones diferenciales y de registro. El uso de archivos .bak nativos es la forma más sencilla de realizar una copia de seguridad y restaurar bases de datos de SQL Server y un método de migración simple para una o varias bases de datos en una instancia. Las copias de seguridad completas de la base de datos en el servidor existente se realizan y se copian en un grupo de IBM Cloud Object Storage . A continuación, se restaura, a través de un servidor de transición con s3fs o rclone y SMB\Samba share, en el servidor virtual de instancia de base de datos de SQL Server en IBM Cloud VPC.

Réplica transaccional

La réplica transaccional permite transferir los cambios entre una base de datos y otra. Estos cambios pueden incluir: datos, tablas, procedimientos almacenados, vistas, etc. La arquitectura consta de lo siguiente:

• Publicador-la base de datos primaria que publica datos.
• Suscriptor: una base de datos secundaria que recibe datos replicados.
• Distribuidor-un servidor que almacena metadatos y transacciones para la replicación transaccional y es idealmente un servidor separado para el publicador o suscriptor.

El proceso funciona de la siguiente manera:

• La réplica transaccional crea una instantánea de los objetos y datos de la base de datos de publicaciones y la envía a la base de datos de suscriptores. La instantánea se aplica a la base de datos del suscriptor.
• Los cambios de datos y las modificaciones de esquema realizadas en el publicador se envían al suscriptor en el orden en que se han producido y se aplican al suscriptor en el mismo orden.
• Cuando las dos bases de datos están sincronizadas y en una ventana de mantenimiento:
  • Detenga cualquier acceso al editor.
  • Asegúrese de que la réplica se ha completado.
  • Suprima la suscripción.
  • Habilite el acceso a lo que era el suscriptor.
  • Deponer lo que era el editor.

Consulte Replicación transaccional para obtener más información.

Duplicación de base de datos

La duplicación de base de datos ha quedado en desuso en SQL Server 2012, sin embargo, todavía se hace referencia a ella en la documentación de SQL 2019, consulte Duplicación de base de datos en SQL Server. Se trata aquí para completar los métodos de migración, sin embargo, investigue cuidadosamente este enfoque si desea emplearlo en su migración.

La duplicación de base de datos en SQL Server le permite conservar una copia, o duplicación, de una base de datos SQL Server en un servidor en espera. La duplicación garantiza que siempre existan dos copias separadas de los datos. En comparación con el envío de registros, la duplicación de base de datos es un poco más complicada de configurar y tiene más restricciones. La duplicación de base de datos es más fácil de configurar si ambos servidores de la asociación están en el mismo dominio de Windows, pero si este no es el caso, puede utilizar certificados para la autenticación de punto final. Los pasos básicos para la migración incluyen:

• Configure la duplicación de base de datos.
• En el tiempo de corte necesario, detenga las aplicaciones que utilizan las bases de datos principales en el servidor primario.
• Asegúrese de que cada base de datos esté en un estado sincronizado.
• Migración tras error de cada base de datos de usuario duplicada.
• Elimine la asociación de duplicación.
• Redirija las aplicaciones al nuevo servidor de bases de datos.
• Dejar fuera de servicio el servidor original.

Envío de registro

El envío de registros de SQL Server se puede configurar a nivel de base de datos y en un periodo de tiempo especificado, la copia de seguridad del registro de transacciones de SQL Server se realizará y se copiará en el servidor de destino y se restaurará. Los registros de transacciones contienen un registro de todas las transacciones que se producen en una base de datos SQL Server . La instancia de SQL Server desde la que se envía la copia de seguridad del registro de transacciones se denomina primaria y la instancia de SQL Server a la que se envía la copia de seguridad del registro de transacciones se denomina secundaria. Antes de configurar el envío de registros, la base de datos debe estar en modalidad de recuperación completa o de registro masivo.

Los valores de copia de seguridad del registro de transacciones de SQL Server permiten direccionar a una vía de acceso de red y se puede definir el planificador de trabajos de copia de seguridad para ejecutar un trabajo de copia de seguridad; de forma predeterminada, el valor es ejecutar un trabajo de copia de seguridad cada 15 minutos. Una vez que se ha planificado la copia de seguridad de la base de datos, se crea una copia de seguridad completa de la base de datos que será necesario recuperar en el servidor secundario. Durante las horas de mantenimiento, se puede realizar una conmutación del servidor primario al servidor secundario, el envío de registros está inhabilitado y el servidor primario está fuera de servicio.

Grupos de disponibilidad Siempre activado

Los grupos de disponibilidad de SQL Server Siempre activado proporcionan soluciones de alta disponibilidad y recuperación tras desastre y están disponibles en las versiones de SQL Server 2012 y posteriores. Esta característica se puede utilizar para migrar las bases de datos existentes de SQL Server a IBM Cloud con un tiempo de inactividad mínimo. Si tiene un clúster de migración tras error de Windows Server existente con grupos de disponibilidad Siempre activado, puede ampliar el clúster temporalmente durante la migración creando una réplica secundaria adicional con réplica asíncrona. Durante una ventana de mantenimiento, se puede realizar una migración tras error manual para habilitar el corte.

Grupos de disponibilidad distribuida siempre activada

Un grupo de disponibilidad distribuida de SQL Server Siempre activado abarca dos grupos de disponibilidad distintos. Cada grupo de disponibilidad se configura en dos clústeres de migración tras error de Windows Server (WSFC) diferentes, uno en la ubicación de origen y otro en IBM Cloud VPC. Los sistemas operativos y las versiones de SQL Server no tienen que ser de la misma versión, siempre que puedan dar soporte a WSFC y a grupos de disponibilidad. Este método de migración es adecuado para volver a alojar bases de datos de SQL Server de misión crítica. La arquitectura del grupo de disponibilidad distribuida es un método eficaz de transferencia de datos, ya que la réplica primaria transfiere los datos sólo a la réplica del reenviador en IBM Cloudy, a continuación, el reenviador es responsable de sincronizar los datos con las réplicas secundarias en IBM Cloud. Una arquitectura típica es la siguiente:

• El clúster WSFC de origen aloja un grupo de disponibilidad Siempre activado, y tiene dos nodos y utiliza la réplica síncrona, con migración tras error automática.
• El clúster WSFC de destino, alojado en IBM Cloud tiene un grupo de disponibilidad Siempre activado, tiene dos nodos, uno en una zona de disponibilidad (AZ) en una región multizona (MZR) y utiliza la réplica síncrona, con migración tras error automática.
• Una conexión de red, normalmente una conexión de enlace directo conecta los dos clústeres.
• Se configura un grupo de disponibilidad distribuida Siempre activado y los datos se transfieren desde la réplica primaria del clúster WSFC de origen a la réplica primaria (el reenviador) en el clúster WSFC de destino.
• El reenviador es responsable de transferir datos a la réplica secundaria en el clúster WSFC de destino.

Durante una ventana de mantenimiento, se puede realizar una migración tras error manual para habilitar el corte y la base de datos primaria en el WSFC de destino se convierte en el origen para el acceso de lectura/escritura de las aplicaciones.

Para obtener más información, consulte Grupos de disponibilidad distribuida.