Recuperación de SQL Server: prácticas recomendadas para la restauración de bases de datos

La definición de un administrador de bases de datos (DBA) de una restauración satisfactoria

Un administrador de bases de datos con el que trabajé en su día me dio su definición de una restauración satisfactoria: «La base de datos está operativa, la aplicación puede realizar consultas en ella y no he tenido que recurrir al equipo de asistencia del proveedor de copias de seguridad para conseguirlo». Se trata de un listón más alto del que alcanzan la mayoría de las demostraciones de los proveedores.

La brecha entre lo que los proveedores de copias de seguridad denominan «recuperación de SQL Server» y lo que los administradores de bases de datos realmente necesitan es una de las discrepancias más arraigadas de nuestro sector. Los proveedores hablan de archivos de copia de seguridad. Los administradores de bases de datos necesitan una base de datos operativa que atienda consultas, con el estado de recuperación adecuado, los metadatos de la aplicación y la configuración de la instancia. No son lo mismo, y la diferencia cobra mayor importancia cuando se realiza una restauración bajo presión.

Este artículo recoge lo que le diría a un compañero que me preguntara cómo enfocar la recuperación de SQL Server en 2026, basándome en la experiencia de equipos a los que he visto triunfar y en los errores que he observado y que han supuesto una pérdida de semanas. 

Copia de seguridad, restauración, recuperación: tres términos, tres conceptos distintos

La copia de seguridad es el acto de capturar una copia de la base de datos en un momento determinado. Completa, diferencial, de registro de transacciones o de grupo de archivos.

La restauración es el acto de volver a escribir una copia de seguridad en una instancia de SQL Server, aplicando la cadena de copias de seguridad adecuada y poniendo la base de datos en línea.

La recuperación es el resultado operativo. La base de datos está en línea, es transaccionalmente coherente y atiende las consultas correctamente. La copia de seguridad y la restauración son mecanismos. La recuperación es el resultado.

Una copia de seguridad que existe pero que no se puede restaurar no es una copia de seguridad. Una restauración que se completa pero que deja la base de datos inutilizable no es una recuperación. Los administradores de bases de datos de SQL Server distinguen estos conceptos cuidadosamente, ya que la diferencia supone la diferencia entre un incidente resuelto y una interrupción prolongada del servicio. 

Modelos de recuperación y lo que permiten

SQL Server cuenta con tres modelos de recuperación. La elección determina qué opciones de restauración están disponibles. Elegir el modelo incorrecto es una de las causas más comunes de las conversaciones del tipo «en realidad no podemos recuperarnos hasta ese momento concreto». 

Las bases de datos de producción con una actividad transaccional significativa suelen ejecutarse en modo Completo. Las bases de datos de informes que pueden tolerar una mayor pérdida de datos suelen funcionar en modo «Simple». El modelo de recuperación se configura por base de datos, no por instancia. Compruébelo explícitamente en cada base de datos de producción, ya que el valor predeterminado del modelo de la base de datos depende de la edición de SQL Server y de las opciones de instalación. 

Los cuatro escenarios de restauración a los que se enfrentan realmente los administradores de bases de datos

La mayor parte de las recuperaciones de SQL Server en producción se enmarcan en uno de estos cuatro escenarios. Estar preparado para la recuperación implica disponer de un procedimiento probado para cada uno de ellos.

Restauración completa de la base de datos en la instancia original

El caso más sencillo. Es necesario restaurar una base de datos en la misma instancia de la que se realizó la copia de seguridad, normalmente para recuperarse de un daño en los datos, un ataque de ransomware o una pérdida significativa de datos. La cadena de restauración consiste en una copia de seguridad completa, más la copia diferencial más reciente y todas las copias de seguridad de registros de transacciones posteriores. Si el origen es recuperable, realice primero una copia de seguridad del registro de cola para minimizar la pérdida de datos. 

Recuperación a un momento determinado (PITR)

Un comando TRUNCATE TABLE accidental en la base de datos equivocada, una implementación defectuosa que ejecutó un script destructivo o un incidente de cifrado por ransomware. Estos casos requieren una recuperación a un momento específico, no solo a la última copia de seguridad completa. La PITR requiere un modelo de recuperación «Completo» o «Con registro masivo» y una cadena de registros de transacciones intacta que se remonte hasta el punto de recuperación. La razón por la que la mayoría de las organizaciones no pueden recuperarse en el momento que necesitan no es una laguna en las copias de seguridad. Se debe a una cadena de registros rota o a una base de datos que se ha dejado accidentalmente en el modo de recuperación «Simple».

Restauración a una instancia diferente de SQL Server

Es necesaria cuando la instancia original no está disponible debido a un fallo de hardware o a un compromiso de la infraestructura, o cuando los administradores de bases de datos (DBA) necesitan recuperar una base de datos en un entorno paralelo sin interrumpir la producción. El destino puede ser una instancia diferente en el mismo servidor (DEV, UAT, PROD) o un servidor físico distinto. Los inicios de sesión, los trabajos y los objetos a nivel de instancia no forman parte de las copias de seguridad de la base de datos y requieren un tratamiento independiente.

Restauración en un entorno diferente para desarrollo, pruebas o análisis forense

Los datos de producción deben trasladarse a entornos de menor nivel para su desarrollo, pruebas o análisis forense tras un incidente. El destino se separa intencionadamente de la producción: un servidor distinto, una red diferente y, a menudo, con enmascaramiento de datos de carácter personal (PII) aplicado tras la restauración. Las capacidades de clonación que crean copias consistentes con la aplicación de los datos de producción sin alterar el origen constituyen el modelo adecuado.

Por qué la copia de seguridad a nivel de máquina virtual no equivale a la recuperación de la base de datos

La mayoría de las herramientas genéricas de copia de seguridad de máquinas virtuales anuncian la protección de SQL Server. Lo que realmente ofrecen es una copia de seguridad a nivel de máquina virtual con instantáneas consistentes ante fallos o coordinadas mediante VSS, y un conjunto de soluciones provisionales para la restauración. Las más habituales son:

«Disponemos de recuperación instantánea de la máquina virtual a partir de los datos de copia de seguridad; solo tiene que poner en marcha su máquina virtual de SQL y utilizar los datos como prefiera». 

«Podemos compartir sus archivos de base de datos a través de SMB desde el destino de la copia de seguridad, para que pueda montarlos y utilizarlos como desee».

Ambas opciones le permiten acceder a los datos. Ninguna de ellas restaura una base de datos. Montar un par de archivos .mdf y .ldf en una instancia de SQL Server puede funcionar en algunos casos, pero no es lo mismo que una restauración adecuada de la base de datos con la cadena de copias de seguridad correcta, el estado de recuperación adecuado y los metadatos de la aplicación. Existe una forma útil de plantearlo: es la diferencia entre encontrar los datos y guardarlos. Entre hacer que los archivos sean accesibles y recuperar la base de datos en pleno funcionamiento para que pueda atender consultas.

La copia de seguridad orientada a aplicaciones comprende el funcionamiento de SQL Server. Sabe qué bases de datos residen en qué máquina virtual, qué modelo de recuperación utiliza cada una, cómo coordinarse con el VSS Writer de SQL Server para obtener instantáneas coherentes con la aplicación y cómo restaurar en la instancia correcta con el estado adecuado de la base de datos. La diferencia arquitectónica se manifiesta en la complejidad de la restauración. Las herramientas orientadas a las aplicaciones le proporcionan una base de datos. Las herramientas orientadas a las máquinas virtuales le proporcionan archivos.

Seis prácticas que distinguen una recuperación fiable del mero descubrimiento de incidencias

Tras observar un número suficiente de recuperaciones de SQL Server, se observa que las mismas seis prácticas están presentes en todos los equipos que llevan a cabo recuperaciones impecables bajo presión. No son nada extraordinario. Simplemente se aplican de forma coherente.

Configure todas las bases de datos de producción con el modelo de recuperación «Completo», a menos que tenga una razón específica para no hacerlo. La recuperación «Simple» impide la recuperación a un momento determinado (PITR). Si una base de datos realmente no necesita PITR, documente dicha decisión. No deje que sea una casualidad.

Realice copias de seguridad del registro de transacciones con la periodicidad que su RPO realmente requiera. Es habitual realizar copias de seguridad del registro cada 15 minutos para los sistemas de nivel 1. Cada hora es el mínimo para la mayoría de las bases de datos de producción. La cadena de registros es lo que permite la recuperación a un punto en el tiempo (PITR).

Verifique las copias de seguridad con RESTORE VERIFYONLY o la comprobación equivalente de la plataforma. Una copia de seguridad que no se pueda restaurar no es protección. La verificación detecta la corrupción, los archivos que faltan y las cadenas rotas antes de que se conviertan en fallos de recuperación. 

Realice una copia de seguridad del final del registro antes de la restauración cuando se pueda acceder al origen. Si los archivos originales de la base de datos siguen siendo legibles, capturar el final del registro antes de la restauración minimiza la pérdida de datos a unos pocos segundos.

Utilice instantáneas consistentes con la aplicación, no consistentes con el fallo. Las copias de seguridad consistentes con la aplicación se coordinan con el VSS Writer de SQL Server, ponen la base de datos en estado de reposo correctamente y garantizan que la instantánea se tome en un momento transaccionalmente consistente. Las copias de seguridad consistentes con el fallo requieren un esfuerzo de recuperación tras la restauración y pueden fallar directamente en el caso de bases de datos activas.

Realice pruebas de restauración trimestralmente en una instancia o servidor diferente. Comprobar la integridad de la copia de seguridad no es lo mismo que probar la restauración. La única forma de saber si la recuperación funciona es llevarla a cabo, idealmente restaurando una base de datos de producción a un entorno que no sea de producción según un calendario definido. Realice un seguimiento del tiempo de restauración como métrica clave.

Con agente frente a sin agente: la disyuntiva arquitectónica

Las arquitecturas tradicionales de copia de seguridad de SQL Server instalaban un agente en cada servidor protegido. El agente se encargaba de la copia de seguridad con reconocimiento de SQL, la coordinación con VSS y la orquestación de la restauración. Funcionaba, pero suponía una carga operativa. Era necesario instalar, actualizar, aplicar parches y solucionar problemas en los agentes de todos y cada uno de los servidores protegidos. En entornos con cientos de máquinas virtuales de SQL, el mantenimiento de los agentes se convierte en un coste real y continuo. Un agente desactualizado es una vulnerabilidad de la que nadie tiene constancia. 

Las arquitecturas sin agentes gestionan las copias de seguridad y la restauración de SQL Server a través de API a nivel de hipervisor y la integración con la plataforma, sin necesidad de instalar software en las máquinas virtuales protegidas. La ventaja es la simplicidad operativa a gran escala. No hay que instalar nada, ni actualizar nada, ni existe el riesgo de que algo falle durante un «Patch Tuesday». El reto de los enfoques sin agentes ha sido, históricamente, el reconocimiento de las aplicaciones. Las copias de seguridad puras a nivel de máquina virtual no tienen conocimiento de las aplicaciones y recurren a las soluciones provisionales que he descrito anteriormente.

Las plataformas modernas sin agente resuelven el problema del reconocimiento mediante la integración directa con las API del hipervisor y del almacenamiento, la coordinación con el VSS Writer de SQL Server para garantizar la coherencia de las aplicaciones y el mantenimiento del reconocimiento a nivel de base de datos sin necesidad de ningún software en la propia máquina virtual de SQL Server. El resultado es una copia de seguridad y restauración con reconocimiento de SQL, que permite la recuperación en un momento determinado, la restauración en una instancia diferente y la restauración en un servidor diferente, sin necesidad de mantener agentes.

Prueba de sus procedimientos de recuperación

La causa más común del fallo en la recuperación de SQL Server no es un fallo en la copia de seguridad, sino un fallo en el procedimiento. La tarea de copia de seguridad se completó con éxito todas las noches durante dos años, pero nadie había ejecutado realmente el procedimiento de restauración documentado de principio a fin. Cuando se produjo el incidente, los pasos eran incorrectos, faltaban dependencias o el destino de recuperación no tenía el tamaño adecuado para la carga de trabajo.

Un programa eficaz de pruebas de recuperación de SQL Server consta de tres componentes. Pruebas de restauración programadas de las bases de datos de producción a un entorno que no sea de producción, como mínimo trimestralmente y mensualmente para los sistemas de nivel 1. Métricas de tiempo de restauración supervisadas que se tienen en cuenta en la planificación del RTO. Y simulacros teóricos o en vivo que incluyan los pasos humanos: vías de escalado, comunicación y toma de decisiones. No solo la restauración técnica.

Si su equipo no puede indicarle con seguridad cuánto tiempo lleva una restauración completa de su mayor base de datos de producción, su RTO es teórico. La forma más rápida de averiguarlo es hacerlo.

Preguntas frecuentes sobre la recuperación de SQL Server

¿Cuál es la diferencia entre la copia de seguridad de SQL Server y la recuperación de SQL Server?

La copia de seguridad consiste en capturar una copia. La restauración consiste en volver a escribir esa copia. La recuperación es el estado resultante de disponer de una base de datos utilizable y en la que se puedan realizar consultas. Una copia de seguridad correcta que no se pueda restaurar a una base de datos utilizable no constituye una protección.

¿Puedo realizar una recuperación a un momento determinado con cualquier herramienta de copia de seguridad? 

No. La recuperación a un momento determinado (PITR) requiere que la base de datos utilice el modelo de recuperación «Completo» o «Bulk-Logged», una cadena intacta de copias de seguridad del registro de transacciones que cubra la ventana de recuperación deseada y una herramienta de copia de seguridad que sepa cómo aplicar dicha cadena. Las instantáneas de máquinas virtuales consistentes ante fallos le proporcionan el estado en los momentos de la instantánea, no en puntos arbitrarios entre ellos. 

¿Es necesario instalar un agente en cada servidor SQL Server para realizar su copia de seguridad?

No, con las plataformas modernas sin agentes. Las arquitecturas sin agentes se coordinan con el VSS Writer de SQL Server a través de las API del hipervisor y del almacenamiento, lo que permite realizar copias de seguridad con reconocimiento de aplicaciones y restauraciones a nivel de base de datos sin necesidad de instalar software en las máquinas virtuales protegidas. 

¿Puedo restaurar una base de datos de SQL Server en un servidor o instancia diferente?

Sí, con la herramienta adecuada. Las copias de seguridad de bases de datos son portables entre instancias y servidores. Los objetos a nivel de instancia (inicios de sesión, tareas, servidores vinculados) no forman parte de las copias de seguridad de bases de datos y deben migrarse por separado. 

Pruébelo en su entorno

HYCU ofrece copias de seguridad de SQL Server sin agentes y adaptadas a las aplicaciones en Nutanix AHV, VMware ESXi y Nutanix-on-VMware. Recuperación a un momento determinado, restauración en distintas instancias o servidores y clonación para desarrollo o pruebas, todo ello sin agentes en las máquinas virtuales protegidas. La versión de prueba se encuentra en hycu.com/trial.