Cómo comprimir respaldos VMDK sin destruir los Sparse
Si has trabajado con respaldos de VMware durante un tiempo, probablemente ya conoces este problema.
Tienes una máquina virtual con un disco de 500 GB. El disco está en Thin Provisioning, pero la máquina realmente utiliza 80 GB.
El respaldo llega al servidor NFS, miras el archivo y dices:
Perfecto, tengo 80 GB para comprimir.
Después haces una copia, un tar, un cp, una compresión o cualquier otra operación aparentemente inocente y de repente tienes un archivo que ocupa 500 GB.
Bienvenido al maravilloso mundo de los archivos Sparse.
Thin Provisioning no significa que el archivo siempre sea pequeño
Cuando VMware utiliza discos virtuales Thin, el VMDK puede tener una capacidad asignada mucho mayor que el espacio que realmente está utilizando la máquina virtual.
Por ejemplo:
Disco virtual: 500 GB
Espacio utilizado: 80 GB
El disco puede tener una capacidad lógica de 500 GB, pero físicamente estar utilizando bastante menos.
Esto es particularmente interesante para los respaldos porque no tiene mucho sentido almacenar, transferir y procesar cientos de gigabytes de bloques que realmente no contienen información útil.
Ahí aparece Sparse.
¿Qué tiene que ver Sparse con todo esto?
Un archivo Sparse puede tener un tamaño lógico enorme, pero físicamente almacenar solamente los bloques que contienen datos.
Podemos tener algo como:
Tamaño lógico: 500 GB
Espacio físico: 80 GB
El problema es que ese comportamiento no siempre sobrevive cuando empezamos a manipular el archivo.
Copiarlo de una manera incorrecta, extraerlo sin las opciones adecuadas, procesarlo con una herramienta que no entiende Sparse o simplemente hacer una operación que obligue a escribir todos los bloques puede convertir esos 80 GB físicos en 500 GB reales.
Y ahí comienza la fiesta.
El problema de hacer backups grandes
El espacio en disco no es gratis, de hecho es bastante caro, MUY caro.
En un servidor de backups, especialmente cuando hablamos de grandes cantidades de máquinas virtuales, unos pocos cientos de gigabytes adicionales por máquina terminan convirtiéndose rápidamente en terabytes.
Y el problema no termina en el almacenamiento.
Si esos respaldos tienen que viajar por la red, el tamaño importa todavía más.
Transferir 80 GB y transferir 500 GB no es lo mismo.
Hay más tiempo de transferencia, más demora en restaurar un respaldo que siempre es crítico, más consumo de ancho de banda, más I/O, más procesamiento y más posibilidades de que alguien termine mirando el progreso del scp como si fuera una maratón de El Señor de los Anillos, edición extendida.
Para ponerlo en números, supongamos un VMDK de 500 GB asignados, pero que realmente utiliza unos 80 GB. Solo por conservar correctamente el Sparse ya podemos reducir considerablemente la cantidad de datos que necesitamos mover.
Y si además comprimimos correctamente el respaldo, podemos reducir todavía más el tamaño final. Dependiendo del sistema operativo, tipo de datos y cuánto espacio libre tenga el disco, una compresión puede conseguir fácilmente entre un 20% y un 60% adicional de reducción sobre los datos reales. En algunos casos puede ser incluso mayor, pero no conviene hacer promesas de vendedor de “llame ya!”.
| Red | 500 GB sin Sparse | 80 GB con Sparse | 80 GB + compresión* |
|---|---|---|---|
| 10 GbE | ~8 min | ~1 min | ~25–50 s |
| 1 GbE | ~1 h 10 min | ~10 min | ~4–8 min |
| 100 MbE / Fast Ethernet | >11 h | ~2 h | ~50–95 min |
casi un 90% más rápido!
NOTA: La compresión es altamente dependiente del contenido del VMDK. Un disco con mucho espacio libre y datos fácilmente comprimibles puede reducirse bastante; uno lleno de datos ya comprimidos puede prácticamente no ganar nada.
La diferencia es enorme.
En una red de 10 GbE quizás alguien diga que ocho minutos no es para tanto. En Gigabit ya empieza a doler. Y en Fast Ethernet estamos hablando de más de 11 horas para mover un archivo que podría terminar ocupando una fracción de ese tamaño.
Por eso conservar correctamente los Sparse y comprimir el respaldo antes de transferirlo no es solamente una cuestión de ahorrar espacio en disco. También significa menos tráfico de red, menos I/O, menos tiempo de transferencia y, lo más importante, respaldos que pueden llegar mucho antes al lugar donde tienen que estar.
Por eso conservar correctamente los Sparse durante el proceso de respaldo puede tener un impacto importante tanto en almacenamiento como en operación.
Y aquí viene la parte complicada
Trabajar correctamente con Sparse no es tan sencillo como parece.
El problema no está necesariamente en crear el archivo.
El problema aparece cuando empiezas a moverlo, copiarlo, comprimirlo y restaurarlo.
Una operación mal planteada puede convertir:
500 GB lógicos
80 GB físicos
en:
500 GB lógicos
500 GB físicos
Y si estás trabajando con varios VMDK, eso escala rápidamente.
Por eso este tipo de respaldos requiere bastante más cuidado que simplemente ejecutar:
tar czf backup.tar.gz *.vmdk
y cruzar los dedos.
El script
Para solucionar este problema hice este script:
vmware-vmdk-compressor
NOTA: Si, le pedí a la IA que lo ordenara y maquillara un poco la salida, por eso está lleno de íconos, pero está ordenado y bien documentado.
La idea es bastante simple: tomar los respaldos VMDK que ya están en el servidor de backup y comprimirlos sin destruir la característica Sparse del archivo.
Está pensado principalmente para ejecutarse en Linux y, en particular, tiene mucho sentido instalarlo directamente en el servidor NFS que recibe los respaldos de VMware.
Por ejemplo, un escenario típico con ghettoVCB puede ser:
VMware
|
| backup
v
NFS
|
+-- VM01/
| +-- disk1-flat.vmdk
| +-- status.ok
|
+-- VM02/
| +-- disk1-flat.vmdk
| +-- status.ok
|
+-- vmware-vmdk-compressor.sh
El backup se genera normalmente y posteriormente el script se encarga de procesarlo.
No comprime un backup que todavía se está escribiendo
Una de las cosas importantes en un sistema de backups es no asumir que porque apareció un archivo ya podemos empezar a hacer cosas con él.
El script verifica que el respaldo haya terminado antes de procesarlo.
Para eso utiliza el mecanismo de finalización del backup mediante status.ok.
La idea es sencilla:
si el backup no está marcado como terminado, no se toca.
Además, el script espera y verifica que los archivos no estén siendo utilizados antes de comenzar el proceso.
Esto es importante porque comprimir un archivo mientras otro proceso todavía lo está escribiendo es una excelente manera de fabricar un backup que después nadie quiere restaurar.
Verificación de los archivos
Antes de comenzar también se realizan verificaciones sobre los archivos que serán procesados.
El objetivo es evitar asumir que cualquier cosa que termine en .vmdk necesariamente corresponde a un backup válido listo para comprimir.
El script trabaja sobre los respaldos que cumplen las condiciones esperadas y verifica el estado de los archivos antes de procesarlos.
La idea es que el proceso sea lo más conservador posible.
En un backup prefiero que el script diga:
No lo proceso.
antes que:
Lo procesé perfectamente y ahora no funciona.
Preservando Sparse
Esta es probablemente la parte más importante del script.
La compresión se realiza de forma que el archivo Sparse pueda ser reconstruido correctamente durante la extracción.
No queremos simplemente comprimir una secuencia gigantesca de ceros y decir que solucionamos el problema.
Queremos preservar la estructura Sparse del archivo para que, al restaurarlo, los bloques que originalmente no ocupaban espacio físico continúen sin ocupar espacio físico.
El resultado es un backup que puede ser considerablemente más pequeño sin convertir el VMDK en un archivo completamente expandido durante el proceso.
¿Por qué Linux?
Porque Linux tiene excelentes herramientas para trabajar con este tipo de archivos y permite construir el proceso utilizando herramientas estándar y muy conocidas.
El script está diseñado para ejecutarse en Linux y utiliza herramientas como:
bashtarpigzigzipfinddudf
Las dependencias y versiones necesarias están documentadas en el repositorio.
Y sí, hay una razón para exigir versiones modernas de algunas herramientas.
El manejo correcto de Sparse durante todo el pipeline depende de que las herramientas utilizadas soporten las opciones necesarias. No sirve de mucho tener un script muy bonito si después el tar del servidor tiene veinte años y cree que Sparse es una marca de impresoras.
¿Dónde ejecutarlo?
El lugar ideal para ejecutar el script es el mismo servidor Linux que recibe los respaldos.
Por ejemplo:
VMware
|
| ghettoVCB
v
NFS Server
|
+-- /backup/vmware/
|
+-- VM01/
+-- VM02/
+-- VM03/
De esta forma no es necesario volver a mover los VMDK por la red solamente para comprimirlos.
El backup llega al NFS y el procesamiento ocurre directamente ahí.
Eso permite aprovechar el almacenamiento local del servidor de backup y evitar tráfico de red innecesario.
Automatizándolo con cron
Una vez configurado el script, lo normal es ejecutarlo mediante cron.
Por ejemplo:
crontab -e
Y agregar:
0 2 * * 6 /usr/local/bin/vmware-vmdk-compressor.sh >> /var/log/vmware-vmdk-compressor.log 2>&1
La frecuencia y horario obviamente dependen del entorno.
La idea es que el proceso se ejecute después de la ventana habitual de respaldos, cuando ya existan backups terminados para procesar.
No tiene mucho sentido programar el compresor exactamente al mismo tiempo que empieza el backup y después preguntarse por qué está esperando a que terminen los archivos.
Aunque técnicamente también es una forma de probar que el script funciona.
Restaurar VMDK Sparse directamente en ESXi con tar-esx
Llegamos a la parte donde VMware nos recuerda que ESXi no es precisamente un Linux de propósito general.
El tar que trae ESXi está basado en BusyBox y no maneja correctamente algunos formatos GNU Sparse utilizados en los respaldos de VMDK. Para solucionar esto preparamos tar-esx, utilizando el código fuente original de GNU tar 1.35. No modificamos el código fuente ni agregamos funciones extrañas: simplemente lo compilamos de forma estática para x86_64, de manera que pueda ejecutarse directamente en ESXi sin depender de librerías externas.
Esto es importante para quienes no tienen ninguna intención de copiar un binario desconocido a un hypervisor de producción y simplemente esperar que todo salga bien. Acá no hay un tar misterioso compilado en algún rincón de Internet: es GNU tar, código fuente original, compilado estáticamente y disponible para revisar.
Primero copiamos el binario al ESXi:
scp tar-esx root@esx1:/tmp/tar-esx
En el ESXi:
chmod 755 /tmp/tar-esx
/tmp/tar-esx --version
El resultado debería mostrar:
tar (GNU tar) 1.35
ExecInstalledOnly
ESXi incorpora una protección llamada ExecInstalledOnly. Cuando está habilitada, ESXi permite ejecutar únicamente determinados binarios instalados mediante paquetes VIB y bloquea la ejecución de binarios externos.
Por eso, al intentar ejecutar tar-esx directamente podemos encontrarnos con:
Operation not permitted
Para utilizar temporalmente nuestro tar debemos desactivar esta protección:
localcli system settings advanced set -o /User/ExecInstalledOnly -i 0
Esto genera una alerta de seguridad en vCenter, y es importante entender que no estamos desactivando la seguridad porque tar-esx sea inseguro. Estamos permitiendo temporalmente que ESXi ejecute un binario que nosotros mismos copiamos al host y que no forma parte de un VIB instalado por VMware.
Una vez finalizada la restauración, la protección debe volver a activarse:
localcli system settings advanced set -o /User/ExecInstalledOnly -i 1
Podemos verificar el estado con:
localcli system settings advanced list -o /User/ExecInstalledOnly
El valor debe quedar nuevamente en:
Int Value: 1
Extraer el backup
Para un .tar.gz, es preferible separar la descompresión de la extracción. ESXi puede tener problemas cuando GNU tar intenta ejecutar gzip internamente, por lo que podemos utilizar pigz:
pigz -dc backup.tar.gz | /tmp/tar-esx -xpf -
O gzip:
gzip -dc backup.tar.gz | /tmp/tar-esx -xpf -
De esta forma pigz se encarga de descomprimir y tar-esx recibe directamente el TAR por stdin y reconstruye el VMDK.
Finalmente, cuando terminemos:
rm -f /tmp/tar-esx
localcli system settings advanced set -o /User/ExecInstalledOnly -i 1
Así mantenemos la protección de ESXi habilitada y podemos restaurar los VMDK Sparse sin convertir un hypervisor en un servidor Linux improvisado.
El código fuente, el binario y las instrucciones completas están disponibles en nuestro repositorio de herramientas para VMware.
Características principales
El script está pensado para resolver específicamente los problemas que aparecen al trabajar con respaldos VMDK Sparse:
- Detecta respaldos que están listos para procesar.
- Utiliza
status.okpara determinar que el backup terminó. - Verifica los archivos antes de comenzar.
- Espera si los archivos todavía están siendo utilizados.
- Trabaja directamente sobre el almacenamiento donde están los respaldos.
- Conserva las características Sparse.
- Utiliza
tarpara empaquetar los archivos. - Utiliza
pigzpara aprovechar múltiples núcleos durante la compresión. - Evita procesar respaldos incompletos.
- Puede ejecutarse automáticamente mediante
cron.
¿Vale la pena?
Si tienes un par de máquinas virtuales y un disco de backup gigantesco, probablemente no sea algo que te quite el sueño.
Pero cuando empiezas a tener decenas o cientos de VMDK, el asunto cambia.
Un backup que conserva correctamente Sparse puede significar una diferencia importante en:
espacio de almacenamiento + I/O + tiempo + ancho de banda + tiempo de restauración.
Y especialmente en un servidor NFS que recibe backups de VMware, tiene bastante sentido procesar los archivos ahí mismo antes de enviarlos a otro almacenamiento.
Porque si vas a mandar 500 GB por la red para después descubrir que realmente solo necesitabas transportar 80 GB, probablemente el problema no era la velocidad de la red.
Era el backup.
El script
El código está disponible en GitHub:
https://github.com/OrangeBox-Labs/vmware
El script se encuentra en el repositorio junto con su documentación y requisitos.
La idea es seguir agregando herramientas para tareas de administración y operación de VMware que normalmente terminan resolviéndose con una mezcla de Bash, cron, tar y bastante café.
Porque aparentemente seguimos administrando infraestructura crítica con comandos escritos a mano a las tres de la mañana.
Y funciona.
La mayoría de las veces.
¿Necesitas ayuda con tus respaldos VMware?
Si tu infraestructura VMware ya tiene suficientes VMDK como para que mirar el espacio libre del servidor de backups se haya convertido en una actividad de riesgo, quizás sea momento de revisar la estrategia completa.
En OrangeBox trabajamos con Linux, VMware, almacenamiento y respaldos, incluyendo automatización y optimización de procesos para infraestructura crítica.
Si necesitas ayuda para ordenar, optimizar o automatizar tus respaldos VMware:
Conoce nuestros servicios de administración Linux
Porque tener backup está bien.
Tener un backup que realmente puedas restaurar de forma eficiente cuando lo necesites está bastante mejor.