Buenas prácticas de backup de VMware: snapshots, CBT, replicación y errores típicos en la RESTauración

Quienes operan entornos vSphere conocen el patrón: las copias de seguridad aparecen «verdes», pero en caso real faltan minutos, las aplicaciones arrancan de forma inconsistente o la RESTauración tarda mucho más de lo previsto. Buenas prácticas de backup de VMware son por tanto menos una cuestión de herramienta y más una disciplina operativa: usar snapshots correctamente, entender Changed Block Tracking (CBT), situar la replicación de forma clara y excluir sistemáticamente las trampas de RESTauración.

Esta entrada va dirigida a administradores, ingenieros de sistemas, operadores y proveedores técnicos de servicios TI. El enfoque no es «cómo hago clic en el producto X», sino: qué mecanismos técnicos actúan en segundo plano, qué requisitos deben cumplirse, qué riesgos son típicos — y cómo construir estrategias de verificación y de contingencia que sean robustas en el día a día.

Buenas prácticas de backup de VMware en la práctica

La mayoría de las copias de seguridad sin agentes en vSphere utilizan las vSphere APIs for Data Protection (VADP). De forma simplificada ocurre una cadena: crear un snapshot, leer los datos (completo o incremental), eliminar el snapshot (commit/merge). El snapshot no es un „backup“ sino un estado temporal que permite lecturas consistentes. Según la configuración, en el sistema operativo invitado además se desencadena un quiescing (se congelan los buffers de aplicación o del sistema de ficheros), típicamente a través de VMware Tools y, en Windows, mediante VSS (Volume Shadow Copy Service).

Importante para la operación: una copia de seguridad no solo carga la red y el repositorio. Afecta sobre todo al datastore, al controlador de almacenamiento y a la propia VM, porque los archivos delta del snapshot generan I/O adicional y la posterior fusión (snapshot-commit) también es intensiva en I/O. Si las copias se ejecutan „a alguna hora de la noche“, pero la carga del almacenamiento ya es alta (jobs por lotes, ETL, reconstrucción de índices, rotación de logs), aumentan los riesgos de largos tiempos de snapshot y de timeouts.

2) Snapshots en la práctica: uso, límites y errores típicos

Un snapshot de VMware no guarda el estado completo de la VM como una copia independiente, sino que crea estructuras delta (los bloques modificados se registran en archivos separados). Mientras el snapshot está activo, esa estructura delta crece — en función de la tasa de cambios, el patrón de I/O y el tamaño del disco de la VM. Ahí radica la razón por la que «dejar snapshots» es un riesgo operativo.

2.1 Por qué los snapshots largos son peligrosos

Los largos tiempos de snapshot suelen provocar:

• Degradación del rendimiento en la VM (rutas de escritura adicionales, mayor latencia).
• Crecimiento del datastore (los archivos delta se llenan; con Thin Provisioning esto puede escalar más rápido de lo previsto).
• Picos de commit (el merge tarda mucho y compite con el I/O productivo).
• Cascadas en las ventanas de backup: un commit retrasado desplaza otros trabajos y al final se genera un atasco.

Un tropiezo frecuente: las copias de seguridad se interrumpen, pero el snapshot permanece (según la herramienta/caso de fallo) o el commit se retrasa. Esto no siempre se aprecia de inmediato en la consola de backup, pero sí en el cliente vSphere o mediante alertas sobre la antigüedad y el número de snapshots.

2.2 Quiesce, VSS y „application-aware“: cuándo consistente es realmente consistente

„Application-aware“ significa que no solo el sistema de archivos está consistente, sino que también las aplicaciones (p. ej. bases de datos) llevan sus buffers de escritura a un estado definido. En Windows eso ocurre típicamente mediante VSS-Writer. En Linux depende en gran medida de la aplicación y del mecanismo empleado (p. ej. scripts, hooks de pre-/post-freeze, modos de backup propios de la base de datos). Esto es determinante: una imagen „crash-consistente“ puede arrancar, pero las transacciones de la base de datos o los índices pueden, en el peor de los casos, forzar una recuperación más larga o fallar.

Para los responsables de operación esto significa: defina por clase de workload (Domain Controller, SQL/Exchange, PostgreSQL, File-Server, servidores de aplicación) de forma explícita qué grado de consistencia es necesario — y documente los prerrequisitos necesarios (versión de VMware Tools, estado del VSS-Writer, servicios, scripts, credenciales, reglas de firewall).

2.3 Lista de comprobación: higiene de snapshots en vSphere

• Alarmas/Informes para snapshots con más de X horas y más de Y snapshots por VM.
• Planificar los jobs de backup de modo que los snapshots existan lo más breve posible (tener en cuenta la carga del almacenamiento).
• Regla: los snapshots son temporales. Para retenciones prolongadas no sustituyen a backup/archivo.
• Antes de cambios mayores (día de parches, cambios de esquema): plan claro de cuándo se permiten snapshots — y cuándo no (p. ej. con alta tasa de escritura en la BD).

3) CBT (Changed Block Tracking): bendición para incrementales, riesgo ante la inconsistencia

CBT, Changed Block Tracking, es una función de vSphere que, por disco virtual, sigue qué bloques han cambiado desde un punto en el tiempo definido. El software de backup puede así crear backups incrementales sin leer la totalidad del disco cada vez. Eso ahorra tiempo y reduce I/O — siempre que CBT sea correcto.

3.1 Cómo falla CBT (y por qué a menudo no se detecta)

CBT puede „estar equivocado“ cuando el historial de cambios no coincide con los datos reales. Esto puede ocurrir por determinados escenarios de almacenamiento/snapshot/clone, por bugs en versiones antiguas de vSphere o por secuencias desafortunadas de operaciones de snapshot y redimensiones. Lo problemático: el backup puede continuar completándose con éxito, pero al RESTaurar faltan bloques o el estado de los datos está inconsistente.

Operativamente esto significa: ante problemas de RESTauración inexplicables o backups incrementales anómalos (inusualmente pequeños o inusualmente rápidos), CBT es un candidato. Una estrategia de retroceso probada es un reinicio activo de la información CBT (típicamente mediante una copia de seguridad completa forzada o mediante los mecanismos de vSphere que reconstruyen los datos de seguimiento de cambios). Cómo se implementa esto en la herramienta concreta depende del producto; lo importante es el principio: «Si hay dudas: volver a establecer una línea base coherente.»

3.2 Puntos de verificación para una operación compatible con CBT

• Operar vSphere/ESXi en una versión estable y soportada (los errores de CBT están bien documentados históricamente; las versiones antiguas son riesgosas).
• Conocer los casos límite de storage/snapshots (p. ej., cadenas de snapshots agresivas, redimensiones frecuentes de discos).
• Pruebas regulares de RESTauración de cadenas incrementales (no solo de copias completas).
• Monitorización de patrones inusuales: incrementales persistentemente «demasiado pequeños», a pesar de una alta tasa de cambios.

4) Replicación vs. copia de seguridad: mismo resultado, objetivos distintos

La replicación (p. ej., mediante replicación del hipervisor o del almacenamiento) copia estados de máquinas virtuales o bloques de almacenamiento de forma prácticamente inmediata a una segunda ubicación. El objetivo suele ser un buen RPO (Recovery Point Objective: pérdida máxima de datos en tiempo) y un RTO rápido (Recovery Time Objective: tiempo hasta la RESTauración). La copia de seguridad, en cambio, se orienta más a la versionado, conservación a largo plazo, inmutabilidad y la capacidad de revertir también «errores lógicos» (cifrado por ransomware, borrado accidental, actualizaciones defectuosas).

4.1 Suposiciones erróneas típicas

• «Replicamos, así que no necesitamos copia de seguridad.» Falso, porque la replicación suele replicar también los errores (p. ej., cifrado, corrupción de datos, configuración incorrecta).
• «Las copias de seguridad son demasiado lentas, así que la replicación es suficiente.» La replicación no sustituye a los estados históricos ni a los requisitos de auditoría.
• «Snapshots = puntos de RESTauración.» Los snapshots son a corto plazo, críticos para el rendimiento y no están diseñados para conservación.

4.2 Buena práctica: combinar, pero mantener separación clara

En diseños robustos existen ambos: replicación para la continuidad operativa (failover de DR) y copias de seguridad para la protección de datos y versiones. Lo decisivo es la separación de las dominios de fallo:

• Segmentar el repositorio de copias de seguridad de forma separada (red, credenciales, MFA/RBAC).
• Planificar destinos de almacenamiento inmutables (inmutabilidad) cuando el ransomware sea un riesgo realista.
• Mantener el runbook de replicación separado del runbook de RESTauración: distinto objetivo, pasos diferentes, pruebas distintas.

5) Trampas de RESTauración: por qué «RESTauración exitosa» no equivale a «sistema nuevamente disponible»

Muchos equipos prueban las RESTauraciones con poca frecuencia o de forma superficial. Una RESTauración de VM puede ser técnicamente exitosa mientras la aplicación no arranca, la recuperación de la base de datos se queda colgada o la red/identidad no encajan. Precisamente en soluciones de software cercanas a procesos, el punto crítico no es el arranque, sino la capacidad funcional de volver a arrancar (dependencias, certificados, DNS, licencias, integraciones).

5.1 Errores frecuentes de RESTore desde el entorno de producción

• Datos de aplicación inconsistentes (crash-consistent en lugar de application-aware; VSS-Writer defectuoso; Linux-DB sin freeze/hook).
• Diseño de repositorio demasiado ajustado: el RESTore falla porque los datos existen, pero el „cold tier“/almacenamiento de objetos es demasiado lento para el RTO.
• Dependencias de red e identidad: controladores de dominio/LDAP/DNS no vuelven a estar en línea en el orden correcto.
• Drivers/controladores/modo de arranque: desajuste UEFI/BIOS, Secure Boot, controladores virtuales modificados.
• Cifrado/keys: BitLocker/LUKS/claves de aplicación no disponibles; el RESTore arranca, pero los datos permanecen ilegibles.
• Permisos y secrets: Service-Accounts modificadas, contraseñas rotadas, la copia de seguridad contiene secrets obsoletos.

5.2 Una prueba de RESTore pragmática: qué debería comprobar como mínimo

Una prueba de RESTore no tiene que ser cada vez un DR completo. Pero debe ser reproducible y medible. Para muchos entornos funciona un ciclo mensual con cargas de trabajo rotativas:

• RESTaurar la VM en una red aislada (sin conflicto de IP/DNS).
• Comprobar arranque y servicios básicos (logs del sistema, comprobación de discos, registros de eventos).
• Verificar la salud de la aplicación (p. ej., inicio de sesión, endpoint de API, planificador de trabajos).
• Si interviene la BD: arrancar la base de datos, medir el tiempo de recovery, ejecutar comprobaciones de integridad.
• Documentar RTO/RPO y justificar las desviaciones (capacidad, paralelismo, rendimiento del repositorio).

Importante: no pruebe solo el „último full“. Pruebe también cadenas incrementales, porque ahí CBT, la integridad de la cadena y las rutas de fusión son especialmente relevantes.

6) Troubleshooting: Wenn Backups grün sind, aber Snapshots bleiben oder Jobs „hängen“

Síntomas típicos en la operación diaria: el snapshot se queda parado, el job de backup dura inusualmente mucho, el commit lleva una eternidad, la latencia del datastore aumenta. La causa a menudo no es „backup roto“, sino un cuello de botella en la ruta de almacenamiento o un guest-quiescing que no vuelve correctamente.

6.1 Secuencia de comprobación sistemática (sin dependencia de herramientas)

1. vCenter Events: eventos de create/remove de snapshot, timeouts, necesidad de consolidación.
2. Datastore/Storage: picos de latencia, queue depth, carga del controlador, rebuilds, congestión.
3. VM-Guest: estado de VMware Tools, VSS-Writer (Windows), logs de aplicaciones, duración del freeze.
4. Backup-Proxy/Transport: HotAdd/NBD/SAN-Transport (según la arquitectura), rutas de red, MTU, pérdida de paquetes.
5. Repository: tasas de escritura/lectura, sobrecarga de dedupe/compresión, tiempo de recuperación desde almacenamiento de objetos.

6.2 PowerCLI: Snapshots finden und Alter auswerten

Para una visión rápida en entornos mixtos, PowerCLI suele ser práctico en la práctica. El siguiente ejemplo lista snapshots y su antigüedad (días). Ajuste filtros y salida según sus estándares.

# Voraussetzung: VMware PowerCLI installiert, Verbindung zu vCenter
# Connect-VIServer -Server vcenter.example.local

Get-VM | Get-Snapshot | Select-Object 
  @{N='VM';E={$_.VM.Name}}, Name, Created, Description, SizeMB, 
  @{N='AgeDays';E={[math]::Round(((Get-Date) - $_.Created).TotalDays,2)}} | 
  Sort-Object AgeDays -Descending

Nota operativa: «SizeMB» no siempre refleja de forma perfecta el impacto real en el almacenamiento (backend de almacenamiento, Thin/Thick, patrones de datos), pero como indicador junto con la antigüedad y la cantidad resulta muy útil.

6.3 PowerCLI: VMs mit „Consolidation needed“ identifizieren

Si se eliminaron snapshots pero las estructuras delta no se consolidaron correctamente, vSphere puede informar „Consolidation needed“. Es una señal de advertencia porque la VM puede seguir funcionando con archivos delta adicionales.

Get-VM | Where-Object {$_.ExtensionData.Runtime.ConsolidationNeeded -eq $true} | 
  Select-Object Name, PowerState

Si obtiene resultados aquí, compruebe primero la latencia del almacenamiento y los trabajos en curso con I/O intensivo. Forzar una consolidación en una fase de alta carga puede causar más daño que beneficio. En su lugar, planifique una ventana de mantenimiento controlada y tenga preparado un plan de contingencia (p. ej. capacidad de almacenamiento, migración de emergencia, orden de parada/arranque definido).

7) Umsetzung im Betrieb: Backup-Fenster, Parallelität, Ressourcen und Rückfallstrategie

Muchos problemas de backup no se deben a falta de función, sino a sobrecarga: demasiados jobs en paralelo, proxies demasiado pequeños, I/O insuficiente en el repositorio, datastores dimensionados de forma ajustada. Las mejores prácticas aquí son, sobre todo, reglas de capacidad y de procedimiento.

7.1 Parallelität bewusst begrenzen

Más jobs en paralelo no acortan automáticamente la ventana. A partir de cierto punto los jobs compiten por los mismos recursos: cola de almacenamiento, red, CPU (compresión/dedupe), I/O del proxy. Es sensato aplicar una paralelidad controlada por datastore/cluster y por clase de carga de trabajo. Los sistemas especialmente intensivos en escritura (bases de datos, logging, message brokers) deberían programarse preferentemente en ventanas con baja tasa de cambios.

7.2 Full vs. Inkremental: Baseline-Strategie definieren

Las cadenas incrementales son eficientes, pero aumentan la dependencia de los metadatos, CBT y la integridad de la cadena. Defina:

• Con qué frecuencia se genera un Full sintético o un Full real.
• Cuánto pueden alargarse como máximo las cadenas (riesgo operativo vs. ahorro de almacenamiento).
• Cómo se actúa ante la sospecha de problemas con CBT o con la cadena (p. ej., Full forzado, nuevo job de backup, nueva cadena).

7.3 Rückfallstrategie (Runbook) für den Backup-Betrieb

Un Runbook no es un ejercicio de cumplimiento, sino que ahorra tiempo por la noche. Debe incluir como mínimo:

• Vías de contacto y escalado (almacenamiento, red, plataforma, aplicación).
• Reglas de decisión: cancelar job sí/no, eliminación de snapshot inmediata/pospuesta.
• Pasos de verificación con fuentes: vCenter Events, métricas de almacenamiento, logs de backup, logs del guest.
• Medidas de emergencia: reducir la paralelidad, reprogramar jobs, Full dirigido, prueba de RESTauración aislada.

8) Security und Ransomware-Realität: Warum Backup-Zonen und Rechte wichtiger werden

En muchos incidentes no es el formato del backup lo que falla, sino la cadena de acceso: si un atacante obtiene privilegios de Domain Admin, los servidores de backup y los repositorios suelen ser el siguiente objetivo. Por eso, en el contexto VMware las buenas prácticas incluyen líneas de separación estrictas:

• Identidades separadas para las operaciones de backup (Least Privilege, RBAC).
• Segmentación de red: tráfico de backup y gestión no en la misma red plana.
• Inmutabilidad (Inmutabilidad, mecanismos tipo WORM) para periodos críticos de retención.
• Copia offline o con air-gap para el escenario de peor caso (dependiendo de tamaño/RTO).

Lo importante es la viabilidad: barreras demasiado estrictas que se eluden en la práctica diaria son peores que un modelo sólido y controlado. Compruebe por tanto de forma regular si sus procesos se aplican realmente (p. ej. derechos de RESTauración solo para roles definidos; cuentas Break-Glass con auditoría).

9) Listas de verificación prácticas: Antes del próximo auditoría o prueba DR

9.1 Chequeo operativo: «¿Funciona realmente mi backup de VMware?»

• ¿Existen RPO/RTO documentados por clase de sistema y se miden?
• ¿Están los snapshots/consolidación en el monitoreo y se registran las desviaciones?
• ¿Se prueban activamente las cadenas incrementales (no solo backups completos)?
• ¿Está claro qué sistemas deben respaldarse de forma application-aware?
• ¿Está el repositorio protegido contra manipulación (permisos, red, inmutabilidad, administradores separados)?
• ¿Existe un entorno de pruebas de RESTauración (red aislada, estrategia definida de DNS/AD)?

9.2 Preflight técnico antes de cambios importantes

• ¿Salud del storage OK (latencia, capacidad, sin rebuilds en la ventana crítica)?
• ¿VMware Tools está lo suficientemente actualizado para los requisitos de quiescing?
• ¿Ventana de backup no sobrecargada (paralelismo/proxies/I/O del repositorio)?
• Plan de emergencia: si el commit del snapshot se queda colgado, ¿quién decide qué y cuándo?

Conclusión: los backups de VMware son tan buenos como su gestión de RESTauración y snapshots

Las buenas prácticas sólidas para backups de VMware se fundamentan en tres pilares: mantener los snapshots breves y controlados, tomarse en serio CBT y las cadenas incrementales como posibles fuentes de fallo y separar claramente la replicación del backup. La prueba decisiva de calidad no es el estado del job en verde, sino una RESTauración ensayada de forma regular, incluida la verificación de las aplicaciones, con RTO/RPO documentados y un runbook para las incidencias típicas.

Si desea comprobar sistemáticamente su capacidad de RESTauración, el siguiente paso es un plan de pruebas claro con puntos de medida y casos de prueba reproducibles: Plan de prueba de RESTauración: Cómo comprobar la recuperabilidad de sus backups paso a paso.

En este tema también son importantes el backup incremental y el backup application-aware. El artículo sitúa estos aspectos de forma comprensible y muestra qué es relevante en el día a día.