Vmware Data Recovery (VDR) provee un mecanismo flexible para obtener copias PIT (point in time) del estado de nuestras máquinas virtuales. Nos podemos olvidar de instalación de agentes de backup tipo Netbackup, Legato, etc en nuestras máquinas virtuales a la vez que obtenemos una copia completa y consistente de nuestro sistema operativo y datos, pudiendo volver a tener una VM funcional tras una catástrofe en minutos.

Sin embargo, esta flexibilidad muchas veces se convierte en un "todo vale" y en una falta de diseño para obtener una estructura de backup adecuada. Voy a exponer alguna de las limitaciones y/o buenas prácticas que me he ido encontrado a la hora de desplegar este producto:

No es aconsejable hacer backups de VMs de más de 250GB. Backups más grandes de ese tamaño hacen difícil cuadrarlo en una ventana de backup de 8h y no hay forma de tunear el VDR para que haga los backups más rápidos (ni asignando más CPU/vRAM al appliance, ni de ninguna otra forma).

NO hacer backup de VMs muy transaccionales. Es decir, no hacer Backup VDR de máquinas virtuales que tengan muchos cambios durante la ventana de Backup (típicamente Bases de datos). Esto es debido a que los snapshots necesarios pueden ocupar mucho espacio y hacer una estimación de espacio necesario es muy complicado.

Aprovisionar un 20%-30% de espacio adicional en datastore de origen por máquina virtual que requiera VDR. Con relación al punto anterior, y para evitar que un datastore se llene por snapshots durante ventana de VDR, es necesario aprovisionar espacio adicional para que se realicen los backups. Si lo del 30% os parece excesivo os contaré que una máquina de GB con 1 Tera en discos ha llegado a tener 300gb en snapshots no consolidados porque su Backup de VDR seguía en ejecución tras más de 48h :-) .

Almacenar los backups FUERA de la SAN. Esto suena a perogrullo, pero en más de un caso me he encontrado que el appliance VDR reside en la misma cabina que las luns a las que hace backup. Si falla la cabina, nos quedamos sin VMs y sin backups, por lo que no tiene sentido almacenarlos en el mismo sitio. Donde sea posible, es aconsejable almacenar los backups en discos locales de los ESX o en una cabina distinta a las VMs de origen. Por ejemplo, en máquinas HP Proliant se pueden comprar discos SATA de 1 ó 2 Terabytes a precios bastante competitivos en relación a los FC/SAS.

No hacer que todos los backups finalicen a la msima hora. Si tenemos muchos trabajos de backup y hacemos que todos finalicen a la misma hora (ej: lunes a las 08:00), conseguiremos que a esa hora se produzca una "tormenta de consolidación de snapshots". VDR cancela todos sus trabajos e informa al vCenter que consolide todos los snapshots que ha creado para poder hacer copias consistentes de las VMs, por lo que conseguimos que a las 8:00 se produzcan operaciones I/O masivas hacia el almacenamiento. Perfecto para que los usuarios estén felices y contentos por la lentitud de sus VMs :-) .

Dimensionamiento de espacio a asignar: Si queremos hacer backup de VMs que ocupan 1 Terabyte neto, típicamente necesitaremos menos de ese espacio asignado a nuestro VDR: ratios de 2/1 no parecen descabellados. Sin embargo, hay que tener en cuenta el crecimiento de nuestras VMs y cuánta retención queremos para ella. No es lo mismo querer guardar los últimos 30 backups diarios, que guardar los últimos 4 semanales. Siempre hay que tener en cuenta el no asignar más de 2 Terabytes de espacio por appliance VDR, lo que según estos cálculos, nos permitiría proteger hasta 3-4 Terabytes de VMs.

Dimensionamiento de los datastores de VMs: Como comentaba antes, es necesario dejar espacio libre en los datastores que vayan a albergar máquinas protegidas por VDR, típicamente entre un 15-20%, dependiendo de la transaccionalidad de las VMs. Para máquinas muy cambiantes, pueden incluso requerir mucho más, por lo que requiere un análisis cuidadoso. El hecho de quedarse sin espacio libre en un datastore mientras se tienen máquinas virtuales encendidas es muy delicado, ya que puede llegar a provocar corrupción de las VMs y/o pérdida de datos (rollback de los snapshots).