Tabla de contenido
- Por qué la salida de VMware cambió la copia de seguridad de las máquinas virtuales
- Cómo funciona la copia de seguridad de KubeVirt: instantáneas CSI y congelación/descongelación
- Virtualización con KubeVirt frente a OpenShift: ¿cuál es la diferencia?
- Comparación de los métodos de copia de seguridad de KubeVirt
- Recuperación ante desastres para KubeVirt: RPO, RTO y conmutación por error
- Cómo realizar una copia de seguridad de una máquina virtual KubeVirt: paso a paso
- Resumen
Realizar copias de seguridad de máquinas virtuales KubeVirt implica proteger máquinas virtuales que ahora se ejecutan como pods de Kubernetes, utilizando instantáneas CSI de las solicitudes de volumen persistente de la máquina virtual, además de la congelación/descongelación consistente con la aplicación a través del agente invitado QEMU, en lugar de copias de seguridad de imágenes de máquinas virtuales heredadas. La definición de la máquina virtual, sus DataVolumes y PVC, y los datos que contienen son todos objetos de Kubernetes. Por lo tanto, una copia de seguridad de KubeVirt es una copia de seguridad de Kubernetes con la virtualización añadida.
El momento actual hace que esto sea urgente. Los cambios en las licencias de Broadcom han obligado a miles de equipos a planificar su salida de VMware, y Red Hat OpenShift Virtualization, basado en KubeVirt, es una de las opciones más comunes. Estos equipos llegan con herramientas de copia de seguridad de la era de vSphere que requieren una API de hipervisor, vCenter y archivos VMDK, ninguno de los cuales existe dentro de una máquina virtual de Kubernetes. Este artículo explica qué ha cambiado, cómo funciona la copia de seguridad de KubeVirt, qué método se adapta mejor a cada escenario y cómo extender la copia de seguridad a la recuperación ante desastres.
Por qué la salida de VMware cambió la copia de seguridad de las máquinas virtuales
La magnitud del cambio es cuantificable. La analista de Gartner, Julia Palmer, predice que Se estima que 351.000 millones de cargas de trabajo de VMware migrarán a otras plataformas para 2028., y una encuesta citada por InformationWeek encontró que solo el 71% de las organizaciones de TI planean permanecer completamente en VMware. La ventana también es finita: vSphere 8 llega al final del soporte general en octubre de 2027. En el lado del destino, Red Hat informó que el El número de máquinas virtuales que se ejecutan en OpenShift Virtualization aumentó en 417% en 2025., Los clústeres que ejecutan máquinas virtuales crecieron en 93%, y Red Hat Services evaluó más de 1,46 millones de máquinas virtuales en proyectos de migración.
Figura 1. La salida de VMware en cifras: previsión de migración de Gartner de 35%, 7% que se quedan completamente en VMware (encuesta citada por InformationWeek), fin del soporte para vSphere 8 en octubre de 2027, +417% máquinas virtuales en OpenShift Virtualization (Red Hat, 2026).
Lo que falla tras la migración es el propio modelo de copia de seguridad. En vSphere, el software de copia de seguridad se comunica con el hipervisor a través de VADP (vSphere APIs for Data Protection), realiza un seguimiento de los bloques modificados y lee los archivos VMDK del almacén de datos. En KubeVirt, no hay vCenter, ni VADP, ni VMDK. Una máquina virtual es un recurso personalizado VirtualMachine. Sus discos son PVC (persistent volume claims), normalmente aprovisionados desde DataVolumes por KubeVirt CDI (Containerized Data Importer), que importa una imagen qcow2 o raw a un volumen. La instancia en ejecución es un pod virt-launcher programado como cualquier otra carga de trabajo.
Una herramienta que solo entiende el almacenamiento puede copiar los bytes de PVC, pero pierde la especificación de la máquina virtual, las definiciones de conexión de red, los secretos de cloud-init y las relaciones entre ellos, por lo que la restauración se convierte en una reconstrucción manual bajo presión. Existe también un riesgo más silencioso: durante la migración de plataforma, la cobertura de copias de seguridad suele fallar silenciosamente, porque el antiguo agente de vSphere ya no está disponible y aún no se ha configurado nada equivalente en Kubernetes.
Cómo funciona la copia de seguridad de KubeVirt: instantáneas CSI y congelación/descongelación
Una máquina virtual KubeVirt es un pod con uno o más PVC conectados como discos, por lo que una copia de seguridad tiene dos capas: los objetos de Kubernetes (VirtualMachine, DataVolume, PVC, Secrets, Services, NetworkAttachmentDefinitions) y los datos de los bloques dentro de los PVC. La capa de objetos es YAML simple; la capa de datos está protegida mediante la API VolumeSnapshot de Kubernetes, implementada por el controlador CSI de su proveedor de almacenamiento.
Figura 2. Cómo funciona la copia de seguridad de KubeVirt: congelación/descongelación del agente invitado, CSI VolumeSnapshot por PVC, paquete VirtualMachineSnapshot y la copia fuera del clúster que convierte un punto de restauración en una copia de seguridad.
Cuando crea un VirtualMachineSnapshot, el objeto de instantánea de máquina virtual de KubeVirt, el controlador crea un VolumeSnapshot para cada volumen respaldado por CSI conectado a la VM y almacena una copia de la especificación y los metadatos de la VM junto con él. Los requisitos previos son una StorageClass cuyo controlador CSI admita instantáneas, una VolumeSnapshotClass para ese controlador y la puerta de la función Snapshot, que OpenShift Virtualization habilita de forma predeterminada. Según la Documentación de instantáneas de KubeVirt, Cuando la máquina virtual está en funcionamiento, el controlador comprueba si el agente invitado de QEMU está conectado. Si lo está, KubeVirt congela los sistemas de archivos invitados, crea una instantánea y los descongela posteriormente. Las instantáneas en línea tienen un plazo de tolerancia a fallos predeterminado de cinco minutos.
La congelación/descongelación es lo que separa los dos niveles de consistencia que todo administrador de copias de seguridad debería poder definir:
- Copia de seguridad consistente ante fallos Captura el disco exactamente como quedaría después de un corte de energía repentino. Es posible que sea necesario recuperar el sistema de archivos y las aplicaciones al arrancar, y se pueden perder las escrituras en la base de datos que estén en curso.
- Copia de seguridad coherente con la aplicación Se pausan las escrituras y se vacían los búferes antes de tomar la instantánea, utilizando la función de congelación/descongelación a través del agente invitado y, cuando sea necesario, scripts previos y posteriores a la instantánea que detienen las bases de datos. El resultado se restaura correctamente sin necesidad de reproducir el registro ni recuperar la base de datos.
Figura 3. Copia de seguridad de KubeVirt con consistencia ante fallos frente a consistencia de la aplicación.
KubeVirt registra el nivel de seguridad alcanzado: sin un agente conectado, la instantánea se marca como de mejor esfuerzo (consistente ante fallos), y un fallo en la congelación se indica con el símbolo QuiesceFailed. Para bases de datos, intermediarios de mensajes y cargas de trabajo de Windows, considere la condición AgentConnected de la máquina virtual como un requisito previo para la copia de seguridad.
Una regla que se mantiene sin cambios desde VMware es que una instantánea no es una copia de seguridad. Las instantáneas de volumen residen en el mismo almacenamiento que el PVC de origen. Para que los datos sobrevivan a un fallo de almacenamiento o a la pérdida del clúster, traslade los datos a un almacenamiento independiente mediante la herramienta de transferencia de datos de Velero, la API VirtualMachineExport de CDI o un motor de replicación que transmita los bloques modificados a otro clúster o nube.
Virtualización con KubeVirt frente a OpenShift: ¿cuál es la diferencia?
KubeVirt es el proyecto de código abierto upstream que agrega administración de máquinas virtuales a Kubernetes a través de recursos personalizados; OpenShift Virtualization es la distribución de KubeVirt con soporte comercial de Red Hat, empaquetada como un operador en OpenShift. KubeVirt se inició en Red Hat en 2017, se unió a la CNCF como un proyecto sandbox en septiembre de 2019, se trasladó a la Nivel de madurez de incubación en abril de 2022 y completó su primera auditoría de seguridad externa en 2025 como parte de su solicitud de graduación.
A efectos de copia de seguridad, ambos comparten las mismas API: Máquina virtual, Instantánea de máquina virtual, Volumen de datos La integración de CSI VolumeSnapshot se comporta de forma idéntica. Las diferencias radican en la configuración predeterminada y el soporte. OpenShift Virtualization incluye plantillas de máquinas virtuales con el agente invitado QEMU preinstalado, habilita la función Snapshot, incluye el kit de herramientas de migración para virtualización para trasladar máquinas virtuales desde vSphere y proporciona OADP (OpenShift API for Data Protection), una distribución Velero compatible con un complemento para KubeVirt. En KubeVirt o en distribuciones que lo integran, como SUSE Harvester, se ensamblan los mismos componentes manualmente. Todo lo que se describe a continuación se aplica a ambas.
Hystax Acura replica sus cargas de trabajo de VMware, KVM y nube pública en KubeVirt en segundo plano y las sigue protegiendo después de la migración con recuperación ante desastres y copias de seguridad automatizadas. Deje su correo electrónico empresarial y un experto de Hystax le guiará a través de una demostración personalizada en su propia infraestructura.
¡Gracias por tu solicitud!
Nos pondremos en contacto contigo pronto.
Comparación de los métodos de copia de seguridad de KubeVirt
La mayoría de las implementaciones se pueden realizar mediante cuatro enfoques. La tabla los compara según los criterios que determinan si una restauración funciona correctamente.
Figura 4. Cuatro métodos de copia de seguridad de KubeVirt evaluados en función de la consistencia, la copia fuera del clúster, el conocimiento de la aplicación y el RTO típico.
| Método | Consistencia | Copia fuera del clúster | Conocimiento de máquinas virtuales/aplicaciones | RTO típico | Lo mejor para |
|---|---|---|---|---|---|
| Instantánea de máquina virtual nativa (CSI VolumeSnapshot) | Aplicación coherente con el agente invitado; de lo contrario, coherente con el fallo. | No, la instantánea permanece en el mismo almacenamiento. | Solo congelación/descongelación; captura la especificación de la máquina virtual + PVC. | Minutos para la reversión in situ | Puntos de control antes de aplicar parches o actualizaciones. |
| Velero + CSI (OADP en OpenShift) | Igual que de forma nativa a través de los ganchos del complemento KubeVirt. | Sí, Data Move copia datos a almacenamiento de objetos compatible con S3. | Congelación/descongelación más ganchos pre/post; espacios de nombres completos | De decenas de minutos a horas; los datos se recuperan del almacenamiento de objetos. | Copia de seguridad programada de máquinas virtuales y sus dependencias de Kubernetes. |
| Instantáneas/replicación de matrices de almacenamiento | Consistente en caso de fallo a menos que esté integrado con el agente invitado. | Sí, si la matriz se replica en un segundo sitio. | Ninguno; los objetos de la máquina virtual se restauraron por separado. | Minutos para la recuperación de datos, más la recuperación manual de objetos de la máquina virtual. | Grandes propiedades estandarizadas con un único proveedor de almacenamiento. |
| Plataforma dedicada de respaldo y recuperación ante desastres (por ejemplo, Hystax Acura) | Puntos de restauración orquestados por agentes y consistentes con la aplicación | Sí, replicación incremental a nivel de bloque en cualquier nube, clúster o almacenamiento de objetos. | Compatible con máquinas virtuales y aplicaciones; planes de recuperación ante desastres, orden de arranque, prueba de conmutación por error, recuperación ante fallos | Minutos, conmutación por error a una réplica preconfigurada | Recuperación ante desastres en la nube cruzada, proveedores de servicios gestionados (MSP), entornos mixtos de VMware y KubeVirt. |
Como regla general: utilice instantáneas nativas para puntos de control de corta duración, Velero u OADP para copias de seguridad programadas que deban salir del clúster, y una plataforma dedicada cuando el requisito se exprese en minutos de RPO y RTO, o cuando una herramienta deba proteger las cargas de trabajo que aún se encuentran en VMware junto con las que ya están en KubeVirt.
Recuperación ante desastres para KubeVirt: RPO, RTO y conmutación por error
El objetivo de punto de recuperación (RPO) es la pérdida máxima de datos medida en tiempo; el objetivo de tiempo de recuperación (RTO) es el tiempo transcurrido entre el incidente y la restauración del servicio. La copia de seguridad proporciona puntos de restauración; la recuperación ante desastres proporciona una copia ejecutable de la infraestructura en otro lugar, además de la automatización para ponerla en marcha en orden. KubeVirt tiene tres escenarios con diferentes perfiles de RPO/RTO:
- Restauración de instantáneas del mismo clúster. Protege contra cambios defectuosos, actualizaciones fallidas o ransomware dentro del sistema invitado, pero no contra la pérdida del almacenamiento o del clúster.
- Restauración entre clústeres desde el almacenamiento de objetos. Velero u OADP restaura las máquinas virtuales en un nuevo clúster desde S3. Sobrevive a la pérdida del clúster, pero el RTO se extiende a horas para entornos de escala de terabytes porque cada disco se rehidrata antes de que la máquina virtual pueda arrancar.
- Replicación continua a una plataforma de respaldo. Los bloques modificados se replican en segundo plano en un segundo clúster de KubeVirt u OpenShift Virtualization, en OpenStack o en una nube pública, y los planes de recuperación ante desastres inician las máquinas virtuales en orden de dependencia. El RPO se reduce a minutos y el RTO al tiempo que tarda en arrancar las réplicas.
Hystax Acura para KubeVirt Implementa el tercer escenario. Replica las máquinas virtuales de KubeVirt en segundo plano con puntos de restauración incrementales a nivel de bloque que están deduplicados y optimizados para WAN, los mantiene en almacenamiento de bloques para DR o en almacenamiento de objetos para copias de seguridad a largo plazo, genera planes de DR automáticamente a partir de la infraestructura replicada y ejecuta conmutaciones por error de prueba no disruptivas bajo demanda. La recuperación por error devuelve los cambios realizados en el sitio de DR a producción sin pérdida de datos. El mismo motor realiza la migración en vivo a la nube desde VMware, KVM y nubes públicas a KubeVirt o Virtualización de Red Hat OpenShift, De esta forma, la migración y la protección se convierten en un único flujo de trabajo, lo que permite cerrar la brecha que se produce cuando la cobertura se interrumpe al salir de VMware.
Es necesario aclarar un término. La migración en vivo de KubeVirt mueve una máquina virtual en ejecución entre nodos del mismo clúster para su mantenimiento; es una función de disponibilidad, no de protección de datos, y no crea ningún punto de restauración. Migración en vivo a KubeVirt La solución que ofrece Hystax es diferente: replicar una carga de trabajo de otra plataforma y transferirla en una ventana de mantenimiento que dura, en promedio, de uno a tres minutos.
Cómo realizar una copia de seguridad de una máquina virtual KubeVirt: paso a paso
Este procedimiento genera una copia de seguridad fuera del clúster que mantiene la coherencia de la aplicación y demuestra que se puede restaurar. Es aplicable tanto a KubeVirt como a OpenShift Virtualization.
Figura 5. Seis pasos para realizar una copia de seguridad de una máquina virtual KubeVirt fuera del clúster, manteniendo la coherencia de la aplicación.
- Instale el controlador de instantáneas y los CRD. Kubernetes upstream necesita los componentes external-snapshotter; OpenShift los incluye. Verificar con kubectl get crd volumesnapshotclasses.snapshot.storage.k8s.io.
- Configure una VolumeSnapshotClass. Crea uno para tu controlador CSI y configúralo política de eliminación: conservar Para la clase utilizada por las copias de seguridad. Confirme que la StorageClass de la máquina virtual admite instantáneas; en OpenShift, el objeto StorageProfile muestra esta capacidad.
- Instale el agente invitado de QEMU en cada máquina virtual. Utilice el paquete de distribución en Linux y las herramientas de invitado virtio-win en Windows, luego confirme la Agente conectado condición en el estado de la máquina virtual. Sin ella, solo se obtienen copias consistentes en caso de fallo.
- Toma la instantánea. Aplicar un Instantánea de máquina virtual haciendo referencia a la VM, opcionalmente con un Fecha límite de fracaso. Lea las indicaciones de estado: desea En línea con participación de agente invitado, no NoGuestAgent ni QuiesceFailed.
- Exportar los datos fuera del clúster. Ejecute una copia de seguridad de Velero u OADP de todo el espacio de nombres con los complementos CSI y KubeVirt y snapshotMoveData: verdadero, orientado al almacenamiento de objetos externo, de modo que las máquinas virtuales, los DataVolumes, los PVC, los Secrets y las definiciones de red se transfieren juntos. O bien, que un motor de replicación envíe los bloques modificados a un sitio de recuperación ante desastres.
- Prueba la restauración. Restaura en un espacio de nombres independiente mediante la asignación de espacios de nombres, inicia la máquina virtual, verifica la aplicación y mide el RTO real. Repite el proceso según un cronograma; una copia de seguridad que nunca se ha restaurado es una suposición, no un plan.
Resumen
KubeVirt y OpenShift Virtualization ejecutan máquinas virtuales como pods de Kubernetes, por lo que una copia de seguridad de KubeVirt protege dos capas a la vez: los objetos de Kubernetes de la máquina virtual y sus datos de PVC, capturados mediante CSI VolumeSnapshots con congelación/descongelación del agente invitado QEMU para la coherencia de la aplicación. Una instantánea por sí sola permanece en el mismo almacenamiento y no es una copia de seguridad; la copia debe salir del clúster mediante Velero/OADP o replicación a nivel de bloque, y la recuperación ante desastres con RPO y RTO bajos requiere replicación continua a una plataforma de reserva con conmutación por error probada. Para los equipos que abandonan VMware, esto supone un rediseño de la protección de datos en lugar de un simple cambio de herramienta, y Hystax Acura cubre tanto la migración a KubeVirt como la recuperación ante desastres y las copias de seguridad posteriores.
Hable con un ingeniero de Hystax sobre sus objetivos de RPO y RTO, la configuración del almacenamiento y el escenario de recuperación ante desastres entre nubes. Le mostraremos cómo Hystax Acura prueba la conmutación por error sin afectar la producción y cómo sería un plan de recuperación realista para su entorno de virtualización OpenShift.
¡Gracias por tu solicitud!
Nos pondremos en contacto contigo pronto.
Preguntas frecuentes
¿Puedo usar Veeam o mi herramienta de copia de seguridad vSphere existente para KubeVirt?
En su configuración de vSphere, los trabajos basados en VADP y acceso a VMDK no tienen equivalente en KubeVirt. Varios proveedores han añadido compatibilidad con KubeVirt mediante la API de instantáneas de CSI, así que verifique primero tres cosas: que la herramienta realice copias de seguridad del recurso VirtualMachine y DataVolumes, no solo de PVC; que active la congelación/descongelación a través del agente invitado de QEMU; y que sea compatible con su controlador CSI. Considere la migración como un nuevo diseño de copia de seguridad, no como un trabajo redirigido.
¿Es suficiente una instantánea CSI para realizar una copia de seguridad de una máquina virtual KubeVirt?
No. Una instantánea de volumen (VolumeSnapshot) es un punto de restauración en el mismo almacenamiento que el volumen de origen y solo cubre los datos de PVC. Una copia de seguridad también requiere la especificación de la máquina virtual y los objetos relacionados, además de una copia en un almacenamiento independiente. Utilice instantáneas para una reversión rápida y combínelas con Velero, OADP o una plataforma de replicación para una protección real.
¿Cuál es la diferencia entre la copia de seguridad de KubeVirt consistente ante fallos y la consistente a nivel de aplicación?
Una copia de seguridad con coherencia ante fallos restaura el disco a su estado tras un apagado repentino; es posible que el sistema invitado necesite recuperar el sistema de archivos y la base de datos al arrancar. Una copia de seguridad con coherencia de la aplicación congela primero los sistemas de archivos del sistema invitado y vacía los búferes mediante el agente invitado de QEMU, lo que permite una restauración limpia. KubeVirt realiza este proceso automáticamente cuando el agente está conectado y recurre a la coherencia ante fallos cuando no lo está.
¿Cómo configuro la recuperación ante desastres para KubeVirt con un RPO y un RTO bajos?
Realice copias de seguridad continuas en lugar de nocturnas, manténgalas en una plataforma que pueda iniciarlas inmediatamente y defina planes de recuperación ante desastres que inicien las máquinas virtuales en orden de dependencia con las redes adecuadas. Pruebe la conmutación por error periódicamente sin afectar la producción. Hystax Acura implementa este modelo para KubeVirt y OpenShift Virtualization, con RPO y RTO en minutos y una ruta de recuperación a producción.
¿Cómo puedo adaptar mi estrategia de copias de seguridad de vSphere a la virtualización de OpenShift?
Mapea los componentes, no los productos: VADP se convierte en la API CSI VolumeSnapshot; la inactividad de VMware Tools se convierte en la congelación/descongelación del agente invitado de QEMU; los proxies de copia de seguridad se convierten en agentes de nodo Velero o agentes de replicación; Site Recovery Manager se convierte en planes de recuperación ante desastres; la retención de almacenes de datos se convierte en VolumeSnapshotClass y políticas de ciclo de vida de almacenamiento de objetos. Mantén tus objetivos RPO y RTO existentes como criterios de aceptación.
¿Puedo realizar copias de seguridad o replicar máquinas virtuales de KubeVirt en una nube diferente o en otro clúster de KubeVirt?
Sí. Velero y OADP restauran desde el almacenamiento de objetos a cualquier clúster con almacenamiento compatible, y las plataformas de replicación como Hystax Acura admiten escenarios de cualquier a cualquier: de KubeVirt a otro clúster de KubeVirt, a OpenStack o a AWS, Azure y Google Cloud, y viceversa.