SQL Server en la práctica

Log shipping: medir recuperación, no solo tareas correctas

Distinga retrasos de copia de seguridad, transferencia y restauración, y ensaye la conmutación con una estimación fiable de pérdida de datos.

Log shipping permite mantener una copia de recuperación con componentes relativamente sencillos. Su principal trampa operativa es considerar una tarea correcta como prueba de que se cumple el objetivo de recuperación. Una tarea de copia puede terminar bien cuando el principal ya no genera archivos. Una restauración puede funcionar mientras el archivo más reciente permanece en otro servidor. La pregunta es cuánto se retrasa la base recuperable respecto al negocio.

Seguir un archivo por las tres etapas

Siga una copia concreta del registro desde su creación en el principal hasta su llegada y aplicación en el secundario. Registre identidad y horarios de cada etapa. Si las copias de seguridad son recientes pero los archivos transferidos son antiguos, revise recursos compartidos, almacenamiento y transferencia. Si llegan archivos pero no se aplican, investigue errores, predecesores ausentes, lectores o capacidad de restauración.

En una instancia configurada como monitor, esta consulta administrativa de solo lectura muestra el resumen. Ejecútela con los permisos necesarios. Examine juntos los resultados del principal y del secundario y compruebe que el monitor recibe información reciente.

USE master;
EXEC sys.sp_help_log_shipping_monitor;

Un registro antiguo puede significar un fallo de telemetría. Confirme historial local y archivos reales antes de actuar. Pero esa posibilidad tampoco permite descartar todas las alertas. Defina una antigüedad máxima aceptable y pruebe la entrega de notificaciones, no solo la existencia de una definición.

Con respaldos cada cinco minutos, transferencias cada dos y restauraciones cada dos, una transacción confirmada justo después del respaldo espera al siguiente ciclo. Después puede esperar ambas etapas posteriores. Los horarios no garantizan cinco minutos máximos de pérdida. Ejecución real, fallos, colas y archivos accesibles tras el incidente determinan el resultado.

Explicar retraso y retención

Un retraso deliberado puede mantener la copia antes de un borrado accidental durante un tiempo útil. La protección depende de detectar el problema antes de aplicar el cambio. No sustituye las copias conservadas de forma independiente: el descubrimiento puede ser tardío y un compromiso compartido puede afectar a varias copias.

Distinga la antigüedad del último archivo transferido y del último restaurado. La alerta de restauración debe contemplar el retraso configurado más una tolerancia justificada. La transferencia debe continuar igualmente. Una excepción general para sistemas retrasados podría ocultar una cadena detenida.

La retención debe cubrir retrasos, interrupciones razonables y tiempo de diagnóstico y recuperación del atraso. Si la limpieza elimina un registro necesario, un archivo posterior correcto no rellena el hueco. Coordine otros productos de respaldo. Una copia ordinaria del registro hecha por otra herramienta puede generar un archivo requerido que el proceso nunca transfiere. Asigne responsabilidad sobre la secuencia completa.

Ensayar el cambio de función

La conmutación es manual y controlada. Primero impida escrituras incompatibles en el antiguo principal. Si está disponible, evalúe una copia final del registro, transfiera y aplique todos los archivos necesarios accesibles. Si está perdido, documente el último estado recuperable y la incertidumbre sobre transacciones posteriores.

No finalice la recuperación simplemente para comprobar si la base abre. Después no puede continuar sin más la secuencia anterior. Restablecer la protección requiere un procedimiento. Determine cuándo dejar de esperar archivos, quién acepta la posible pérdida y cómo se redirigen los clientes.

STANDBY puede permitir lecturas entre restauraciones, pero los lectores pueden interferir si no se administra su desconexión. Pruebe el modo y la combinación de versiones admitida. Compruebe usuarios, tareas, conexiones y dependencias externas tras el cambio. Mida hasta la primera operación de negocio correcta y conserve la secuencia de medios y el tiempo observado como evidencia del ensayo.

Referencias técnicas: Microsoft Learn: Log shipping overview · Microsoft Learn: Monitor summary · Microsoft Learn: Manual failover.

Pregunta sobre este artículo

¿Tiene alguna pregunta sobre este tema?

Cuéntenos qué está evaluando o dónde tiene dificultades. Le responderemos con una recomendación práctica.

Inquiries are not enabled in this preview.

Hacer una pregunta sobre este artículo