Cada vez más nos encontramos sistemas críticos, ERPs, etc. cuyas bases de datos tienen un tamaño elevado. Además, brillan por su ausencia las técnicas de particionado (nativo o no), la división en múltiples filegroups, etc. Una de las consecuencias de esto es que, en caso de desastre, los tiempos de restauración de la base de datos son muy elevados. Esto tiene un impacto directo en el RTO en caso de desastre, pero también en caso de tener que acceder a un backup para una recuperación parcial de datos, para ejecutar una consulta “en el pasado” para un auditor, etc.


En este tipo de escenarios podemos recurrir a herramientas de terceros de forma que podamos conseguir algo que actualmente es imposible con las herramientas nativas de SQL Server. En este post concretamente nos vamos a centrar en SQL Safe, de Idera, y más concretamente en dos de sus funcionalidades que aportan, desde nuestro punto de vista, un valor especial y diferenciado: InstantRestore y SQL Virtual Database.
Comenzaremos comentando el funcionamiento de SQL Virtual Database ya que, en cierta forma, es la base sobre la que apoya Instant Restore. Con SQL Virtual Database lo que conseguimos es realizar un “restore virtual” de un backup de SQL Server. Una vez este restore se realiza, la base de datos podrá utilizarse de forma normal, tanto para lecturas como para escrituras. Debemos tener claro eso sí que el objetivo de esta funcionalidad es proporcionar acceso temporalmente y no que sirva cargas de producción. El punto en el tiempo al que queremos restaurar podrá ser seleccionado en el momento del “restore” y los cambios que se realicen se almacenarán en ficheros externos, por lo que el backup original quedará intacto. Cuando finalice el proceso que deseamos realizar los posibles cambios que realizáramos sobre la base de datos se perderán al realizarse el “drop/detach”. El siguiente diagrama muestra los componentes de SQL Virtual Database:

Desde el punto de vista de Windows veremos que se nos añaden varios servicios, siendo dos críticos para el funcionamiento de ambas funcionalidades (SQLsafe Filter Service y SQLSafe OLT Service):


El tiempo del proceso de “restore virtual” dependerá básicamente de lo compleja que sean las fases de recuperación (analysis, redo y undo) ya que es necesario pasar por ellas para que la base de datos sea consistente. Lo que nos ahorraremos es la mayor parte del proceso de restauración consistente en la extracción y escritura de los ficheros mdf/ndf y ldf del propio backup. También ahorraremos una gran cantidad de espacio durante el proceso. En nuestra experiencia el espacio también suele ser un limitante importante, especialmente en entornos de desarrollo y pruebas, ya que hay veces que los ficheros tienen mucho espacio vacío que, aunque no esté incluido en el backup, sí es necesario para poder ejecutar el proceso de restore tradicional.

InstantRestore es una tecnología que nos permite poner una base de datos online rápidamente mientras el proceso completo de restauración ocurre en background. Tras esta frase seguramente muchos de vosotros estaréis pensando en los posibles problemas o complejidades que encierra este proceso. Lo que haremos por una parte es poner la base de datos online mediante la tecnología de SQL Virtual Database y, en background, continuaremos con la restauración de los ficheros de datos, etc. Cuando esta restauración finalice (la llamada fase de hidratación) todas aquellas operaciones de escritura que se realizaran durante este proceso se replicarán sobre los ficheros con lo que cuando el proceso finalice el resultado será el mismo que si hubiésemos realizado un restore tradicional pero sin el downtime asociado. Debemos tener en cuenta que durante este proceso las propiedades ACID (Atomicity, Consistency, Isolation and Durability) no se ven afectadas en absoluto ya que para el motor de SQL Server el proceso es totalmente transparente.

Una vez que hemos comentado las funcionalidades vamos a mostrarlas en funcionamiento ya que desde un punto de vista de administración de SQL Server parecen ser casi “mágicas”. El primer punto será instalar el software sobre nuestro entorno de pruebas basado en Windows 10 + SQL Server 2017:


La instalación nos permite personalizar los componentes a instalar:

Siendo los mínimos necesarios los indicados en la siguiente imagen:


Como base de datos de pruebas vamos a utilizar la base de datos WideWorldImportersDW sobre la que crearemos algunas tablas adicionales para incrementar su tamaño:

Una vez finalizado el proceso realizaremos un full backup sin compresión y otro con compresión para tener los tiempos y espacios como referencia. En este ejemplo los tiempos de backup resultaron ser muy similares, en torno a 60 segundos, mientras que el espacio ocupado era 5 veces menor en la versión comprimida:

Una vez tenemos los backups procederemos a lanzar un comando RESTORE de SQL Server:

Lanzaremos cada restauración tres veces y calcularemos el tiempo medio. En el caso del backup no comprimido el tiempo medio ha sido de 79 segundos y en el caso del backup comprimido de 49 segundos. Tened en cuenta que estamos hablando de una base de datos con apenas 5 GB de datos y si la base de datos fuese 100 veces mayor, de unos 500GB (algo bastante habitual a día de hoy), hablaríamos de tiempos de restauración de más de 2 horas en el caso del backup no comprimido y de más de 1 hora en el caso del backup no comprimido.

El siguiente paso es probar a realizar un attach virtual para ver cuánto tiempo requerirá para este proceso. Para ello seleccionaremos la opción en la SQL Safe Management Console:

Nos encontramos con que la opción del menú no realiza ninguna acción. Sospechamos que el problema puede venir por no tener disponibles unos procedimientos almacenados instalados en la instancia. El proceso se puede ejecutar desde la correspondiente opción en la consola:


Desafortunadamente parece que no funciona correctamente en SQL Server 2017:


Por tanto, intentaremos seguir un proceso manual de instalación, copiando las DLL de la carpeta de instalación (C:\Program Files\Idera\SQLsafe en mi caso) a la carpeta Binn de nuestra instancia (C:\Program Files\Microsoft SQL Server\MSSQL14.SQL2017_1\MSSQL\Binn en mi caso):

Procederemos a registrar posteriormente las DLLs, en su versión 32 bits o 64 bits, siendo necesario en mi caso la versión de 64 bits:

Sin embargo, tampoco es posible lanzar el proceso una vez instalados manualmente. Si analizamos con profiler parte de los objetos comprobaremos que se comprueba explícitamente la versión, fallando en caso de ser superior a 2016:


También encontramos algunos errores referentes al firmado del Filter driver necesario:

Para sortear este problema, necesitaremos relajar la política correspondiente para no solo cargar drivers firmados:

Pese a todo, no conseguimos que funcionara este software correctamente en este entorno. Imaginamos que Idera estará trabajando en una versión compatible con 2017 y que la liberará cuando SQL Server 2017 RTM esté disponible. Mientras tanto vamos a realizar las pruebas contra un SQL Server 2016 por lo que tendremos que repetir el proceso de restauración y de backups. Los tiempos de backup y de restore “tradicional” no varían respecto a los de SQL 2017 por lo que nos sirven los tiempos medidos anteriormente.

Para poder comprobar el funcionamiento optamos por configurar un entorno más “conservador” basado en Windows Server 2012 R2 y SQL Server 2016. En este entorno realizaremos la instalación de nuevo:

En este entorno una vez instalado el software no tendremos problemas en registrar los procedimientos almacenados directamente desde la herramienta:

Comprobaremos que el estado del InstantRestore es correcto al utilizar SQL 2016:

Una vez tenemos todo correctamente instalado podemos proceder a probar ambas funcionalidades. Debemos tener en cuenta que tanto para la funcionalidad InstantRestore como para SQL Virtual Database necesitamos un fichero de mapping. Este fichero de mapping es un proceso de postprocesado sobre el fichero de backup que ayudará a agilizar el proceso de montado de la base de datos.
En el caso que vayamos a realizar únicamente montados de backups muy puntuales podemos obviar este punto y realizarlo directamente manualmente cuando sea necesario. Podemos generar el mapping mediante la línea de comandos de SQL Virtual Database:

Una vez tenemos este mapping creado podemos montar la base de datos virtual directamente con un comando como este:

SQLvdbCmd.exe create virtualWWI "c:\Backup\test.bak" -move WWI_Primary c:\backup\fichero.mdf -move WWI_UserData c:\backup\fichero2.ndf -move WWIDW_InMemory_Data_1 c:\backup\fichero -move WWI_Log c:\backup\log.ldf

En el primer intento de montaje nos encontramos con un error y la base de datos quedó en modo sospechoso:

La razón no era otra que, debido a que la base de datos incluye tablas en memoria, no era posible restaurar la base de datos por no disponer de suficiente memoria. Este problema es algo que vamos a sufrir con más frecuencia cuanto más se utilice esta funcionalidad de tablas en memoria.
En nuestro caso lo que hicimos para liberar la memoria fue poner offline la base de datos WideWordImportersDW de forma que la memoria utilizada por ésta pasara a estar disponible para la nueva. Por tanto, una vez offline, lanzaremos de nuevo el comando:

Podemos ver que el tiempo para montar la base de datos virtual es de solamente unos pocos segundos. La diferencia de tiempo respecto a un restore completo será mayor cuanto mayor sea el tamaño de la base de datos original. Esta velocidad puede ser muy útil cuando únicamente necesitemos ejecutar alguna consulta puntual sobre la base de datos o realizar alguna extracción parcial de información.
Para realizar una prueba del InstantRestore procederemos a seleccionar el backup desde la consola de administración y marcaremos la opción InstantRestore en el wizard:

Recordemos que también necesitaremos el mapping para que esta funcionalidad sea aplicable. La opción alternativa a la generación de mapas a posteriori al backup es incluir la generación del mapa en el propio proceso de backup:

Una vez lancemos el restore con la opción InstantRestore veremos que, de forma casi inmediata, la base de datos estará disponible, en modo lectura y escritura, aunque su estado sea aún “in recovery” en SSMS:

Si realizamos una consulta funcionará correctamente en este este estado:

Y también podemos realizar operaciones de escritura, como la creación de una tabla sin problemas:

Por tanto, utilizando esta funcionalidad podemos decir que el RTO y el downtime que sufre nuestra base de datos cuando decidimos recuperar a un backup, es mínimo de solo 11 segundos:

Una vez la base de datos está online en background el proceso de “hidratación” continúa. Cuando éste finaliza la base de datos se encontrará totalmente restaurada y con todos los datos escritos en los ficheros correspondientes:

En conclusión, SQLSafe de Idera aporta funcionalidades muy interesantes sobre los procesos de restauración de bases de datos SQL Server. Estas funcionalidades nos permitirán mucha más agilidad en nuestros procesos de recuperación de información e incluso una mejora importante en el RTO de nuestras bases de datos que puede pasar de horas a pocos minutos. Desgraciadamente el software no parece estar preparado para SQL Server 2017 y también tenemos la sensación que puede no ser todo lo estable que sería deseable… por lo que recomendaríamos realizar pruebas exhaustivas antes de realizar un despliegue en producción.

En el fondo lo que desearíamos es que este tipo de funcionalidades estuvieran incluidas en el propio SQL Server de forma nativa, con un comando RESTORE “WITH ONLINE=ON”. Sería un buen “extra” para la opción Enterprise que permitiría un acceso temprano a la base de datos, así como la posibilidad de tener “snapshots” de lectura/escritura (muy útiles para pruebas).
Indicar que a día de hoy no existen indicios de que este tipo de tecnologías se vayan a implementar nativamente por lo que recomendamos encarecidamente que se realice un diseño físico de las bases de datos que nos permita recuperar nuestros sistemas de forma granular. El uso de particionado es una de las herramientas más potentes que tenemos para que el volumen de datos mínimo necesario para que nuestros sistemas funcionen (aunque sea de forma parcial, sin históricos por ejemplo) disminuya.

Rubén Garrigós

Rubén Garrigós is an expert in high-availability enterprise solutions based on SQL Server design, tuning, and troubleshooting. Over the past ten years, he has worked with Microsoft data access technologies in leading companies around the world. He currently is a Microsoft SQL Server and .NET applications architect with SolidQ. Ruben is certified by Microsoft as a Solution Expert on the Microsoft Data Platform (MSCE: Data Platform) and as a Solution Expert on the Microsoft Private Cloud (MSCE: Private Cloud). As a Microsoft Certified Trainer (MCT), Ruben has taught multiple official Microsoft courses as well as other courses specializing in SQL Server. He has also presented sessions at official events for various Microsoft technologies user groups.