A lo largo de los años podemos apreciar como el Volume Shadow Copy Service (VSS) es en general un servicio desconocido para muchos y en este post queremos mostrar su utilidad y posibilidades más allá del apoyo de las actividades de backup consistente a nivel de ficheros.
Comenzaremos por ejemplo hablando de snapshots de bases de datos. En SQL Server disponemos en la versión Enterprise (o desde SQL Server 2016 SP1+ en todas las versiones) de la funcionalidad Database Snapshots. Esta funcionalidad de snapshot no nos permite utilizar dichos snapshots en otras instancias ni locales ni remotas, por lo que estamos atados a la misma instancia que generó el snapshot.
Vamos a ver un caso práctico del uso de snapshots VSS y para ello utilizaremos la base de datos adventureworks2017 cuyos ficheros se encuentran en el disco E:
El primer paso será crear un snapshot del disco E. Esto podemos hacerlo de muchas formas vía WMIC, PowerShell, .NET o desde la utilidad de línea de comandos vssadmin. Por sencillez utilizaremos la utilidad de línea de comandos vssadmin:
Si todo funciona correctamente podremos ver el nuevo snapshot y su identificador:
En caso de fallo la causa más frecuente es que el estado de alguno de los writers involucrados no sea correcto. Con el comando vssadmin list writers podemos sacar la lista de writers registrados y su estado actual, que debería ser Stable y “No Error”:
Para poder utilizar el shadow copy recién creado necesitaremos montarlo primero. Para ello podemos utilizar el comando mklink y montarlo sobre una carpeta (que no debe existir previamente):
Si accedemos al contenido de C:\Snapshot veremos que tenemos una “foto” del contenido del disco E:
En muchos casos puede ser interesante que compartamos esta carpeta para poder tener un acceso externo a los ficheros desde otra instancia ubicada en otra máquina:
Un posible fallo que podemos tener tras compartir la carpeta son los errores por permisos al intentar acceder a ella desde SQL Server. En este caso lo habitual es que la cuenta de servicio de la instancia externa no tenga permisos para acceder a la carpeta compartida. Esto es algo que podemos solucionar fácilmente simplemente dando permisos a la cuenta de servicio:
Sin embargo, si los propios ficheros MDF/LDF no tienen los permisos adecuados ya antes de crear el snapshot, al tratarse de un snapshot de solo lectura, no podremos añadírselos posteriormente a los ficheros. Por tanto, si este es el caso, deberemos añadir los permisos sobre los ficheros antes de realizar el snapshot.
Otro problema que nos podemos encontrar es que no podemos realizar el attach con normalidad de los ficheros ya que el propio proceso los intenta modificar (y no puede al ser ficheros de solo lectura). Una forma de evitar este problema es “engañando” a SQL Server creando una base de datos dummy y luego modificando las rutas de los ficheros.
Primero crearíamos la base de datos dummy:
A continuación modificaríamos la ruta de sus ficheros:
Y finalmente intentaremos poner offline y online la base de datos.
Sin embargo al realizar este proceso veremos que una vez la base de datos vuelva online, obtendremos otro error y la base de datos quedaría en recovery pending:
Para poder acceder en modo lectura a la base de datos, la tendríamos que pasar a modo emergencia, tras lo cual estará disponible para lecturas:
Un posible uso de esta técnica sería descargar procesos pesados a otro servidor sin tener que copiar la base de datos. Por ejemplo, podríamos lanzar un CHECKDB desde otro servidor (WS2016NODO2) al que hubiéramos dado acceso al snapshot (del WS2016NODO1 vía shared folder):
Debemos tener en cuenta que, obviamente, toda la carga de entrada/salida sobre esa base de datos seguirá recayendo sobre el sistema original. Sin embargo todo el coste de CPU y, especialmente, sobre Tempdb quedará descargado en esta otra instancia .
También podríamos usar esta técnica como una forma de dar acceso a un conjunto de instancias a un mismo conjunto de datos en modo solo lectura para fines analíticos o de cálculos pesados distribuidos. Por ejemplo, además de la instancia WS2016nodo2\SQL2017_1 podemos añadir a otra instancia (WS2016nodo3\SQL2017_1) otra base de datos apuntando al mismo snapshot siguiendo los mismos pasos anteriores:
Una vez tenemos estas dos bases de datos idénticas, podríamos incluso montar algún tipo de balanceador hardware o software para balancear las peticiones si lo que queremos es procesar muchas peticiones pequeñas pero balanceadas entre los N nodos. Por sencillez para mostrar esta configuración podemos instalar el balanceador que viene por defecto en Windows Server 2016. Para ello lanzaremos el siguiente comando:
A continuación con el network load balancing manager crearemos un nuevo cluster de balanceo, elegiremos el primer nodo, seleccionaremos un interfaz y una IP para balanceo para crear el cluster:
A continuación, crearemos una regla de balanceo para un puerto que decidamos, por ejemplo el 14330 y sin ningún tipo de afinidad de cliente a IP balanceada
Ya tenemos el primer nodo en el balanceador, ahora añadiremos el segundo:
El proceso será el mismo que en el caso anterior, seleccionaremos el nodo, el interfaz a usar y en este caso la IP balanceada y las reglas ya nos aparecerán preconfiguradas:
Antes de testear el balanceador, nos aseguraremos que nuestras instancias están escuchando en el puerto adecuado:
El siguiente paso es comprobar que el balanceo funciona y para ello podemos lanzar una sencilla consulta contra la IP balanceada para que devuelva el nombre del servidor y podamos ir viendo como va cambiando el nombre del servidor entre llamadas:
Si lanzamos varias peticiones concurrentes con algo más de carga de CPU, podremos ver cómo aproximadamente la carga se reparte entre ambos SQL Server:
Otro escenario de uso donde nos podría ser útil el VSS es un escenario de comparación masiva de datos entre instancias. Si utilizamos algún tipo de proceso que lee las filas desde dos bases de datos, calcula algún hash y luego realiza un cruce de todos los hashes para localizar diferencias. Estos procesos suelen ser muy intensivos en IO pero también en CPU debido a la computación de los hash y las comparaciones entre ellos. Por tanto, podría tener sentido generar un snapshot en cada una de las instancias y desde una tercera instancia externa montar las bases de datos sobre esos ficheros y realizar las comparaciones desde dicho servidor.
Existen otros escenarios de uso de VSS que no podemos implementarlos únicamente con el proveedor de Windows y necesitamos el apoyo de un proveedor hardware. Concretamente Windows no provee de soporte nativo para snapshots de lectura/escritura pero sí hay proveedores de SAN que nos permitirían explotar esa posibilidad desde VSS. Esto nos permitiría tener un proceso automático que genere un snapshot nuevo de un entorno, lo clone internamente como lectura/escritura y lo presente a otro entorno (o a varios). Esta técnica proporciona una forma rápida de mover datos entre entornos o de refrescar entornos de datos con agilidad evitando copias masivas por red entre discos. Lo que sí debemos tener claro es que en general estos snapshots clonados únicamente mantienen las diferencias entre ambos por lo que en caso de corrupción el problema se presentaría en los otros entornos por lo que, en general, no debemos confiar en los snapshots como método único de backup. Existen excepciones ya que hay casos que los snapshots se pueden clonar físicamente en background, incluso contra otra ubicación geográfica, por lo que al finalizar dicho proceso sí tendríamos dos copias independientes totalmente entre sí.
También tenemos situaciones en las cuales podemos querer guardar una base de datos en un medio de solo lectura (por ejemplo por temas legales, o de auditoría). Existe un procedimiento almacenado en SQL Server bastante “arcaico” que se encarga de crear una base de datos pensada para este fin y otro asociado para “certificar” su uso read-only. El siguiente script crea una base de datos, añade una tabla, inserta 10000 filas y ejecuta el proceso de certificación tras el cual la base de datos quedará offline y sus ficheros listos para ser usados desde un medio read-only:
Si creamos un snapshot sobre los ficheros de esta base de datos “especial”:
Creamos el enlace simbólico al shadow copy en una carpeta y la compartimos como hicimos anteriormente:
Y a continuación hacemos un attach desde otra máquina veremos no tendremos problemas como con el caso anterior, cuando tuvimos que “engañar” al SQL Server creando otra base de datos, apuntar sus ficheros a los del snapshot y pasando la base de datos al modo emergencia. Simplemente nos aparecerá la base de datos como read-only en cada uno de los nodos desde los que hagamos attach:
En conclusión, es interesante que tengamos en nuestro toolset funcionalidades como VSS que utilizadas alrededor de nuestros conocimientos en SQL Server nos puedan ayudar a crear soluciones más eficientes para nuestros clientes que las que plantearíamos inicialmente si no las conociéramos. Por poner otro ejemplo de estos conocimientos generales, en otra entrada de este blog hace ya un tiempo hablamos de los pipes, los virtual devices, etc. y su uso para realizar backups y restores “al vuelo” sin necesitar almacenamiento intermedio: https://blogvisionarios.com/es/sql-server/backups-y-restores-al-vuelo-sin-almacenamiento-intermedio/ También en otro post hablamos de técnicas de indexación alternativas y complementarias a los índices típicos/nativos que incluye SQL Server (y que podrían aplicarse en otros motores) para los casos en los que las estructuras indexadas disponibles no son las idóneas para el problema a abordar: https://blogvisionarios.com/es/sql-server/combinando-ngrams-y-fulltext-search/
Por tanto os recomendamos que en vuestro rol de DBAs/consultores y ante un problema relacionado con SQL Server intenteis tener la mente abierta para plantear una solución donde el resultado final sea lo más elegante y satisfactorio posible.
