ghettoVCB es una herramienta bastante simple para realizar respaldos de máquinas virtuales directamente desde VMware ESXi.

En esta guía vamos a dejarlo funcionando con un servidor NFSv4 como destino y automatizar los respaldos mediante cron.

Si todavía no tienes un NFS funcionando, revisa primero nuestra guía:

Cómo instalar y configurar un servidor NFS en Linux

La idea es terminar con algo así:

VMware ESXi
     |
     | NFSv4
     v
/vmfs/volumes/bkp/
     |
     +-- respaldo_vms/
           |
           +-- ghettoVCB/
           +-- backups/
           +-- logs/

Habilitar SSH en ESXi

Para realizar la configuración desde la consola del ESXi vamos a utilizar SSH.

Desde vSphere Client:

  1. Selecciona el host ESXi.
  2. Ve a Configure.
  3. Entra en System > Services.
  4. Busca TSM-SSH.
  5. Selecciona Start.

Una vez habilitado, podemos conectarnos:

ssh root@192.168.10.10

Agregar el NFS como datastore en ESXi

Antes de agregar el datastore necesitamos que el ESXi tenga conectividad hacia el servidor NFS.

Lo recomendable es utilizar un VMkernel dedicado para tráfico de almacenamiento. Por ejemplo:

ESXi
  |
  +-- vmk0  Administración
  |
  +-- vmk1  NFS
            |
            +-- 192.168.10.20

Desde el ESXi podemos comprobar la conectividad hacia el servidor NFS:

vmkping -I vmk1 192.168.10.20

Si responde, tenemos conectividad entre el VMkernel y el servidor NFS.

Esto es importante porque el servidor NFS debe permitir la IP que realmente utilizará el ESXi para acceder al almacenamiento.

Agregar el datastore desde vSphere Client

Desde vSphere Client:

  1. Seleccionamos el ESXi donde queremos agregar el almacenamiento.
  2. Vamos a Storage.
  3. Seleccionamos Datastores.
  4. Hacemos clic en New Datastore.
  5. En el tipo de datastore seleccionamos NFS.
  6. Seleccionamos NFS 4.1.
  7. Definimos el nombre del datastore.

NOTA: Dejar usuario y password en blanco.

Por ejemplo:

bkp

Luego configuramos el servidor NFS:

NFS Server: 192.168.10.20
NFS Share:  /backup

El nombre del datastore puede ser cualquiera. La ruta del share, en cambio, debe coincidir exactamente con el export configurado en el servidor NFS.

En nuestro ejemplo:

Servidor NFS:
    /backup

ESXi:
    datastore: bkp

Finalmente seleccionamos el host o los hosts que tendrán acceso al datastore y terminamos el asistente.

Una vez creado, deberíamos verlo en:

Storage > Datastores

como:

bkp

Y desde la consola del ESXi podremos acceder a él como:

/vmfs/volumes/bkp/

Si tenemos un cluster con vCenter

Si estamos trabajando con un cluster administrado por vCenter, podemos agregar el datastore a varios ESXi durante el mismo procedimiento.

Esto es importante cuando utilizamos DRS.

Todos los hosts que puedan ejecutar las VMs que queremos respaldar deben tener acceso al mismo datastore NFS.

Por ejemplo:

vCenter
   |
   +-- Cluster
         |
         +-- esxi01
         +-- esxi02
         +-- esxi03
                |
                +-- NFS: bkp

No basta con agregar el NFS solamente a esxi01.

Si DRS mueve una VM a esxi02 y ese host no tiene acceso al datastore, no vamos a poder respaldar esa VM.

Comprobar desde ESXi (por SSH)

Una vez agregado el datastore podemos comprobarlo desde la consola:

esxcli storage nfs41 list

Deberíamos ver el datastore bkp listado y montado de esta manera:

[root@esx1:~] esxcli storage nfs41 list
Volume Name  Host(s)    Share     Vmknics  Accessible  Mounted  Connections  Read-Only  Security   isPE  Hardware Acceleration
-----------  ---------  --------  -------  ----------  -------  -----------  ---------  --------  -----  ---------------------
bkp          93.0.0.10  /storage  None           true     true            1      false  AUTH_SYS  false  Not Supported

También podemos comprobar directamente el filesystem:

ls -lh /vmfs/volumes/bkp/

Debería mostar los archivos que contiene el NFS:

[root@esx1:~] ls -lh /vmfs/volumes/bkp/
total 40
drwxr-xr-x    3 root     root        4.0K Aug 28 23:13 ISOS
drwxr-xr-x    5 root     root        4.0K May  9  2024 VMware
drwx------    2 root     root       16.0K Aug 28  2019 lost+found
drwxr-xr-x   52 root     root        4.0K Aug 20 23:49 respaldo_vms

Si todo está correcto, ya tenemos el NFS disponible en ESXi y podemos continuar con la configuración de ghettoVCB.

NFS 4.1 y VMkernel

En una instalación simple, basta con que el ESXi tenga un VMkernel con conectividad hacia la red del NFS.

En entornos donde tenemos varias redes o queremos controlar exactamente por qué VMkernel sale el tráfico NFS, ESXi 8 permite utilizar vmkportbind para asociar el tráfico NFS 4.1 a determinados VMkernel. Esta funcionalidad está disponible para NFS 4.1 desde ESXi 8.0 Update 3. :contentReference[oaicite:1]{index=1}

Para una instalación sencilla de backups no necesitamos complicarlo. Primero hagamos que funcione correctamente y después optimizamos si realmente hace falta.

Descargar ghettoVCB

Vamos a mantener ghettoVCB directamente en el NFS.

De esta forma no necesitamos instalar nada adicional en cada ESXi y todos los hosts pueden utilizar la misma estructura.

Nos movemos al directorio donde vamos a dejar la herramienta:

cd /vmfs/volumes/bkp/respaldo_vms/

Descargamos ghettoVCB desde su repositorio oficial:

wget https://github.com/lamw/ghettoVCB/archive/refs/heads/master.zip

NOTA: Puede que wget no funcione bien en el ESXi, si no funciona, pueden descargarlo desde el servidor NFS y dejar los archivos en el mismo PATH

Creamos el directorio:

mkdir -p ghettoVCB

Extraemos el archivo:

unzip master.zip

Movemos el contenido:

mv ghettoVCB-master/* ghettoVCB/

Eliminamos los archivos que ya no necesitamos:

rm -rf ghettoVCB-master master.zip

La estructura debería quedar aproximadamente así:

/vmfs/volumes/bkp/respaldo_vms/ghettoVCB/
├── ghettoVCB.sh
├── ghettoVCB.conf
├── logs/
└── backups/

Verificamos que el script exista:

ls -lh /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/ghettoVCB.sh

Y le damos permisos de ejecución:

chmod +x /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/ghettoVCB.sh

Antes de continuar, conviene ejecutar:

/vmfs/volumes/bkp/respaldo_vms/ghettoVCB/ghettoVCB.sh -h

Si aparece la ayuda de ghettoVCB, ya tenemos la herramienta funcionando.

Configuración básica de ghettoVCB

Si siguieron al pie de la letra esta guía, la configuración de ghettoVCB está en:

/vmfs/volumes/bkp/respaldo_vms/ghettoVCB/ghettoVCB.conf

Para este escenario utilizaremos una configuración sencilla:

VM_BACKUP_VOLUME=/vmfs/volumes/bkp/respaldo_vms/
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=2
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=3
POWER_DOWN_TIMEOUT=5
ENABLE_COMPRESSION=0
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0
SNAPSHOT_TIMEOUT=15
WORKDIR_DEBUG=0

Vamos a detallar las opciones más importantes:

Destino del backup

VM_BACKUP_VOLUME=/vmfs/volumes/bkp/respaldo_vms/

Aquí indicamos dónde se van a guardar los respaldos.

Formato de los discos

DISK_BACKUP_FORMAT=thin
¿Qué significa Thin, Thick y Sparse?

En VMware, un disco thin no ocupa inmediatamente todo el espacio definido para el VMDK. Si creamos un disco de 500 GB pero la máquina utiliza solamente 100 GB, el archivo puede ocupar aproximadamente esos 100 GB en el almacenamiento, dependiendo de su contenido y configuración.

Un disco thick, en cambio, reserva desde el principio todo el espacio definido para el disco virtual.

Y aquí es donde aparece el concepto sparse.

Un archivo sparse es un archivo que puede tener un tamaño lógico grande, pero que físicamente ocupa mucho menos espacio porque las zonas que todavía no contienen datos no necesitan bloques reales en el filesystem.

Por ejemplo:

Tamaño lógico:       500 GB
Espacio utilizado:   100 GB

El archivo puede aparecer como de 500 GB, pero consumir solamente unos 100 GB de espacio físico.

Esto es justamente lo que nos interesa conservar cuando hacemos nuestros respaldos.

Por eso utilizamos:

DISK_BACKUP_FORMAT=thin

El formato thin permite mantener esta característica y evitar que un VMDK que utiliza poco espacio termine ocupando innecesariamente todo su tamaño lógico en el backup.

Hay que tener cuidado al copiar, comprimir o mover estos archivos. Algunas herramientas pueden convertir un archivo sparse en uno completamente asignado y terminar consumiendo mucho más espacio del esperado.

En otras palabras:

Thick
  └── reserva todo el espacio

Thin
  └── utiliza espacio según necesidad

Sparse
  └── permite que un archivo tenga un tamaño lógico mayor
      que el espacio físico que realmente ocupa

Por eso, cuando trabajamos con backups de VMDK, preservar los archivos sparse es importante.

NOTA: Al final de esta guía les dejo el link a una herramienta que hicimos para poder comprimir los respaldos y preservar el formato thin de los discos de vmware.

Rotación de los respaldos

VM_BACKUP_ROTATION_COUNT=2

Con esto mantenemos dos backups de cada VM (uno cada semana, o uno diario, como ustedes decidan configurar esto).

Por ejemplo:

VM01-2026-08-21
VM01-2026-08-28

Cuando se genera un nuevo backup, ghettoVCB elimina los que exceden la cantidad configurada. (borra el más viejo)

La cantidad de copias que debemos mantener depende de nuestra política de respaldo y del espacio disponible. Dos copias son solamente un ejemplo razonable para esta configuración.

No apagar las máquinas virtuales

POWER_VM_DOWN_BEFORE_BACKUP=0

No queremos apagar las VMs durante el respaldo, una de las gracias de este sistema, es que puede respaldar en caliente.

ghettoVCB trabajará utilizando snapshots para realizar el backup.

No respaldar VMs que tengan snapshots

ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0

Esta opción es importante en nuestra configuración.

Cuando una VM ya tiene snapshots, el disco virtual que está recibiendo las nuevas escrituras no es necesariamente el VMDK base. VMware utiliza una cadena de snapshots (-000001.vmdk, -000002.vmdk, etc.) y los cambios se van escribiendo en esos discos delta.

Si ghettoVCB encuentra una VM con snapshots y permitimos el backup, podemos terminar respaldando una cadena de discos dependientes entre sí, en lugar de tener un backup limpio del estado actual de la VM.

Sin compresión

ENABLE_COMPRESSION=0

Por ahora dejamos la compresión desactivada.

El backup se genera primero y después podemos procesar los VMDK desde el servidor NFS.

Esto permite separar las dos tareas y evitar agregar carga innecesaria al ESXi durante el respaldo, queremos que los ESX se dediquen a que las VM corran correctamente, activar la compresión va a generar una carga de CPU muy grande en los ESX y va hacer que los respaldos tarden mucho más, tanto que hasta podrían no alcanzar a terminar durante nuestra típica ventana de respaldo de viernes en la tarde a domingo en la noche.

Si necesitas comprimir los VMDK manteniendo correctamente los archivos thin/sparse, puedes revisar nuestra guía:

Cómo comprimir respaldos VMDK de VMware sin destruir los archivos Sparse

Recomendaciones

  1. Nombres de las VMs: evita espacios y caracteres especiales. Aunque VMware los permite, pueden producir problemas cuando el nombre pasa por scripts, ghettoVCB o procesos de copia. Es mejor utilizar nombres simples como WEB.ORANGEBOX.CL, ZABBIX.ORANGEBOX.CL o WAZUH.ORANGEBOX.CL.

  2. Nombres de los discos: cuando una VM se crea clonando otra VM o utilizando una plantilla, es bastante común que los VMDK mantengan el nombre que tenían originalmente. Puedes terminar con una VM llamada ERP01 que tenga discos llamados Template-Linux-01.vmdk. Esto no afecta necesariamente al funcionamiento, pero sí puede convertirse en un problema cuando tengas que buscar o restaurar una VM. El nombre de la VM debe ser descriptivo y fácil de identificar, porque será lo primero que busquemos cuando necesitemos recuperar un servidor.

  3. Espacio disponible: considera que ghettoVCB necesita terminar completamente el nuevo backup antes de eliminar la rotación más antigua. Por ejemplo, si un backup ocupa 100 GB y configuramos VM_BACKUP_ROTATION_COUNT=2, debemos tener espacio suficiente para aproximadamente 300 GB, porque durante la ejecución podemos tener el backup actual y las dos copias anteriores. En la práctica, deja margen adicional para evitar que el NFS llegue al 100%.

  4. DRS: si los ESXi están administrados por vCenter y utilizan DRS, no mantengas una lista fija de VMs por host. Una VM puede estar hoy en esxi01 y mañana en esxi02. Por eso en nuestra configuración generamos el listado justo antes del backup.

  5. Probar la restauración: de vez en cuando restaura una VM desde el backup. El objetivo del respaldo no es acumular VMDK, sino poder recuperar una máquina cuando realmente haga falta.

¿Cuánto puede tardar un backup?

La velocidad de la red tiene un impacto enorme cuando estamos moviendo máquinas virtuales grandes.

La siguiente tabla muestra el tiempo teórico aproximado para transferir 100 GB, suponiendo que la red es el único límite y que estamos utilizando el 100% de su capacidad:

Red Velocidad teórica 100 GB aprox. 1 TB aprox.
100 Mbps 12,5 MB/s 2 h 13 min 22 h 45 min
1 GbE 125 MB/s 13 min 20 s 2 h 13 min
10 GbE 1.250 MB/s 1 min 20 s 13 min 20 s

Estos son tiempos teóricos. En un backup real hay que sumar el rendimiento del storage, ESXi, NFS, procesamiento de snapshots y el overhead de la red.

Por eso una VM de 1 TB no es simplemente “copiar un archivo de 1 TB”. Dependiendo de la infraestructura, ese respaldo puede tardar minutos o prácticamente todo el día.

Si tenemos un servidor con discos capaces de escribir a varios cientos de MB/s pero seguimos utilizando una red de 1 GbE, la red se convierte inmediatamente en el cuello de botella.

También hay que tener presente que estamos hablando de 100 GB transferidos, no necesariamente de una VM con un disco virtual de 100 GB.

Un VMDK thin puede tener un tamaño lógico de 1 TB y utilizar físicamente mucho menos espacio. Por eso el tamaño del disco virtual y el tamaño real del backup no necesariamente son iguales.

Probemos si funciona.

Antes de continuar, algunas recomendaciones de buenas prácticas y buenos modales, tal como me enseñó mi abuelita.

Eliminar snapshots antes del backup

Como ya mencióné, este punto es importante para el correcto funcionamiento del respaldo.

Antes de seguir debemos asegurarnos que las VMs no tienen snapshots.

Para eso vamos a usar:

for i in $(vim-cmd vmsvc/getallvms|awk {'print $1'}|grep -v Vmid); do vim-cmd vmsvc/snapshot.removeall $i; done

Obtener las VMs que están ejecutándose en el ESXi

Aquí aparece una diferencia importante entre un ESXi standalone y un cluster administrado por vCenter.

Si tenemos un ESXi standalone, normalmente sabemos qué VMs están en ese host.

Pero si el ESXi pertenece a un cluster administrado por vCenter y utilizamos DRS, las máquinas virtuales pueden moverse entre hosts.

Por eso no conviene mantener una lista fija de VMs.

En lugar de eso, justo antes del backup obtenemos las VMs que están ejecutándose en ese momento en el host:

esxcli vm process list|grep -v '^\ '|grep -v '^$' |grep -v vCLS > /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/vms_to_backup.$HOSTNAME

Esto genera un archivo como:

vms_to_backup.esxi01.orangebox.cl

o:

vms_to_backup.esxi02.orangebox.cl

El uso de $HOSTNAME es importante cuando varios ESXi utilizan el mismo NFS.

Así cada host mantiene su propio listado y sus propios logs.

Ejecutar el backup

Ya tenemos la configuración, el listado de maquinas a respaldar y eliminamos los snapshots, ahora podemos correr un backup para comprobar que todo está correcto:

/vmfs/volumes/bkp/respaldo_vms/ghettoVCB/ghettoVCB.sh -g /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/ghettoVCB.conf -f /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/vms_to_backup.$HOSTNAME -l /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/logs/respaldo-VMS-$HOSTNAME-$(date +%F-%T).log

Programar los respaldos automáticos.

Hacer persistente la configuración

En VMware no basta con modificar el crontab directamente y agregar las tareas como lo hacemos siempre en un Linux, ya que si se reinicia ese ESXi, los archivos de cron se borran y se pierde toda la configuración.

Para dejar esta configuración persistente, tenemos que editar un script que corre durante el arranque de cada ESXi, para que vuelva a escribir la configuración del crontab:

vi /etc/rc.local.d/local.sh

Hay que agregar esto al final:

# Note: This script will not be run when UEFI secure boot is enabled.
/bin/kill $(cat /var/run/crond.pid)
/bin/echo '0 21 * * 5  for i in $(vim-cmd vmsvc/getallvms|awk {'\'print \$1\''}|grep -v Vmid); do vim-cmd vmsvc/snapshot.removeall $i; done' >> /var/spool/cron/crontabs/root
/bin/echo '0  23 * * 5  esxcli vm process list|grep -v '"'^\ '"'|grep -v '"'^$'"' |grep -v vCLS > /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/vms_to_backup.'"$HOSTNAME"'' >> /var/spool/cron/crontabs/root
/bin/echo '1  23 * * 5  /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/ghettoVCB.sh -g /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/ghettoVCB.conf -f /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/vms_to_backup.'"$HOSTNAME"' -l /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/logs/respaldo-VMS-'"$HOSTNAME"'-$(date +'%F-%T').log' >> /var/spool/cron/crontabs/root
crond
exit 0

NOTA: Ojo! NO poner todos los ESX a respaldar a la misma hora, pueden saturar la red y el servidor NFS, lo ideal es que lo hagan de manera secuencial.

De esta forma el flujo completo queda:

Viernes 21:00
    |
    +-- eliminar snapshots
    |
    v
Viernes 23:00
    |
    +-- obtener VMs que están en ESTE ESXi
    |
    v
Viernes 23:01
    |
    +-- ejecutar ghettoVCB
    |
    v
NFS

Guarden los cambios y ahora debemos ejecutar:

/sbin/auto-backup.sh

Esto guarda los cambios y al bootear el ESXi va a crear el archivo /var/spool/cron/crontabs/root con las tareas que acabamos de programar.

Ojo con Secure Boot

Hay una consideración importante.

/etc/rc.local.d/local.sh no se ejecuta cuando UEFI Secure Boot está habilitado.

Esto significa que si dependemos de este archivo para reconstruir las tareas de cron, después de reiniciar el ESXi los respaldos automáticos no volverán a quedar configurados.

El resultado es bastante malo: todo parece estar funcionando, pero el viernes en la noche no se ejecuta ningún backup.

Si vamos a utilizar este método, debemos considerar esta limitación antes de habilitar Secure Boot.

Revisar los backups

Después de ejecutar el backup podemos revisar los logs:

ls -lh /vmfs/volumes/bkp/respaldo_vms/ghettoVCB/logs/

Y comprobar los backups generados en el NFS.

También podemos revisar rápidamente el espacio:

df -h /vmfs/volumes/bkp

No basta con que cron haya ejecutado el comando. Hay que revisar que ghettoVCB haya terminado correctamente y que los archivos realmente estén en el almacenamiento.

Listo

Con esto tenemos un esquema simple de respaldo:

VMware ESXi
      |
      | ghettoVCB
      v
    NFS
      |
      +-- backups
      +-- logs
      +-- configuración

En un ESXi standalone funciona directamente.

En un cluster con vCenter y DRS, el listado dinámico de VMs permite que cada host respalde solamente las máquinas que tiene ejecutándose en ese momento.

Y como ghettoVCB, su configuración y los logs están en el NFS, podemos mantener una estructura común para todos los hosts.

¿Necesitas implementar algo similar?

Si necesitas implementar una estrategia de respaldo para VMware, en OrangeBox podemos ayudarte a diseñarla, implementarla y dejarla automatizada.

Conoce nuestros servicios de infraestructura crítica