Recuperación a un punto en el tiempo: demostrar el resultado
Construya una cadena completa, elija un destino STOPAT justificable y compruebe los datos de negocio antes de abrir la base recuperada.
Recuperar a un punto en el tiempo significa decidir qué transacciones deben pertenecer a la base resultante. «Justo antes del borrado» todavía no es una instrucción ejecutable. El operador necesita una hora fiable, una cadena continua y una prueba de negocio que distinga el estado correcto de una base simplemente disponible. Este procedimiento supone el modelo de recuperación completa y copias de registro ya establecidas.
Definir el límite de negocio
Imagine que un despliegue elimina facturas equivocadas a las 14:30. El registro de la aplicación puede mostrar la llegada de la solicitud, mientras la transacción confirma después. El navegador del cliente puede utilizar otra zona horaria. Correlacione pruebas de la base, identificadores de solicitudes y cambios auditados antes de elegir el límite. Conserve la evidencia original en lugar de sobrescribir inmediatamente la base dañada.
Prefiera restaurar en paralelo con otro nombre y archivos físicos separados. Así conserva información para investigar y permite revisar el resultado con negocio. Reserve espacio y evite que tareas programadas o integraciones confundan la copia con producción. Recuperar SQL Server no deshace un pago ni un correo enviado a un sistema externo.
Documente la referencia temporal del procedimiento. La fecha del ejemplo representa la cronología comprobada del servidor; no declara que sea UTC. Una hora ambigua por cambio estacional exige un ensayo específico. Elegir automáticamente el segundo anterior también puede excluir confirmaciones legítimas que habrá que conciliar.
Montar y aplicar la secuencia
Empiece con una copia completa cuyo estado final sea anterior al objetivo. Añada una diferencial compatible si acorta la recuperación sin sobrepasar el destino, y después todos los registros necesarios hasta el que contiene ese momento. Importa la confirmación de la transacción: una operación iniciada antes pero confirmada después no debe aparecer como trabajo confirmado.
Examine encabezados y listas de archivos reales. Los nombres y las horas de finalización no demuestran continuidad. Identifique posiciones de conjuntos, todas las partes de copias repartidas, claves y nombres lógicos para MOVE. Una copia completa posterior al error no puede retroceder mediante STOPAT aplicado a un registro posterior.
La plantilla presupone una base aislada donde ya se restauraron la completa correcta y la diferencial opcional con NORECOVERY. Sustituya todas las rutas y repita la operación para cada registro necesario en orden. Mantenga el mismo destino durante toda la secuencia.
RESTORE LOG [RecoveryPractice]
FROM DISK=N'D:\Restore\required_log_001.trn'
WITH NORECOVERY, STOPAT='2025-05-12T14:29:59';
-- Repeat for every required log, with the same STOPAT.
-- Only after confirming that the target was reached:
-- RESTORE DATABASE [RecoveryPractice] WITH RECOVERY;
La base sin recuperar admite registros adicionales. Antes del paso final, compruebe que la cadena realmente alcanza el instante solicitado. Si el objetivo está después del último registro disponible, investigue los archivos que faltan. Una base todavía cerrada no demuestra éxito ni pérdida definitiva. En recuperación por medio de registros de operaciones masivas, el trabajo mínimamente registrado limita la elección de instantes dentro de la copia afectada.
Demostrar el resultado antes de abrir
Si la base original sigue accesible, evalúe una copia del final del registro para conservar transacciones todavía no respaldadas antes de una restauración destructiva. El método depende del estado y del objetivo. No improvise una sobrescritura con WITH REPLACE durante el incidente.
Después de recuperar, revise integridad y reglas de negocio: facturas afectadas presentes, operación incorrecta ausente, confirmaciones anteriores conocidas conservadas y totales conciliados. Registre las transacciones posteriores excluidas deliberadamente para repetirlas de manera controlada. El estado ONLINE no prueba esas condiciones.
Mida por separado diagnóstico, obtención de medios, restauración, validación y reconexión. Una contraseña ausente puede incumplir el plazo incluso con una restauración rápida. Guarde la secuencia exacta de archivos y las consultas de verificación del ensayo para que otro operador pueda reproducir la decisión sin depender de recuerdos.
Referencias técnicas: Microsoft Learn: Point-in-time restore · Microsoft Learn: Tail-log backups.