Actualmente, existen muchas tecnologías de recuperación ante desastres (DR) en la industria, incluyendo espejado de bases de datos, agrupamiento y soluciones de replicación. Sin embargo, el traslado de registros (log shipping) es un método más sencillo, fácil de configurar y mantener. Este artículo tratará los pasos para la recuperación ante desastres en SQL Server utilizando el traslado de registros.
Solución de recuperación ante desastres con envío de registros
El envío de registros principalmente mantiene copias de seguridad en un servidor secundario y asume el control del servidor principal según sea necesario para mejorar la disponibilidad general de la base de datos. En otras palabras, cuando la base de datos principal se vuelve indisponible debido a un desastre, puede activar manualmente la base de datos secundaria para continuar brindando servicios.
Para configurar el traslado de registros para una base de datos, SQL Server crea los siguientes tres trabajos del agente para automatizar las operaciones de copia de seguridad, copiado y restauración:
El primer trabajo se ejecuta en la instancia principal. Hace una copia de seguridad del registro de transacciones en la base de datos principal.
El segundo trabajo se ejecuta en el servidor secundario. Copia las copias de seguridad del registro desde el servidor principal al servidor secundario.
El tercer trabajo también se ejecuta en el servidor secundario. Restaura las copias de seguridad del registro y actualiza las entradas del registro en la base de datos secundaria.
Consideraciones antes de configurar el envío de registros en SQL Server
Aunque configurar el envío de registros no es difícil, se deben tener en cuenta varias consideraciones antes de su implementación:
Protección a nivel de base de datos: Si solo necesita proteger un número reducido de bases de datos en caso de un desastre, este nivel es suficiente. Sin embargo, si desea conservar múltiples bases de datos a nivel de instancia de SQL Server, una solución independiente de envío de registros no es adecuada.
Conmutación manual por error en el servidor secundario: El envío de registros por sí solo no puede conmutar automáticamente del servidor principal al servidor secundario. Debe activar manualmente la base de datos secundaria.
Configuración manual de inicio de sesión SQL: Los inicios de sesión SQL no se transfieren automáticamente del servidor principal al servidor secundario. Necesita transferir las credenciales de inicio de sesión desde la instancia del servidor principal a la instancia del servidor secundario para sincronizar los inicios de sesión. Además, a menudo necesita crear manualmente varios planes de mantenimiento, servidores vinculados, y paquetes de SSIS (SQL Server Integration Services) en el servidor secundario.
Riesgo de pérdida de datos: Normalmente, cuando la base de datos principal no está disponible, solo se puede restaurar la última copia de seguridad del registro de transacciones. Esto significa que todas las transacciones realizadas después de que se enviara la última copia del registro a el servidor secundario se perderán. Por ejemplo, si el servidor principal falla a las 9:00 AM y la última copia enviada al servidor secundario B fue a las 8:45 AM, entonces todos los datos entre las 8:45 AM y las 9:00 AM se perderán.
Envío inverso de registros: Esto es útil cuando se cambian los roles de los servidores sin realizar una copia de seguridad completa de la base de datos. Por ejemplo, si tienes una copia de seguridad grande y necesitas transferir datos desde el servidor secundario a un servidor principal remoto, podría tardar mucho tiempo en copiar toda la copia de seguridad.
¿Cómo configurar y usar el envío de registros?
Generalmente, el proceso de configuración del envío de registros se puede dividir en dos pasos claramente diferenciados:
Paso 1 – Inicializar la base de datos en el servidor secundario
Supongamos que tenemos dos bases de datos en la instancia del servidor principal y necesitamos transferir los registros de TestDB1 a un servidor secundario que inicialmente no tiene ninguna base de datos. Es importante tener en cuenta que para configurar la transferencia de registros, la base de datos debe estar en modo de recuperación COMPLETO o BULK-LOGGED. Si la base de datos está en modo de recuperación SIMPLE, la transferencia de registros fallará porque no se podrán utilizar las copias de seguridad del registro de transacciones.
1. Primero, necesitamos realizar una copia de seguridad completa de la base de datos y una copia de seguridad del registro de transacciones. Puede ejecutar las siguientes consultas T-SQL para crear copias de seguridad "completas" y "del registro de transacciones":
backup database TestDB1 to disk = 'c:\backup\TestDB1.bak'
backup log TestDB1 to disk = 'c:\backup\TestDB1.bak'
2. A continuación, restaure la copia de seguridad en el servidor secundario .
3. En la interfaz Restore Database, seleccione Device como fuente de datos y haga clic en su icono.
4. En el cuadro de diálogo Select backup devices, haga clic en Add.
5. Seleccione el archivo de copia de seguridad para restaurar y haga clic en OK.
6. Ejecute la restauración de la copia de seguridad TestDB1.
7. Haga clic en Select a page y vaya a Files para modificar las ubicaciones de los archivos de la base de datos física si es necesario.
8. Luego, haga clic en Options en el lado izquierdo. En la página de Options, seleccione RESTORE WITH STANDBY de la lista desplegable de Recovery state. Tenga en cuenta que al seleccionar RESTORE WITH STANDBY se asegura de que la base de datos permanezca en un estado de solo lectura. Si elige RESTORE WITH NORECOVERY, la base de datos será inaccesible.
9. Tras seleccionar el estado de recuperación apropiado, haga clic en OK para garantizar una restauración exitosa. Esto restaurará TestDB1 en modo Standby (solo lectura) en la instancia del servidor secundario.
En este punto, la base de datos se ha inicializado correctamente en el servidor secundario.
Paso 2 – Activar la Base de Datos Principal
1. Haga clic derecho en TestDB1 en la instancia del servidor principal y haga clic en Properties.
2. Seleccione Enable this as the primary database in the log shipping configuration.
De forma predeterminada, el registro de transacciones se respalda cada 15 minutos. Sin embargo, en ocasiones el registro de transacciones puede crecer demasiado como para ser copiado y restaurado dentro del límite de tiempo predefinido. Para resolver este problema, debe programar copias de seguridad adicionales del registro. Haga clic en Configuración de copia de seguridad, especifique la ubicación del archivo de copia de seguridad en la interfaz de Configuración de copia de seguridad del registro de transacciones y luego haga clic en Programar, y cambie la frecuencia de copia de seguridad para que se ejecute cada 1-2 minutos.
3. Haga clic en Add para configurar la base de datos secundaria. El sistema le solicitará que se conecte a la instancia del servidor secundario.
4. Como se configuró en el Paso 1, en la interfaz de Secondary Database Settings, seleccione No, the secondary database is initialized.
5. Proceda a copiar los archivos especificando la ubicación de la carpeta de copia de seguridad del servidor secundario, configurando la frecuencia de copia de seguridad y haciendo clic en OK.
6. En la interfaz Restore Transaction Log, establezca el estado de la base de datos en Standby mode y marque Disconnect users in the database when restoring backups. Tras configurar el intervalo de copia de seguridad, haga clic en OK.
7. Para agregar la instancia del servidor secundario y la base de datos, haga clic en OK para crear trabajos del agente de SQL Server.
Bajo el SQL Server Agent en el servidor principal, encontrará el trabajo de copia de seguridad del registro de transacciones.
Bajo el Agente de SQL Server en el servidor secundario, encontrará dos trabajos recién creados: uno que copia las copias de seguridad del registro de transacciones desde la base de datos principal y otro que restaura las copias de seguridad del registro de transacciones en la base de datos secundaria.
8. En este punto, la solución de recuperación ante desastres con envío de registros está completamente configurada. Si la base de datos principal falla, puede poner inmediatamente en línea la base de datos secundaria. También puede ejecutar la siguiente consulta para confirmar que la base de datos secundaria ha salido del modo de espera:
Select * from Products
RESTORE DATABASE TestDB1 WITH RECOVERY
9. Al actualizar la base de datos, verá que TestDB1 en el servidor secundario ahora está en línea.
Estrategia de protección de datos más completa para SQL Server
Al implementar soluciones de recuperación ante desastres como el traslado de registros, las empresas suelen requerir una estrategia de protección de datos más completa y eficiente. Vinchin Backup & Recovery ofrece una solución automatizada de copia de seguridad y recuperación diseñada específicamente para máquinas virtuales y bases de datos como SQL Server, y admite copias de seguridad completas, incrementales y diferenciales. Gracias a sus tecnologías integradas de eliminación de duplicados y compresión de datos, reduce significativamente el consumo de almacenamiento y el tiempo de copia de seguridad.
Además, la solución de respaldo de Vinchin elimina la necesidad de intervenciones manuales complejas, permitiendo la protección automática de bases de datos y admitiendo la migración entre plataformas y el almacenamiento en la nube. En caso de un fallo en SQL Server, Vinchin ayuda a los administradores a restaurar rápidamente las bases de datos, evitando la pérdida de datos y tiempos prolongados de inactividad, ofreciendo así una garantía más completa de recuperación ante desastres para las empresas.
Para crear trabajos de copia de seguridad de la base de datos de SQL Server, vaya a la página Physical Backup > Database Backup > Backup:
1. Seleccione las bases de datos que deben respaldarse.
2. Seleccione un nodo de copia de seguridad en el que desee que se procesen y almacenen los datos de la copia de seguridad.
3. Configure estrategias de copia de seguridad según sus necesidades.
4. Revise y confirme la configuración.
Haga clic en el botón de abajo para probar la versión de prueba gratuita de 60 días de Vinchin y experimentar una solución eficiente y confiable para la copia de seguridad y recuperación de datos.
Preguntas frecuentes sobre la recuperación ante desastres de SQL Server
1. ¿Cuál es la diferencia entre alta disponibilidad (HA) y recuperación ante desastres (DR)?
HA garantiza un tiempo de inactividad mínimo mediante el uso de clústeres de conmutación por error, grupos de disponibilidad Always On o reflejo de la base de datos, mientras que DR se centra en restaurar el servicio después de fallos catastróficos, lo que suele implicar copias de seguridad externas o centros de datos secundarios.
2. ¿Qué es una instancia de clúster de conmutación por error de SQL Server (FCI) y cómo ayuda en la recuperación ante desastres (DR)?
Un FCI es una solución de alta disponibilidad que utiliza Windows Server Failover Clustering (WSFC) para proporcionar conmutación automática por error a nivel de instancia de SQL Server. Requiere almacenamiento compartido (SAN, Storage Spaces Direct o soluciones basadas en la nube). Es ideal para alta disponibilidad local, pero no es por sí solo una solución de recuperación ante desastres, ya que no protege contra fallos generalizados del sitio.
Conclusión
El traslado de registros (log shipping) es una solución económica, eficiente y sencilla para la recuperación ante desastres en SQL Server. Es una opción ideal para la recuperación ante desastres a nivel de base de datos. Sin embargo, para la recuperación ante desastres a nivel de instancia, se deben considerar otras técnicas de recuperación ante desastres, como el reflejado de bases de datos (database mirroring) o la agrupación de conmutación por error (failover clustering). Además, el traslado de registros puede provocar pérdida de datos. Si necesita recuperar datos eliminados o inaccesibles de una base de datos SQL dañada, considere utilizar una herramienta profesional para la recuperación de SQL.
