Guía de migración de bases de datos SQL Server con Downtime Mínimo

adminJul 1, 2025

Migrar una base de datos SQL Server grande y en producción desde un servidor local a la nube es una de las tareas más delicadas para cualquier profesional de IT. El miedo a un tiempo de inactividad prolongado, la pérdida de datos o los fallos de seguridad son riesgos reales. Sin embargo, con un plan sólido y las herramientas adecuadas, es posible realizar esta operación de forma segura, eficiente y con una interrupción del servicio de apenas unos minutos.

En esta guía definitiva, te llevaremos de la mano a través de un método probado y seguro que utiliza backups, logs de transacciones y un canal SFTP para garantizar una migración exitosa. No solo te diremos qué hacer, sino por qué lo haces, dándote el conocimiento para resolver problemas y adaptar el proceso a tus necesidades. Olvídate de las ventanas de mantenimiento de horas; te enseñaremos a hacerlo como un profesional.

1. Fase de Preparación del Servidor de Destino (Nube)

Antes de tocar la base de datos de origen, debemos preparar el nuevo hogar en la nube. Una preparación meticulosa aquí es la clave para una ejecución sin problemas más adelante. Nuestro primer objetivo es configurar un punto de entrada seguro y robusto para los archivos de backup mediante un servidor SFTP.

1.1. Instalando el Servidor OpenSSH

La forma más sencilla y nativa de montar un servidor SFTP en Windows Server es a través de la característica OpenSSH. Para instalarla, abre PowerShell como Administrador y ejecuta el siguiente comando. Es mucho más rápido que usar la interfaz gráfica.

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

1.2. Iniciando y Configurando el Servicio SSH

Una vez instalado, debemos asegurarnos de que el servicio se ejecute y se inicie automáticamente con el servidor. Abre la aplicación Servicios, busca en la lista OpenSSH SSH Server, haz clic derecho sobre él y selecciona Propiedades. En Tipo de inicio, elíge Automático, haz clic en Iniciar para arrancarlo ahora mismo y luego en Aceptar. Esto garantiza que si el servidor se reinicia, el servicio SFTP volverá a estar disponible sin intervención manual.

1.3. Configurando el Firewall

La seguridad es primordial. Debemos permitir la entrada por el puerto 22, pero idealmente solo desde la IP de origen. Abre el Firewall de Windows Defender con seguridad avanzada y ve a Reglas de entrada. Busca la regla llamada OpenSSH SSH Server (sshd) y asegúrate de que esté habilitada (icono verde). Para una seguridad extra, haz doble clic en la regla, ve a la pestaña Ámbito y en la sección «Direcciones IP remotas», selecciona «Estas direcciones IP» y añade la IP pública específica del servidor de origen. Esto reduce drásticamente la superficie de ataque, ya que bloquea cualquier intento de conexión desde otras partes del mundo.

1.4. Creando un Usuario y Carpeta Dedicados para SFTP

Por seguridad, nunca uses una cuenta de administrador para estas tareas. Primero, crea la carpeta en el servidor de destino donde se recibirán los backups. Recomendación: No uses el disco del sistema operativo (C:). Crea la carpeta en un disco de datos separado, por ejemplo: D:\Backups_Recibidos. Esto evita llenar el disco del SO y afectar el rendimiento del servidor.

A continuación, crea un usuario local sin privilegios. Abre Administración de equipos > Usuarios y grupos locales > Usuarios. Haz clic derecho y selecciona Usuario nuevo…. Dale un nombre (ej: sftpuser), una contraseña segura, desmarca «El usuario debe cambiar la contraseña…» y marca «La contraseña nunca expira».

1.5. Asegurando y «Enjaulando» al Usuario SFTP

Este es un paso de seguridad crítico. Vamos a forzar a que este usuario solo pueda usar SFTP y que no pueda navegar fuera de su carpeta designada. Para ello, navega a C:\ProgramData\ssh y abre el archivo sshd_config con un editor de texto (ejecutado como Administrador). Pega el siguiente bloque de configuración al final del archivo:

# --- Configuración SFTP para sftpuser ---
Match User sftpuser
    ForceCommand internal-sftp
    PasswordAuthentication yes
    ChrootDirectory D:\Backups_Recibidos
    PermitTunnel no
    AllowAgentForwarding no
    AllowTcpForwarding no
    X11Forwarding no

Explicación de las directivas:

ForceCommand internal-sftp: Obliga a que la sesión sea solo de transferencia de archivos, impidiendo la ejecución de comandos remotos.
ChrootDirectory: «Enjaula» al usuario en el directorio especificado, mejorando la seguridad.
Las demás directivas (PermitTunnel, Allow...) desactivan funcionalidades de reenvío de puertos que no son necesarias y podrían ser un riesgo de seguridad.

A continuación, ajusta los permisos de la carpeta D:\Backups_Recibidos. Haz clic derecho > Propiedades > Seguridad > Opciones avanzadas. El Propietario debe ser SYSTEM o el grupo Administradores, y el sftpuser solo debe tener permisos de Lectura y ejecución, no de escritura. Finalmente, reinicia el servicio OpenSSH SSH Server para que los cambios surtan efecto.

2. Fase de Preparación del Servidor de Origen (On-Premise)

Con el destino listo, ahora preparamos el servidor desde el que vamos a enviar los datos.

2.1. Instalando el Cliente SFTP (FileZilla)

Para transferir los archivos, necesitamos un programa cliente. En el servidor de origen, abre un navegador y descarga el cliente de FileZilla desde su página oficial. La instalación es sencilla; puedes aceptar las opciones por defecto. Recomendación: Una vez abierto, usa el «Gestor de Sitios» (Archivo > Gestor de Sitios) para guardar la configuración de conexión. Esto te ahorrará tiempo y evitará errores al no tener que teclear los datos cada vez.

2.2. Analizando y Configurando la Base de Datos

Este paso es el corazón de nuestra estrategia de bajo downtime. Necesitamos que la base de datos esté en modo de recuperación FULL para poder capturar los cambios en tiempo real. Conéctate al servidor de origen con SSMS y ejecuta esta consulta para verificar el estado actual:

SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'NombreDeTuBBDD';

Si el resultado es SIMPLE, debes cambiarlo a FULL con el siguiente comando. Si ya está en FULL, puedes omitir este paso. Impacto a considerar: Cambiar a FULL significa que el log de transacciones (.ldf) comenzará a crecer. Debes asegurarte de tener una estrategia de backups de logs periódicos para gestionarlo o suficiente espacio en disco.

ALTER DATABASE [NombreDeTuBBDD] SET RECOVERY FULL WITH NO_WAIT;

¡Atención! Si acabas de cambiar el modelo a FULL, es obligatorio realizar un backup completo inmediatamente. Este backup inicializa la cadena de logs que nos permitirá hacer la «magia» más adelante.

3. Fase del Proceso de Backup y Migración

Dividiremos la migración en dos sub-fases: el trabajo pesado que hacemos sin molestar a nadie, y la ejecución final que dura solo unos minutos.

3.1. Trabajo Previo (Sin Corte de Servicio)

3.1.1. Realizar el Backup Completo en Local

En el servidor de origen, ejecuta el backup completo de la base de datos. Recomendación: Antes del backup, considera ejecutar una comprobación de integridad para asegurarte de que no estás copiando una base de datos corrupta. DBCC CHECKDB ('NombreDeTuBBDD') WITH NO_INFOMSGS; Un resultado sin errores te da la tranquilidad de que la base de datos está sana.

BACKUP DATABASE [NombreDeTuBBDD]
TO DISK = N'D:\Backups\BBDD_COMPLETA.bak' -- Asegúrate de que esta ruta existe
WITH COMPRESSION, STATS = 10, CHECKSUM;
GO

La opción WITH CHECKSUM añade una capa extra de verificación para garantizar que el backup no se corrompa durante la escritura.

3.1.2. Transferir el Backup Completo vía SFTP

Abre FileZilla en el servidor de origen. Usa la IP pública del servidor de destino y las credenciales del sftpuser para conectarte por el puerto 22. Una vez conectado, verás tus archivos locales a la izquierda y los remotos a la derecha. Simplemente arrastra el archivo BBDD_COMPLETA.bak desde tu carpeta local de backups a la carpeta remota. Si la conexión es inestable, clientes como FileZilla o WinSCP pueden reanudar transferencias interrumpidas.

3.1.3. Restaurar el Backup en la Nube en Modo `NORECOVERY`

En el servidor de destino, vamos a restaurar este backup, pero dejándolo en un estado de «standby». Conéctate con SSMS al servidor de la nube y ejecuta la restauración. Presta especial atención a la cláusula WITH NORECOVERY. Si la olvidas, la base de datos quedará online y no podrás aplicar el log final, obligándote a empezar de nuevo.

RESTORE DATABASE [NombreDeTuBBDD]
FROM DISK = N'D:\Backups_Recibidos\BBDD_COMPLETA.bak'
WITH
    MOVE N'NombreLogicoDelMDF' TO N'D:\MSSQL\Data\NombreDeTuBBDD.mdf',
    MOVE N'NombreLogicoDelLDF' TO N'E:\MSSQL\Log\NombreDeTuBBDD.ldf',
    NORECOVERY,
    REPLACE,
    STATS = 5;
GO

Al terminar, verás la base de datos en la lista con el estado «(Restaurando…)». ¡Perfecto! Está lista para el último paso.

3.2. Ejecución Final (Durante la Ventana de Corte)

3.2.1. Iniciar el Corte y Realizar el Backup Final del Log

Este es el momento de la verdad. Coordina con el cliente el inicio del corte de servicio. Una vez detenida la aplicación, ejecuta este comando en el servidor de origen. Este backup se conoce como «tail-log backup» (backup de la cola del log) y captura hasta la última transacción confirmada.

BACKUP LOG [NombreDeTuBBDD]
TO DISK = N'D:\Backups\BBDD_ULTIMO_LOG.trn'
WITH STATS = 10;
GO

3.2.2. Transferir y Restaurar el Log

Usa FileZilla de nuevo para transferir el pequeño archivo .trn al servidor de destino. Tardará solo unos segundos. Inmediatamente después, en el SSMS del servidor de destino, restaura este log.

RESTORE LOG [NombreDeTuBBDD]
FROM DISK = N'D:\Backups_Recibidos\BBDD_ULTIMO_LOG.trn'
WITH NORECOVERY, STATS = 5;
GO

3.2.3. Poner la Base de Datos Online

Este es el comando final que activa la base de datos en la nube.

RESTORE DATABASE [NombreDeTuBBDD] WITH RECOVERY;

En este instante, el tiempo de inactividad técnico ha terminado. La base de datos está online, completamente actualizada y lista para recibir conexiones.

4. Fase de Cierre, Validación y Plan de Emergencia

4.1. Apuntar la Aplicación y Validar

El paso final es que el equipo del cliente actualice la cadena de conexión de su software para que apunte a la IP del nuevo servidor en la nube. Una vez hecho esto, es crucial realizar una validación funcional completa junto a ellos. Checklist de validación recomendado:

Acceso: ¿Pueden los usuarios iniciar sesión?
Datos: ¿Se muestran los datos recientes correctamente?
Operaciones CRUD: ¿Pueden crear, leer, actualizar y eliminar registros?
Funciones clave: ¿Funcionan los informes más importantes o los procesos de negocio críticos?
Rendimiento: ¿La aplicación responde con una velocidad aceptable?

4.2. El Plan de Rollback (Plan B)

Un buen profesional siempre tiene un plan de vuelta atrás. Si algo sale catastróficamente mal durante la validación, el proceso es simple: pedir al cliente que vuelva a apuntar su aplicación al servidor original. Como no hemos modificado la base de datos de origen, el sistema volverá a funcionar exactamente como antes del corte.

5. Tareas Post-Migración y Optimización

El trabajo no termina cuando la base de datos está online. Realizar estas tareas asegurará un rendimiento y una estabilidad óptimos a largo plazo.

5.1. Actualizar Estadísticas y Reconstruir Índices

Las estadísticas de la base de datos pueden no estar actualizadas tras la restauración. Ejecuta lo siguiente para ponerlas al día, lo que es vital para el rendimiento de las consultas.

EXEC sp_updatestats;

5.2. Comprobar Usuarios Huérfanos

Es posible que los inicios de sesión (logins) del servidor no estén correctamente mapeados a los usuarios de la base de datos. Ejecuta este comando para detectar «usuarios huérfanos».

EXEC sp_change_users_login 'Report';

5.3. Establecer un Nuevo Plan de Mantenimiento y Backup

La base de datos está ahora en un nuevo hogar. Es fundamental configurar un nuevo plan de backups (completos, diferenciales y de logs) adecuado para el entorno de nube. No asumas que los planes antiguos siguen siendo válidos.

5.4. Monitorización y Desmantelamiento

Monitoriza de cerca el rendimiento del nuevo servidor durante los primeros días. Una vez que estés seguro de que la migración ha sido un éxito y el sistema es estable, puedes planificar el desmantelamiento seguro del antiguo servidor de base de datos.

Conclusión

¡Felicidades! Siguiendo estos pasos, has ejecutado una migración de SQL Server de nivel profesional. Has minimizado el riesgo y el tiempo de inactividad para el cliente, utilizando un método seguro y fiable que garantiza la integridad de los datos. Esta técnica de backup/log shipping manual a través de SFTP demuestra un dominio técnico que diferencia a un simple administrador de un verdadero arquitecto de soluciones. Ahora tienes en tu poder un playbook robusto para enfrentar una de las tareas más temidas en el mundo IT.