SQL Server Envío de registros: Guía completa para administradores de bases de datos (DBA) [2026]

SQL Server El trasvase de registros es una solución automatizada de recuperación ante desastres que mantiene copias de seguridad de sus bases de datos de producción. Esta tecnología transfiere copias de seguridad de los registros de transacciones desde una base de datos principal en una instancia de servidor principal a una o más bases de datos secundarias en instancias de servidor secundarias independientes, garantizando así la sincronización de estas bases de datos con la principal y brindando protección contra la pérdida de datos y las fallas del servidor.

1.2 Propósito y beneficios del envío de registros

El envío de registros cumple múltiples propósitos críticos en la administración de bases de datos:

Su función principal es la recuperación ante desastres, proporcionando una conmutación por error confiable. tarObtenga información cuando su servidor principal no esté disponible debido a una falla de hardware, corrupción de software o eventos catastróficos que afecten su centro de datos.
También es acost-eficaz solución de alta disponibilidadA diferencia de las funciones de nivel empresarial que requieren licencias costosas, el envío de registros funciona con SQL Server Edición estándar, lo que la hace accesible para organizaciones con limitaciones presupuestarias.
Las bases de datos secundarias en modo de espera ofrecen un valor adicional más allá de la recuperación ante desastres. Los administradores de bases de datos pueden usarlas para generar informes de solo lectura, descargando así la carga de trabajo de consultas del servidor de producción.
La función de restauración diferida protege contra modificaciones accidentales de datos. Al configurar un retraso en la restauración, se crea un período de tiempo para recuperarse de los errores del usuario antes de que los cambios destructivos afecten a la base de datos secundaria.

2. SQL Server Componentes y flujo de trabajo del envío de registros

El envío de registros consta de los siguientes componentes:

Servidor principal y base de datos principal: El servidor principal representa su producción SQL Server instancia que ejecuta la base de datos principal.
Recurso compartido de respaldo: la ubicación intermedia para almacenar y transferir las copias de seguridad del registro de transacciones desde el servidor principal a los servidores secundarios.
Servidores secundarios y bases de datos secundarias: Los servidores secundarios host las copias de reserva en caliente de su base de datos principal.
Servidor de monitoreo (opcional): este servidor rastrea el historial y el estado de todas las operaciones de respaldo, copia y restauración en toda su topología de envío de registros.
Trabajos del agente: incluidos los trabajos de copia de seguridad, restauración y alerta, automatizando todo el proceso de envío de registros.

El flujo de trabajo de automatización es:

El trabajo de respaldo se ejecuta en el servidor principal y crea copias de seguridad del registro de transacciones de la base de datos principal en el recurso compartido de respaldo.
El trabajo de copia se ejecuta en cada servidor secundario y transfiere archivos de respaldo de registro desde el recurso compartido de respaldo a los servidores secundarios.
El trabajo de restauración se ejecuta en cada servidor secundario y aplica copias de seguridad del registro de transacciones a la base de datos secundaria.
El trabajo de alerta se ejecuta en el servidor de monitoreo y verifica si las operaciones de respaldo y restauración se completan dentro de plazos aceptables.

3. Prerrequisitos y requisitos

3.1 SQL Server Requisitos de la versión

El envío de registros está disponible desde SQL Server 2000 y sigue siendo compatible con todas las versiones posteriores a partir de SQL Server 2005 a 2025. Este apoyo de larga data demuestra la estabilidad y la relevancia continua de la tecnología.

3.2 SQL Server Requisitos de la edición

El envío de registros funciona con las ediciones Standard, Workgroup, Enterprise y Developer de SQL ServerEsta amplia compatibilidad con ediciones hace que el envío de registros sea accesible para organizaciones sin licencias de Enterprise Edition, a diferencia de funciones como Grupos de disponibilidad siempre activos que requieren ediciones Enterprise o Evaluation.

Nota: Express Edition no admite el envío de registros.

3.3 Requisitos del modelo de recuperación de la base de datos

El envío de registros requiere que la base de datos principal utilice el modelo de recuperación completa o el modelo de recuperación de registros masivos. El modelo de recuperación simple no es compatible porque SQL Server trunca automáticamente los registros de transacciones, rompiendo la cadena de registro continua necesaria para el envío de registros.

Para obtener más detalles sobre los modelos de recuperación, consulte nuestro guía completa sobre SQL Server copia de seguridad.

4. Configuración del envío de registros mediante SSMS

4.1 Crear carpeta para compartir copias de seguridad

Antes de configurar el envío de registros, prepare la carpeta compartida de respaldo donde se almacenarán y transferirán las copias de seguridad del registro de transacciones.

En el servidor principal o en un servidor de archivos dedicado, cree una carpeta (por ejemplo, C:\Copia de seguridad)
Haga clic derecho en la carpeta y seleccione Propiedades
Haga clic en la pestaña Compartir . Puede
Haga clic en Reparto adelantado
Comprobar Compartir esta carpeta
Haga clic en Permisos y otorgar control total permiso para el SQL Server cuenta de servicio Servicio NT\MSSQLSERVER.
Haga clic en OK Aplicar.
Documentar la ruta de red (UNC) (por ejemplo, \\NOMBRE-DEL-SERVIDOR\Copia de seguridad)

4.2 Habilitar y configurar el envío de registros

Haga clic derecho en la base de datos principal y seleccione Propiedades.
En el cuadro de diálogo Propiedades de la base de datos diálogo, seleccione el Envío de registros de transacciones página en el panel izquierdo.
Comprobar Habilite esto como una base de datos principal en una configuración de envío de registros para habilitar el envío de registros.
A continuación, puede configurar las opciones de copia de seguridad, el servidor secundario y el servidor de monitorización en esta página de propiedades. Los presentaremos en las siguientes subsecciones.

4.2.1 Configurar los ajustes de copia de seguridad

Haga clic en la pestaña Configuración de copia de seguridad en la
En el cuadro de diálogo Configuración de copia de seguridad del registro de transacciones diálogo, bajo Ruta de red a la carpeta de respaldo En el campo, ingrese la ruta UNC (por ejemplo, \\NOMBRE-DEL-SERVIDOR\Copia de seguridad)
Si la carpeta de respaldo reside en el servidor principal, ingrese la ruta local (por ejemplo, C:\Copia de seguridad)
Configure otros ajustes, como el período de retención de la copia de seguridad, el umbral de alerta, el trabajo de copia de seguridad y la compresión.
Haga clic en OK para confirmar la configuración y cerrar el cuadro de diálogo.

4.2.2 Configurar la instancia del servidor secundario y la base de datos

Haga clic en Agregar la extensión de bajo Instancias de servidor secundario y bases de datos
En el cuadro de diálogo Configuración de la base de datos secundaria diálogo, haga clic Conecta para conectarse a la instancia del servidor secundario.
En el cuadro de diálogo Base de datos secundaria En el menú desplegable, seleccione una base de datos existente o escriba un nuevo nombre de base de datos
En el cuadro de diálogo Inicializando la base de datos secundaria seleccione el módulo Sí, genere una copia de seguridad completa de la base de datos principal y restáurela en la base de datos secundaria (y cree la base de datos secundaria si no existe)
Haga clic en la pestaña Copiar archivos . Puede
En el cuadro de diálogo Carpeta de destino para los archivos copiados (esta carpeta normalmente se encuentra en el servidor secundario), ingrese la ruta local de la carpeta de destino en el servidor secundario.
Asegúrese de que la carpeta exista y SQL Server La cuenta de servicio tiene permisos de escritura
Haga clic en OK para confirmar la configuración y cerrar el cuadro de diálogo.

4.2.3 Configurar el servidor de monitorización

Comprobar Utilice una instancia de servidor de monitorización
Haga clic en Configuración
Haga clic en Conecta Para conectarse a la instancia del servidor de monitorización
Establecer Eliminar historial después para especificar el período de retención en horas
Haga clic en OK para confirmar la configuración y cerrar el cuadro de diálogo.

4.2.4 Revisión y finalización de la configuración

Revise todas las configuraciones en el Envío de registros de transacciones página
Verificar la configuración de respaldo, las configuraciones del servidor secundario y la configuración de monitoreo
Haga clic en OK para aplicar la configuración
El asistente crea todos los trabajos necesarios en los servidores primario, secundario y de monitoreo.
Haga clic en Cerrar cuando se complete la configuración

5. Ventajas y desventajas del envío de registros

5.1 beneficios de SQL Server Envío de troncos

Cost-Solución efectiva: Funciona con SQL Server Edición Estándar, que elimina los costosos requisitos de licencia de la Edición Empresarial. Esto facilita la recuperación ante desastres confiable para organizaciones con presupuestos limitados.
Fácil de configurar y mantener: El asistente de configuración guía a los administradores a través de la configuración con opciones claras. Most Las bases de datos se pueden configurar en 15 a 30 minutos sin necesidad de formación especializada.
Compatibilidad con varios servidores secundarios: Admite numerosos servidores secundarios sin limitaciones arquitectónicas. Implementa un servidor secundario para la recuperación ante desastres local, otro remoto y un tercero para la generación de informes.
Impacto mínimo en el servidor principal: Funciona de forma asíncrona, lo que elimina la sobrecarga de sincronización en el servidor principal. Los tiempos de confirmación de las transacciones no se ven afectados.
Utiliza copias de seguridad del registro de transacciones existentes: Las copias de seguridad de envío de registros son copias de seguridad de registros de transacciones estándar, que se pueden utilizar para la recuperación en un punto en el tiempo independientemente del envío de registros.
Opción de restauración retrasada: La función de retraso de restauración proporciona protección contra modificaciones accidentales de datos que no están disponibles en soluciones de replicación en tiempo real.
No se requiere almacenamiento compartido: Utiliza almacenamiento independiente en cada servidor, lo que elimina los requisitos de almacenamiento compartido y los costos asociados.osts.
Soporte multiplataforma: Funciona de forma idéntica tanto en Windows como en Linux. SQL Server despliegues
Funciona en todos los dominios: No requiere relaciones de confianza de dominio ni integración con Active Directory.

5.2 Desventajas y limitaciones del envío de registros

Sin conmutación por error automática: La principal limitación es la necesidad de conmutación por error manual. Los administradores deben ejecutar varios pasos antes de que se reanude el servicio.
Retraso en la sincronización de datos: Las bases de datos secundarias siempre van a la zaga de las bases de datos primarias en cuanto a la frecuencia de copias de seguridad y restauraciones.
Sólo configuración a nivel de base de datos: Se configura a nivel de base de datos, no de instancia. Proteger 50 bases de datos requiere 50 configuraciones independientes.
Cambios en la cadena de conexión manual: Las aplicaciones deben actualizar las cadenas de conexión para que apunten al servidor secundario después de la conmutación por error.
Interrupciones de la base de datos secundaria: Las bases de datos secundarias en modo de espera desconectan a los usuarios durante las operaciones de restauración.
Gestión de bases de datos independiente: Cada configuración de base de datos debe gestionarse individualmente sin capacidades de gestión coordinadas.

6. Mejores prácticas y casos de uso

6.1 Cuándo utilizar el envío de registros

Recuperación de desastres de bajo presupuesto: Sobresale como acost-Solución de recuperación ante desastres eficaz para organizaciones que no pueden justificar la licencia de Enterprise Edition.osts.
Requisitos de RPO/RTO moderados: Las aplicaciones que toleran entre 15 y 30 minutos de pérdida de datos y entre 30 y 60 minutos de inactividad se alinean perfectamente con sus capacidades.
Servidor de informes de solo lectura: Cree copias de solo lectura para informes de cargas de trabajo que toleran desconexiones periódicas.
Entornos de la edición estándar: Organizaciones estandarizadas en SQL Server La edición estándar no tiene acceso a grupos de disponibilidad siempre activa, lo que hace que el envío de registros sea la mejor opción disponible.
Proyectos de migración de servidores: Facilita las migraciones de servidores manteniendo copias sincronizadas durante los períodos de transición.
Requisitos de datos retrasados: Configure retrasos de restauración para mantener las bases de datos en puntos fijos en el pasado para fines de cumplimiento o auditoría.

6.2 Cuándo NO utilizar el envío de registros

Requisitos de tiempo de inactividad casi nulo: Las aplicaciones con requisitos de RTO inferiores a 15 minutos no pueden depender de la conmutación por error manual.
Conmutación por error automática necesaria: No es apropiado cuando los requisitos comerciales exigen una conmutación por error automática sin intervención del administrador.
Se requiere sincronización en tiempo real: Las aplicaciones que requieren datos en tiempo real o casi en tiempo real en servidores secundarios no pueden aceptar el retraso inherente del envío de registros.
Tolerancia mínima a la pérdida de datos: Las organizaciones con RPO medido en segundos o que requieren cero pérdida de datos necesitan soluciones sincrónicas.

6.3 mejores prácticas

Optimización de la frecuencia de copias de seguridad: Equilibrar la frecuencia de las copias de seguridad en función de la sobrecarga del sistema y los objetivos de recuperación.tart con intervalos de 15 minutos y ajustar según los requisitos reales.
Consideraciones sobre la ruta de red: Utilice rutas UNC en lugar de unidades asignadas para las ubicaciones de las copias de seguridad. Coloque los recursos compartidos de copia de seguridad en una infraestructura de red fiable.
Configuración de monitoreo y alertas: Configure alertas para errores en los trabajos de copia de seguridad, copia y restauración inmediatamente después de completar la configuración del envío de registros.
Calendario de pruebas regulares: Programe pruebas de conmutación por error trimestrales o semestrales para validar los procedimientos y mantener la preparación del administrador.
Mantenimiento de documentación: Mantener libros de ejecución detallados que documenten los detalles de configuración, los procedimientos de conmutación por error y los pasos de solución de problemas.
Consideraciones de Seguridad: Utilice cuentas de servicio dedicadas con los permisos mínimos necesarios. Restrinja los permisos de recursos compartidos de red según corresponda.
Gestión del espacio en disco: Monitoree continuamente el espacio en disco en las ubicaciones de respaldo. Configure alertas cuando el espacio caiga por debajo del 20 %.
Configuración de la política de retención: Establezca períodos de retención de copias de seguridad más largos que el retraso de sincronización máximo aceptable.
Retraso de restauración para protección: Configure retrasos de restauración cuando la protección contra modificaciones accidentales justifique un mayor retraso de sincronización.

7. Solución de problemas comunes

7.1 Errores en los trabajos de copia de seguridad

Espacio en disco insuficiente: Revise el historial de trabajos para detectar errores de espacio en disco. Verifique el espacio disponible y libre eliminando copias de seguridad antiguas o activando la compresión.
Problemas de permisos: Verificar el SQL Server La cuenta de servicio tiene permisos de control total tanto en la carpeta local como en el recurso compartido de red.
Base de datos no en recuperación completa: Vuelva al modelo de recuperación completa y realice una copia de seguridad completa para restaurarlo.tart la cadena de registro de transacciones.

7.2 Errores en los trabajos de copia

Ruta de red inaccesible: Pruebe la conectividad desde el servidor secundario asignando manualmente la ruta de red.
Problemas de autenticación: Configure credenciales explícitas para el acceso a recursos compartidos de red si los servidores están en dominios diferentes.
Problemas de bloqueo de archivos: Excluye la carpeta de respaldo del análisis antivirus en tiempo real para evitar bloqueos de archivos.

7.3 Errores de restauración de trabajos

Archivos de respaldo faltantes: Verifique que los archivos existan en la carpeta de destino y verifique el historial de trabajos de copia.
Error de secuencia de restauración: Identifique las copias de seguridad del registro de transacciones faltantes y restáurelas en secuencia para reparar la cadena de registro.
Base de datos en estado incorrecto: Reinicialice el envío de registros restaurando una copia de seguridad completa con NORECOVERY si alguien recuperó la base de datos.
Corrupción de archivos de base de datos: Si los fallos de restauración persisten a pesar de la secuencia y configuración correctas, es posible que los archivos de la base de datos estén dañados. En tales casos, puede que necesite usar un servicio especializado. herramienta de recuperación de SQL para extraer datos de los archivos .MDF y .NDF dañados antes de intentar reinicializar el envío de registros.

7.4 Problemas de retraso en la sincronización

Limitaciones del ancho de banda de la red: Habilite la compresión de respaldo para reducir el tamaño de los archivos y los requisitos de ancho de banda.
Alto volumen de transacciones: Considere aumentar la frecuencia de las copias de seguridad para crear archivos de copia de seguridad más pequeños y manejables.
Frecuencia de restauración inadecuada: Aumente la frecuencia de los trabajos de restauración para aproximarse a la frecuencia de las copias de seguridad y minimizar el retraso.

7.5 Supervisión de problemas de conectividad del servidor (SQL 2025)

Errores del proveedor OLE DB: SQL Server El cifrado obligatorio predeterminado de 2025 entra en conflicto con instancias más antiguas que carecen de una configuración de cifrado adecuada.
Configuración de cifrado no coincidente: Verifique la configuración del servidor vinculado en el servidor de monitoreo y verifique la configuración de cifrado.
Soluciones alternativas: Elimine y vuelva a crear el envío de registros mediante parámetros TLS 1.3 o actualice todas las instancias a SQL Server 2025.

7.6 SQL Server Problemas con el servicio del agente

Servicio No StarTed: Verifique el estado del servicio del Agente y configúrelo para que funcione.tart automáticamente.
Horario de trabajo deshabilitado: Verificar el estado del cronograma de trabajo y habilitar los cronogramas deshabilitados.
Errores en los pasos del trabajo: Revise el historial de trabajo para identificar pasos fallidos y mensajes de error específicos.

8. Preguntas frecuentes (FAQ)

P: ¿Puedo utilizar el envío de registros con Express Edition?

A: no SQL Server Express Edition no admite el envío de registros porque carece de SQL Server Agente.

P: ¿Con qué frecuencia debo programar copias de seguridad de registros?

R: Los intervalos predeterminados de 15 minutos proporcionan un equilibrio razonable. Ajústelos según su objetivo de recuperación.

P: ¿Se pueden utilizar bases de datos secundarias para elaborar informes?

R: Sí, las bases de datos secundarias configuradas en modo de espera permiten acceso de solo lectura entre operaciones de restauración.

P: ¿Qué sucede si falla el servidor principal?

A: Ejecute una conmutación por error manual para poner en línea una base de datos secundaria. La pérdida de datos equivale al retraso de sincronización en el momento del fallo.

P: ¿Puedo tener varios servidores secundarios?

R: Sí, el envío de registros admite servidores secundarios ilimitados con configuraciones independientes.

P: ¿Cómo calculo el retraso de sincronización?

A: Compare la marca de tiempo del último registro de transacciones restaurado con la hora actual utilizando tablas de monitoreo de envío de registros.

P: ¿Puede el envío de registros funcionar en diferentes dominios?

R: Sí, funciona en diferentes dominios o en entornos de grupos de trabajo sin requerir relaciones de confianza.

P: ¿Cuál es la diferencia entre el modo Sin recuperación y el modo de espera?

R: El modo sin recuperación mantiene la base de datos inaccesible. El modo de espera permite consultas de solo lectura entre restauraciones.

P: ¿Puedo pausar el ritmo de envío de registros?rar¿Ily?

R: Sí, deshabilite los trabajos de copia de seguridad, copia y restauración para pausar la sincronización y conservar la configuración.

P: ¿Cómo puedo eliminar la configuración de envío de registros?

A: En el Envío de registros de transacciones página de propiedades:

Desmarcar Habilite esto como una base de datos principal en una configuración de envío de registros
Haga clic en OK para eliminar la configuración y eliminar trabajos.

P: ¿Puedo cambiar la base de datos secundaria al modo de lectura-escritura?

R: Sí, ejecute RESTORE DATABASE WITH RECOVERY, pero esto rompe la cadena de envío de registros.

P: ¿Cuál es el retraso máximo que puedo configurar para la restauración?

R: No existe un límite estricto. Configure retrasos de minutos a días según sus requisitos de protección.

P: ¿Cómo afecta el envío de registros a la estrategia de backup?

A: Crea copias de seguridad del registro de transacciones que se pueden utilizar tanto para el envío de registros como para la recuperación en un punto determinado del tiempo.

P: ¿Puedo utilizar el envío de registros para la migración del servidor?

R: Sí, configure el envío de registros al nuevo servidor, sincronice y luego realice una conmutación por error planificada del servidor antiguo durante el mantenimiento.

P: ¿Qué herramientas de monitoreo funcionan con el envío de registros?

A: SQL Server Management Studio incluye informes integrados. Herramientas de terceros como SQL Monitor y SolarWinds ofrecen una monitorización mejorada.

9. Conclusión y recomendaciones

9.1 Resumen de puntos clave

SQL Server El envío de registros proporciona un control confiable y fiableostRecuperación ante desastres eficaz mediante operaciones automatizadas de copia de seguridad y restauración de registros de transacciones. La tecnología funciona con la Edición Estándar, requiere una infraestructura mínima y admite varios servidores secundarios.

El envío de registros es excelente para objetivos de recuperación moderados donde la conmutación por error manual es aceptable. Las principales limitaciones incluyen el requisito de conmutación por error manual, el retraso en la sincronización y el alcance de la configuración a nivel de base de datos.

La tecnología se integra bien con las estrategias de respaldo existentes, admite informes de solo lectura a través del modo de espera y brinda protección de restauración retrasada contra cambios accidentales.

9.2 Cómo elegir la opción adecuada para su entorno

Evalúe el envío de registros según sus requisitos específicos antes de la implementación. Considere los objetivos de punto de recuperación, los objetivos de tiempo de recuperación, las limitaciones presupuestarias y la tolerancia a la complejidad operativa.

Organizaciones que utilizan SQL Server La Edición Estándar con requisitos de recuperación moderados debería considerar seriamente el envío de registros. Las empresas con un RTO estricto inferior a 15 minutos deberían evaluar los Grupos de Disponibilidad Siempre Activa.

Considere enfoques híbridos que combinen el envío de registros con otras tecnologías para cost Optimización al tiempo que se satisfacen diversos requisitos.

9.3 Próximos pasos y recursos adicionales

Comience con implementaciones piloto a pequeña escala para adquirir experiencia. Desarrolle documentación completa, que incluya detalles de configuración, procedimientos de conmutación por error y guías de solución de problemas.

Programe pruebas de conmutación por error periódicas para validar los procedimientos y mantener la disponibilidad del administrador. Manténgase al día con SQL Server Actualizaciones y mejoras.

Referencias

Documento oficial de Microsoft: Acerca del envío de registros (SQL Server)
Documento oficial de Microsoft: Configurar el envío de registros (SQL Server)

Sobre el Autor

Yuan Sheng es un administrador de bases de datos senior (DBA) con más de 10 años de experiencia en SQL Server Entornos y gestión de bases de datos empresariales. Ha resuelto con éxito cientos de escenarios de recuperación de bases de datos en organizaciones de servicios financieros, atención médica y manufactura.

Yuan se especializa en SQL Server Recuperación de bases de datos, soluciones de alta disponibilidad y optimización del rendimiento. Su amplia experiencia práctica incluye la gestión de bases de datos multiterabyte, la implementación de Grupos de Disponibilidad Siempre Activa (AVA) y el desarrollo de estrategias automatizadas de backup y recuperación para sistemas empresariales críticos.

Gracias a su experiencia técnica y su enfoque práctico, Yuan se centra en crear guías integrales que ayuden a los administradores de bases de datos y a los profesionales de TI a resolver problemas complejos. SQL Server Aborda los desafíos de manera eficiente. Se mantiene al día con las últimas novedades. SQL Server versiones y las tecnologías de bases de datos en evolución de Microsoft, probando periódicamente escenarios de recuperación para garantizar que sus recomendaciones reflejen las mejores prácticas del mundo real.

¿Tiene preguntas acerca SQL Server ¿Necesita ayuda adicional para la recuperación de la base de datos o para solucionar problemas? Yuan le da la bienvenida. comentarios y sugerencias para mejorar estos recursos técnicos.