Preparación del entorno para la migración a LRS: migración de SQL Server en Azure Arc

Applies to:SQL Server

Este artículo le ayuda a preparar su entorno para una migración de Log Replay Service (LRS) de la instancia de SQL Server habilitada por Azure Arc a Azure SQL Managed Instance en el portal de Azure.

Con LRS, puede migrar las bases de datos de SQL Server a Azure SQL Managed Instance mediante la copia de seguridad y restauración mediante el trasvase de registros (migración en línea):

Prerrequisitos

Para migrar las bases de datos de SQL Server a Azure SQL Managed Instance a través del portal de Azure, necesita los siguientes requisitos previos:

• Una suscripción de Azure activa. En caso de no tener ninguna, cree una cuenta gratuita.
• Instancia compatible de SQL Server habilitada por Azure Arc con la última versión de la extensión de Azure para SQL Server. Para actualizar la extensión, consulte Actualización de la extensión.

Versiones de SQL Server admitidas

La migración con LRS funciona con cada edición de SQL Server en Windows. Aunque se admite la migración a los niveles de servicio De uso general y Crítico para la empresa de SQL Managed Instance, la migración directa al nivel de servicio Crítico para la empresa tiene algunas limitaciones importantes tener en cuenta.

En la tabla siguiente se enumeran las versiones mínimas admitidas de SQL Server para LRS:

La migración inversa solo se admite en SQL Server 2025 y SQL Server 2022 desde instancias administradas de SQL con la directiva update correspondiente. Puede revertir manualmente una migración utilizando otras herramientas, como copias de seguridad y restauración nativas o configurando manualmente un vínculo en SSMS.

Permissions

En esta sección se describen los permisos necesarios para migrar la instancia de SQL Server a SQL Managed Instance a través del portal de Azure.

En la instancia de SQL Server de origen, necesita los siguientes permisos:

• Si habilita privilegios mínimos, se conceden los permisos necesarios, como sysadmin, según sea necesario durante el proceso de migración de la base de datos.
• Si no puede usar privilegios mínimos, necesita permisos sysadmin en la instancia de SQL Server de origen.

Para migrar con LRS, necesita uno de los permisos siguientes en el destino de SQL Managed Instance:

• Rol Colaborador de SQL Managed Instance
• Un rol con el siguiente permiso: Microsoft.Sql/managedInstances/databases/*

Crear una cuenta de almacenamiento

Use una cuenta de Azure Blob Storage como almacenamiento intermediario para los archivos de copia de seguridad entre la instancia de SQL Server y la implementación de SQL Managed Instance. La cuenta de almacenamiento debe estar en la misma suscripción de Azure que el destino de SQL Managed Instance.

Para crear una nueva cuenta de almacenamiento y un contenedor de blobs dentro de esa cuenta:

1. Cree una cuenta de almacenamiento:
   1. Busque Cuentas de almacenamiento en el portal de Azure y seleccione Crear.
   2. En la pestaña Aspectos básicos , seleccione la suscripción y el grupo de recursos. La región debe ser la misma que el destino de SQL Managed Instance.
   3. Deje el tipo de almacenamiento preferido en blanco.
   4. Use la configuración predeterminada para el resto de las pestañas y seleccione Revisar y crear.
   5. Una vez pasada la validación, seleccione Crear.
2. Cree un contenedor de blobs dentro de la cuenta de almacenamiento.
   1. Vaya a la nueva cuenta de almacenamiento en el portal de Azure.
   2. En Almacenamiento de datos, seleccione Contenedores.
   3. Use Agregar contenedor para abrir el panel Nuevo contenedor .
   4. Escriba un nombre para el contenedor, deje las opciones en sus valores predeterminados y seleccione Crear para crear el contenedor.
3. (Opcional) Si tu almacenamiento de Azure está detrás de un firewall, tu almacenamiento de blobs de Azure requiere configuración adicional después de aprovisionar la instancia administrada de SQL.

Concesión de permisos para Azure Blob Storage

Migración de SQL Server en Azure Arc con LRS usa una identidad administrada para autenticarse con Azure Blob Storage.

Debe conceder los siguientes permisos:

• Otorgue al usuario acceso a la cuenta de almacenamiento donde planea almacenar copias de seguridad durante el proceso de migración.
• Conceda al usuario acceso al grupo de recursos que contiene la cuenta de almacenamiento.
• Conceda acceso a la cuenta de almacenamiento a la identidad administrada después de que se aprovisione la instancia administrada de SQL.

Concesión de acceso de usuario a la cuenta de almacenamiento

Para acceder a las copias de seguridad de la base de datos durante el proceso de migración, asigne al usuario que inicia sesión en el portal de Azure y realice la migración a la Storage Blob Data Reader rol de la cuenta de almacenamiento que contiene las copias de seguridad.

Para asignar el rol, siga estos pasos:

1. En el portal de Azure, vaya al grupo de recursos que contiene la cuenta de almacenamiento.

2. Seleccione Control de acceso (IAM) en el menú de recursos.

3. Use + Agregar para seleccionar Agregar asignación de roles y abra el panel Agregar asignación de roles .

4. Busque y seleccione el rol Lector de datos de Storage Blob . Después, seleccione Siguiente.

   

5. Use + Seleccionar miembros para abrir el panel Seleccionar miembros y busque la cuenta de usuario de la persona que realiza la migración. Si varias personas van a migrar datos, conceda a todos esos usuarios este acceso. Seleccione la cuenta de usuario y, a continuación, use Seleccionar para guardar la selección. Active la opción para asignar acceso a usuario, grupo o entidad de servicio.

6. Seleccione Revisar y asignar para ir a la pestaña Revisar y asignar y, a continuación, seleccione Revisar y asignar de nuevo para completar la asignación de roles.

Concesión de acceso de usuario al grupo de recursos

Para acceder a las copias de seguridad de la base de datos durante el proceso de migración, el usuario que inicia sesión en el portal de Azure y realiza la migración debe asignarse el rol Reader en el grupo de recursos que contiene la cuenta de almacenamiento.

Para asignar el rol, siga estos pasos:

1. En el portal de Azure, vaya al grupo de recursos que contiene la cuenta de almacenamiento.

2. Seleccione Control de acceso (IAM) en el menú de recursos.

3. Use + Agregar para seleccionar Agregar asignación de roles y abra el panel Agregar asignación de roles .

4. Busque y seleccione el rol Lector . Después, seleccione Siguiente.

   

5. Use + Seleccionar miembros para abrir el panel Seleccionar miembros y busque la cuenta de usuario de la persona que realiza la migración. Si varias personas van a migrar datos, conceda a todos esos usuarios este acceso. Seleccione la cuenta de usuario y, a continuación, use Seleccionar para guardar la selección. Active la opción para asignar acceso a usuario, grupo o entidad de servicio y, a continuación, use Siguiente para continuar.

6. En la pestaña Tipo de asignación , establezca el tipo de asignación en Activo y la duración de la asignación en Permanente:

   

7. Seleccione Revisar y asignar para ir a la pestaña Revisar y asignar y, a continuación, seleccione Revisar y asignar de nuevo para completar la asignación de roles.

Concesión de acceso de identidad administrada a la cuenta de almacenamiento

Una vez que se aprovisione tu instancia administrada de SQL, debes asignarle a su identidad administrada el rol Storage Blob Data Reader para que pueda acceder a la cuenta de Azure Blob Storage durante el proceso de migración.

En primer lugar, debe determinar qué tipo de identidad administrada usa la instancia administrada de SQL. Para ello, siga estos pasos:

1. Vaya a la instancia administrada de SQL en el portal de Azure.
2. En Seguridad, seleccione Identidad.
   1. Si en Identidad administrada asignada por el usuario, ve No se han encontrado identidades administradas asignadas por el usuario, su instancia de SQL administrada utiliza la identidad predeterminada asignada por el sistema.
   2. Si ve una entrada en el campo Identidad principal, la instancia administrada de SQL usa una identidad administrada asignada por el usuario. Anote esta identidad para usarla en el paso en el que va a seleccionar esta identidad administrada al conceder acceso de lector de datos de Storage Blob a la cuenta de almacenamiento.

Para conceder acceso a la cuenta de almacenamiento, siga estos pasos:

1. Vaya a la cuenta de Azure Blob Storage en el portal de Azure que quiere usar para la migración.
2. Seleccione Control de acceso (IAM) en el menú de recursos.
3. Use + Agregar para seleccionar Agregar asignación de roles y abra el panel Agregar asignación de roles .
4. Busque y seleccione el rol Lector de datos de Storage Blob . Después, seleccione Siguiente.
5. En Asignar acceso para comprobar la opción Identidad administrada .
6. Use Seleccionar miembros para abrir el panel Seleccionar miembros .
7. Si la instancia administrada de SQL usa la identidad administrada asignada por el sistema predeterminada:
   1. En Identidad administrada, seleccione Instancia administrada de SQL.
   2. Busque y seleccione el nombre de la instancia administrada de SQL.
   3. Use Seleccionar para guardar la selección.
8. Si la instancia administrada de SQL usa una identidad administrada asignada por el usuario:
   1. En Identidad administrada, seleccione Identidad administrada asignada por el usuario.
   2. Busque el nombre de identidad principal que anotó anteriormente en la página Identidad de la instancia administrada de SQL y selecciónelo.
   3. Use Seleccionar para guardar la selección.
9. Seleccione Revisar y asignar para ir a la pestaña Revisar y asignar y, a continuación, seleccione Revisar y asignar de nuevo para completar la asignación de roles.

Una vez que haya cargado al menos una copia de seguridad completa en esta cuenta de almacenamiento, puede ejecutar el siguiente comando en la instancia administrada de SQL para comprobar que puede acceder a la cuenta de Azure Blob Storage:

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

Configuración de la base de datos de SQL Server de origen

Habilite la recuperación acelerada de bases de datos y Service Broker en la instancia de SQL Server de origen si planea usar estas características en el SQL Managed Instance de destino después de la migración, ya que estas características no se pueden habilitar después de la migración si aún no están habilitadas en la instancia de SQL Server de origen.

Habilitación de la recuperación acelerada de bases de datos

Para SQL Server 2019 y versiones posteriores, habilite la recuperación de base de datos accelerated y asegúrese de que el almacén de versiones persistente (PVS) esté establecido en PRIMARY. Si la recuperación acelerada de la base de datos no está habilitada en la base de datos de origen SQL Server, no puede habilitarla en la instancia administrada de SQL de destino después de migrar la base de datos. Si el almacén de versiones persistente (PVS) no está establecido en PRIMARY, puede experimentar problemas con las operaciones de restauración en la instancia de SQL administrada de destino.

Para SQL Server 2017 y versiones anteriores, no se admite la recuperación acelerada de bases de datos, por lo que este paso no es necesario.

Para configurar la recuperación acelerada de la base de datos correctamente en la base de datos de SQL Server de origen, siga estos pasos:

1. Habilite la recuperación acelerada de la base de datos ejecutando el siguiente script de Transact-SQL en SQL Server:

   ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
   

2. El almacén de versiones persistente (PVS) debe establecerse PRIMARY en la base de datos de origen, que es la configuración predeterminada. Si esto se cambió anteriormente, debe volver a cambiarlo a PRIMARY antes de iniciar la migración.

Habilitación de Service Broker

Service Broker está habilitado de forma predeterminada para todas las versiones de SQL Server. Si Service Broker se deshabilitó y planea usarlo en SQL Managed Instance, habilite Service Broker en la base de datos de SQL Server de origen antes de migrar a SQL Managed Instance. Si Service Broker no está habilitado en la base de datos de SQL Server de origen, no puede usarlo en la instancia administrada de SQL de destino.

Para comprobar si Service Broker está habilitado, ejecute el siguiente script de Transact-SQL en SQL Server instancia:

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Si Service Broker está deshabilitado, habilite mediante la ejecución del siguiente script de Transact-SQL en la base de datos de SQL Server de origen:

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

Carga de copias de seguridad en la cuenta de Blob Storage

Cuando el contenedor de blobs esté listo y haya confirmado que la instancia administrada de SQL puede acceder al contenedor, puede empezar a cargar las copias de seguridad en la cuenta de Azure Blob Storage. Cuando todas las copias de seguridad se cargan en la cuenta de almacenamiento, está listo para continuar con la migración.

Para cargar las copias de seguridad en Azure:

• Realice copias de seguridad en una instancia de SQL Server.
• Copy las copias de seguridad en la cuenta de Blob Storage.
• Alternativamente, SQL Server 2025 (17.x) en Windows Server presenta compatibilidad con la identidad administrada para copias de seguridad directamente en URL. Para realizar una copia de seguridad directamente a la URL de SQL Server 2022 y versiones anteriores, debe usar un token de SAS. Para usar una identidad administrada con SQL Server 2022 y versiones anteriores, copie las copias de seguridad en la cuenta de Blob Storage mediante AzCopy. La única excepción es si va a migrar desde SQL Server en máquinas virtuales de Azure, que admite la copia de seguridad directamente en URL con la autenticación de identidad administrada a partir de SQL Server 2022 CU 17.

Puede usar los siguientes procedimientos recomendados:

• Realice copias de seguridad con COMPRESSION opciones y CHECKSUM para reducir el tamaño de los archivos de copia de seguridad y evitar la migración de una base de datos dañada.
• Realice copias de seguridad en lotes más pequeños.
• Utilice hilos de carga en paralelo.
• Haga que el último archivo de copia de seguridad sea lo más pequeño posible.
• Para migrar varias bases de datos mediante el mismo contenedor de Azure Blob Storage, coloque todos los archivos de copia de seguridad de una base de datos individual en una carpeta independiente dentro del contenedor. Use una estructura de archivos plana para cada carpeta de base de datos. No se admite el anidamiento de carpetas dentro de carpetas de base de datos.

Realizar copias de seguridad en una instancia de SQL Server

Los pasos de esta sección muestran cómo hacer copias de seguridad de forma local, pero también es posible hacer copias de seguridad directamente a una URL.

Establezca las bases de datos que quiere migrar en el modo de recuperación completa para permitir copias de seguridad de registros.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master;

ALTER DATABASE SampleDB
SET RECOVERY FULL;
GO

Si aún no tiene copias de seguridad existentes, para realizar manualmente copias de seguridad completas, diferenciales y de registro de la base de datos en el almacenamiento local, use los siguientes scripts T-SQL de ejemplo. CHECKSUM no es necesario, pero es recomendable para evitar la migración de una base de datos dañada y para tiempos de restauración más rápidos.

En el ejemplo siguiente, se realiza una copia de seguridad completa de la base de datos en el disco local:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

En el ejemplo siguiente, se realiza una copia de seguridad diferencial en el disco local:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

En el ejemplo siguiente, se realiza una copia de seguridad de registros en el disco local:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
GO

Copia de copias de seguridad en la cuenta de Blob Storage

Una vez que las copias de seguridad estén listas y quiera empezar a migrar bases de datos a una instancia administrada de SQL mediante LRS, use los métodos siguientes para copiar las copias de seguridad existentes en la cuenta de Blob Storage:

• Descargue e instale AzCopy.
• Descargue e instale Explorador de Azure Storage.
• Use Explorador de Storage en el portal de Azure.

Limitaciones

Las limitaciones de LRS se aplican a las migraciones a través del portal de Azure.

Limitaciones al migrar al nivel de servicio Crítico para la empresa

Al migrar a un SQL Managed Instance en el nivel de servicio Business Critical, tenga en cuenta las siguientes limitaciones:

• Al migrar bases de datos grandes, es posible que experimente un tiempo de inactividad considerable porque las bases de datos no están disponibles después de la transición mientras se propagan a las réplicas secundarias del nivel de servicio Crítico para la empresa. Las soluciones alternativas se enumeran en la sección de transición más larga.
• La migración se reinicia automáticamente desde el principio si la conmutación por error no planeada, la actualización del sistema o la revisión de seguridad interrumpe la migración. Esta limitación dificulta planear una migración predecible sin sorpresas de último minuto.

Transición más larga en el nivel de servicio Crítico para la empresa

Si va a migrar a un SQL Managed Instance en el nivel de servicio Business Critical, tenga en cuenta el retraso en poner las bases de datos en línea en la réplica principal mientras se propagan a las réplicas secundarias. Este retraso es especialmente cierto para bases de datos más grandes.

La migración a un SQL Managed Instance en el nivel de servicio Business Critical tarda más tiempo en completarse que en el nivel de servicio De uso general. Una vez completada la migración a Azure, las bases de datos no están disponibles hasta que sean replicadas desde la réplica principal en las tres réplicas secundarias. El proceso de propagación puede tardar un tiempo prolongado en función del tamaño de la base de datos. Cuanto mayor sea la base de datos, la propagación a las réplicas secundarias será más larga; puede tardar hasta varias horas.

Si es importante que las bases de datos estén disponibles en cuanto se complete la transición, tenga en cuenta las siguientes soluciones alternativas:

• Migre primero al nivel de servicio De uso general y, a continuación, actualice al nivel de servicio Crítico para la empresa . La actualización del nivel de servicio es una operación en línea que mantiene las bases de datos en funcionamiento hasta que se produce una conmutación por error corta como último paso de la operación de actualización.
• Usa el vínculo Instancia administrada para una migración en línea a una instancia Business Critical sin esperar a que las bases de datos estén disponibles después de la migración total.

La supervisión de la migración a través del portal de Azure solo está disponible para instancias de SQL Server que cumplan los requisitos de licencia.

Solución de problemas comunes

Para solucionar problemas comunes al migrar a Azure SQL Managed Instance, consulte Solucionar problemas de migración.

Paso siguiente

Contenido relacionado

• Migración de SQL Server en Azure Arc
• Preparar el entorno para una migración de enlace de instancia gestionada
• Descripción general de SQL Server habilitado por Azure Arc
• Comentarios de la experiencia de migración directamente al grupo de productos
• Migración a Azure SQL Managed Instance - Migración de SQL Server en Azure Arc