Restauración SQL en NetBackup: logs parcialmente correctos

Una restauración de SQL Server en NetBackup puede mostrar un estado de "éxito parcial" incluso cuando los archivos de la base de datos y los registros de transacciones aparecen en las carpetas previstas. En el caso analizado, el problema radicaba en la plantilla por lotes de restauración: varias secciones todavía requerían descomentar líneas, actualizar rutas de destino y ajustar correctamente el estado final de recuperación.

Por eso, el diagnóstico de restauraciones en SQL debe separar la colocación física de archivos del estado de recuperación de la base de datos. Ver archivos .mdf y registros en el disco demuestra que una parte de la restauración se ejecutó, pero no confirma si el script de restauración completo finalizó según lo previsto.

¿Por qué puede funcionar una restauración y aun así ser parcialmente correcta?

NetBackup evalúa la operación de restauración en su conjunto, y que algunos archivos aparezcan en disco es solo una parte del proceso. Un script por lotes puede completar un tramo de la recuperación mientras otra sección se omite, permanece comentada, presenta errores de sintaxis o queda en un estado de recuperación incorrecto.

El administrador del debate creó una plantilla con MOVE y configuró los transaction logs para que se mantuvieran sin recuperar. La base de datos y los logs aparecieron en la ubicación esperada, pero el trabajo devolvió una condición de éxito parcial acompañada de mensajes confusos de User e Inf.

Un participante habitual de NetBackup aconsejó revisar el propio script por lotes. La solución consistió en descomentar las secciones necesarias, actualizar las rutas de destino y definir de forma adecuada el estado de recuperación para cada fase.

Ese es un orden de diagnóstico prudente: valida la sintaxis del script y la secuencia de restauración antes de suponer que el soporte, SQL Server o la imagen de backup están dañados.

¿Qué conviene revisar en una plantilla de MOVE en NetBackup para SQL?

Comprueba cada sección MOVE que asocia los archivos originales de SQL Server con su destino de restauración. La documentación de SQL Server en NetBackup muestra que una plantilla generada puede contener líneas TO comentadas y rutas de ejemplo que deben editarse cuando se traslada la base de datos.

Presta atención a las repeticiones. Una restauración que involucra una base de datos completa más imágenes diferenciales o de transaction log puede incluir varias secciones que requieren cambios coherentes. Arreglar únicamente la primera ruta del archivo .mdf no basta si los bloques posteriores de restauración de logs aún conservan comentarios de la plantilla o destinos antiguos.

Revisa el nombre lógico del archivo de la base de datos, la ruta física de destino y si la línea correspondiente está activa o sigue comentada. Haz exactamente lo mismo con los archivos de datos y los archivos de log.

Guarda una copia limpia del script definitivo. Una plantilla de restauración constituye código de recuperación en producción, por lo que debes gestionarla como código, con control de versiones o al menos en un runbook validado, en vez de recurrir a un archivo improvisado durante una incidencia.

¿Qué hace NORECOVERY durante la restauración de transaction logs?

Una secuencia de restauración en SQL Server normalmente mantiene la base de datos en estado de restauración mientras aún queden imágenes de backup pendientes de aplicar. En las plantillas de NetBackup, los pasos intermedios deben recurrir al comportamiento equivalente a NORECOVERY de SQL Server para que el siguiente backup diferencial o transaction log pueda continuar la cadena.

El último paso funciona de otra manera. Cuando se aplica el último log necesario, la base de datos debe recuperarse para que SQL Server la ponga en línea. Si el último paso se deja sin recuperar, los archivos pueden estar presentes pero la restauración parecerá inconclusa desde la perspectiva de la aplicación.

El administrador de Reddit tropezó con esta complicación en la segunda fase. Tras lograr que el script se ejecutara, la base de datos seguía sin estar en línea a pesar de haber especificado la recuperación en las secciones de transaction log. Comprueba con atención el estado de recuperación de la última operación de restauración, ya que revisar cada bloque de manera aislada no basta.

Utiliza el propio SQL Server para confirmar el estado de la base de datos una vez que el trabajo de NetBackup haya terminado.

¿Por qué resulta más sencillo el flujo de recuperación de la Web UI?

Los puntos de recuperación en la Web UI de NetBackup reducen la cantidad de modificaciones manuales de plantillas en los flujos compatibles de SQL Server. La documentación actual permite al administrador seleccionar un punto de recuperación completo, diferencial o de transaction log, y elegir un punto de recuperación concreto, otro momento en el tiempo o una marca de transacción.

Eso ayuda sobre todo cuando el objetivo es una recuperación a un punto específico y no un traslado complejo de base de datos. La interfaz guía la secuencia de restauración y la selección del destino sin necesidad de que el operador edite a mano cada sección del archivo por lotes.

El participante del debate calificó el método de lotes como tradicional y sugirió la Web UI porque automatiza buena parte de la configuración de recuperación. Es una alternativa razonable siempre que la versión de NetBackup y la configuración de SQL admitan ese flujo de trabajo.

Aun así, conviene conservar el dominio de los scripts. Las plantillas por lotes siguen siendo útiles para la automatización repetible, traslados complejos a rutas alternativas y entornos donde la recuperación debe documentarse al margen de la interfaz gráfica.

¿Cómo debe validarse la recuperación a un momento dado?

Define el objetivo exacto antes de empezar. Decir "restaurar la base de datos de ayer" es ambiguo, mientras que "recuperar la base de datos a las 14:04:30 antes de la transacción errónea" es un criterio verificable.

Confirma que el backup completo, los diferenciales oportunos y la cadena requerida de transaction logs existan hasta ese punto temporal. A continuación, ejecuta la restauración siguiendo el flujo admitido de NetBackup y verifica el estado final de la base de datos en SQL Server.

Una vez que la base de datos pase a estar en línea, realiza comprobaciones a nivel de aplicación. Verifica las tablas esperadas, los registros recientes, los inicios de sesión, los trabajos programados y los servicios dependientes, ya que una base de datos marcada en línea puede encontrarse en un punto de recuperación erróneo.

El enfoque por capas de recuperación que se detalla en la guía de backup de VM frente a backup de base de datos cobra importancia por esta misma razón. La restauración de una VM devuelve el servidor completo, mientras que la restauración de transaction logs responde a una necesidad mucho más precisa en la base de datos.

¿Qué registros y evidencias conviene guardar tras una restauración con éxito?

Guarda la plantilla final operativa o documenta las opciones exactas seleccionadas en la Web UI. Registra los identificadores de backup o puntos de recuperación utilizados, el destino de la restauración, la hora de parada, el estado de recuperación y la verificación en SQL Server que demostró el éxito.

Apunta también el motivo por el cual el trabajo original arrojó un resultado parcial. Si la causa raíz fueron secciones comentadas en la plantilla, anótalo con claridad, o el próximo administrador podría interpretar la misma advertencia como corrupción de medios e iniciar una investigación mucho más extensa.

En el caso de bases de datos críticas, repite la recuperación en un entorno de pruebas. La guía de Proxmox Backup Server aborda otra plataforma, pero el principio operativo es idéntico: los procedimientos de recuperación solo resultan fiables cuando se han ensayado.

Mide el tiempo de restauración además de su exactitud. Un script que funciona pero exige seis horas de diagnóstico en cada incidente no cumple el objetivo operativo fijado.

¿Qué haría yo ante una restauración de transaction logs con éxito parcial?

Dejaría de alterar el almacenamiento o las políticas de backup y examinaría primero la definición de la restauración. En una restauración por lotes, compararía cada MOVE, ruta de destino, marca de comentario y campo de estado de recuperación frente a una plantilla conocida y frente a la estructura actual de SQL Server.

Si el propósito es una recuperación habitual a un momento dado y la versión de NetBackup lo admite, probaría el flujo de puntos de recuperación de la Web UI porque reduce la edición manual. Tras la restauración, verificaría que SQL Server muestre la base de datos en línea y que los datos correspondan al punto previsto.

Un mensaje de éxito parcial no equivale automáticamente a una recuperación fallida. Simplemente indica que el flujo completó una parte de lo que solicitaba el script, por lo que conviene localizar el paso pendiente antes de volver a lanzar la cadena completa.