Una snapshot no es lo mismo que una snapshot
Elemental. Al igual que es evidente que una instantánea no es igual que una instantánea, no sea que alguien me riña por usar los anglicismos.
Cuando se habla de hacer copias de seguridad de máquinas virtuales surgen técnicas y métodos para todos los gustos, y el problema es que a dos de ellas se les da desafortunadamente el mismo nombre. Vamos a ver algunas opciones:
- Snapshots/Instantáneas de las que aparecen como acción en la consola de Hyper-V. Es seguramente el peor método de copia de seguridad que podemos utilizar para una máquina virtual, con ciertas salvedades. La razón subyace en su propio funcionamiento. Una instantánea consiste básicamente en un fichero diferencial respecto al VHD de la máquina (AVHD) más una copia de la configuración (xml) de la VM y, si se obtuvo con la máquina encendida, un par de ficheros que representan el estado de la memoria y el procesador (.vsv y .bin). Además, las instantáneas de Hyper-V pueden encadenarse unas con otras, creando árboles con ramas que representan diferentes estados de ejecución a los que podemos volver, y que podemos descartar en cualquier momento. Esta característica es importante en durante los procesos de instalación y configuración de equipos, en baterías de pruebas y desarrollo, e incluso en situaciones en las que debemos probar un parche o un cambio en un momento dado. Sin embargo su uso como estrategia de seguridad tiene las siguientes e importantes limitaciones:
- Los .avhd son discos diferenciales de crecimiento dinámico, por lo que tienen un impacto en el rendimiento de la máquina virtual. A mayor número de snapshots existentes entre el VHD original y el estado de ejecución actual, más se acumula este efecto.
- La restauración de un punto anterior supone una vuelta atrás en el estado de ejecución de la máquina. El ir y venir por el túnel del tiempo puede tener consecuencias nefastas en cualquier aplicación o servicio mínimamente transaccional que corra dentro de la VM. Controladores de dominio, bases de datos, sistemas de correo, etc., sobre todo si no están solos en la red y si están en producción, deberían tener esta operación estrictamente limitada.
- Cuando descartamos instantáneas, dejamos pendientes operaciones de fusión de datos entre los .vhd y los .avhd. Estos “merge” no suceden inmediatamente sino que se llevan a cabo cuando apagamos la VM. Si no somos conscientes de este hecho, es posible que ocurra justo en el momento en el que no nos podemos permitir el tiempo de caída que supone el proceso
- Parar la máquina virtual y copiar el/los .VHD de los que consta la VM. Es quizás uno de los métodos de backup más utilizados por muchos de nosotros, a la par que cutre.
- Al igual que el anterior tiene la pega de que su “restauración” supone, como todas, una perdida de datos, pero es tan evidente que somos conscientes de ello y lo asumimos de forma natural.
- Por otro lado, los VHD solo contienen la información de la VM. Su configuración radica en el .xml asociado, y al volver a crear la VM en su ausencia, notaremos principalmente que se nos crean unas nuevas tarjetas de red. Esto sucede porque en ese .xml se referencian unos identificadores únicos para los elementos de la VM que se regeneran al crear la VM desde cero. Puede también copiarse todo el sistema de carpetas que contienen el .xml y los .vhd al igual que hacíamos en Virtual Server con los .vmc y .vhd. Sin embargo deberemos registrar manualmente la VM, lo que logramos creando un “hard link” al .xml en una carpeta del sistema en particular. Hace tiempo puse por aquí un pequeño script para ello.
- Usar la función exportar/importar incluida en Hyper-V. Debe hacerse con la máquina parada, o con el estado salvado, y permite llevarnos todo lo necesario para restaurar una VM a otra localización. Esta funcionalidad está detrás de algunas acciones de SCVMM como las migraciones y los clonados. Para importar la VM de nuevo, deberemos copiar el conjunto de carpetas y archivos a la localización final donde deseamos que resida la VM, e importarlo desde la consola de Hyper-V
- Snapshots/Instantáneas basadas en VSS. Estas son las buenas y es lo que podemos llamar estrictamente copias de seguridad de máquinas virtuales, que se pueden sacar en caliente o templado, según cómo las estemos obteniendo. La idea es sacar una copia consistente de los VHDs mientras están siendo utilizados por la VM, y esto puede suceder a dos niveles:
- Copia consistente de los VHDs a nivel de partición padre. En resumen, estamos usando el VSS provider de Hyper-V para que nos dé un snapshot de los .VHD en estado consistente. De esta manera solamente garantizamos la consistencia de los VHDs a nivel de fichero, pero no podemos garantizar nada a nivel de los ficheros que haya dentro de esos VHDs. La única manera de hacerlo es pausando la VM mientras los VHDs se están copiando. A esto se le llama generalmente Offline Backup.
- Copia consistente de los VHDs a nivel de partición hija. Para eso se necesita la inestimable colaboración de los componentes de integración instalados en el sistema operativo de la VM. En este caso usamos el VSS provider de Hyper-V para sacar la copia consistente del VHD, pero se solicita a la VM mediante sus componentes de integración que ponga en estado consistente todos los datos mediante los VSS providers registrados. Esto garantiza la consistencia tanto a nivel de VHD como de los datos que residen dentro de dicha VM. Esta copia de seguridad puede llevarse a cabo totalmente en caliente, sin interrupción de la ejecución de la VM, razón por la cual se la llama Online Backup.
- Copia de seguridad a nivel de la VM. Es decir tratando a la VM como si fuese un servidor físico, y usando las herramientas de copia de seguridad como siempre.
Una buena estrategia de recuperación de desastres debe pasar por una combinación de los puntos 3 (automatizado), 4 y 5, dejando los 1, 2 y 3 (manual) para pruebas sin importancia e informática recreativa.
Ya hablaremos más en detalle de como usar Virtual Machine Manager y sobre todo Data Protection Manager para todo esto, sin ser desde luego los únicos productos del mercado que lo hacen. Mientras tanto, algunas lecturas interesantes al respecto:
- Backup and Disaster Recovery for Server Virtualization
- Planning for Backup
- Protecting Hyper-V (con DPM 2007 SP1)
- Como Configurar Windows Server Backup para soportar VSS Writer en Hyper-V (ojo con los matices)
Saludos
Comments
Anonymous
January 01, 2003
Hola Algunos enlaces a información sobre temas que suelen surgir frecuentemente: Herramienta para crearAnonymous
February 08, 2010
Pregunta que puede resultar absurda y/o fuera de lugar: Habiendo creado un vhd padre (ssoo.vhd) y trabajar con su hijo (boot.vhd); al hacer un merge vdisk depth=1 con el boot.vhd seleccionado, continuo teniendo ambos archivos con la misma relación de parentesco entre ellos. Leyendo documentación variada (http://technet.microsoft.com/es-es/library/dd979538(WS.10).aspx) (https://blogs.msdn.com/7/archive/2009/10/08/diskpart-exe-and-managing-virtual-hard-disks-vhds-in-windows-7.aspx), no he sido capaz de conocer con certeza cual es el estado actual de cada disco virtual. ¿Que ha sucedido con cada uno de ellos? Gracias por adelantadoAnonymous
April 11, 2012
Que bueno el concepto "informática recreativa". Está muy extendido su uso!Anonymous
September 11, 2015
Hola, usted me podría indicar que método utilizar para detectar snapshot , programados ? Gracias