Índice
- Por que a saída do VMware alterou o backup da VM?
- Como funciona o backup do KubeVirt: snapshots CSI e congelamento/descongelamento
- Virtualização KubeVirt vs OpenShift: qual a diferença?
- Comparação de métodos de backup do KubeVirt
- Recuperação de desastres para KubeVirt: RPO, RTO e failover
- Como fazer backup de uma VM do KubeVirt: passo a passo
- Resumo
Fazer backup de VMs do KubeVirt significa proteger máquinas virtuais que agora são executadas como pods do Kubernetes, usando snapshots CSI das reivindicações de volume persistentes da VM, além de congelamento/descongelamento consistente com o aplicativo por meio do agente convidado QEMU, e não o backup legado de imagem de VM. A definição da VM, seus DataVolumes e PVCs, e os dados dentro deles são todos objetos do Kubernetes. Um backup do KubeVirt é, portanto, um backup do Kubernetes com reconhecimento de virtualização adicionado.
O momento torna isso urgente. As mudanças no licenciamento da Broadcom levaram milhares de equipes a planejar a migração do VMware, e o Red Hat OpenShift Virtualization, baseado no KubeVirt, é um dos destinos mais comuns. Essas equipes chegam com ferramentas de backup da era vSphere que pressupõem uma API de hipervisor, vCenter e arquivos VMDK, nenhum dos quais existe dentro de uma VM do Kubernetes. Este artigo explica o que mudou, como funciona o backup do KubeVirt, qual método se adequa a cada cenário e como estender o backup para a recuperação de desastres.
Por que a saída do VMware alterou o backup da VM?
A dimensão dessa mudança é mensurável. A analista da Gartner, Julia Palmer, prevê que 35% das cargas de trabalho da VMware migrarão para outras plataformas até 2028., E uma pesquisa citada pela InformationWeek revelou que apenas 71% das organizações de TI planejam permanecer totalmente na VMware. O prazo também é limitado: o suporte geral para o vSphere 8 termina em outubro de 2027. Do lado dos usuários finais, a Red Hat informou que... O número de máquinas virtuais em execução no OpenShift Virtualization cresceu 417% em 2025., os clusters que executam máquinas virtuais cresceram 93%, e a Red Hat Services avaliou mais de 1,46 milhão de máquinas virtuais em projetos de migração.
Figura 1. A saída do VMware em números: Previsão de migração do Gartner de 35%, 7% permanecendo totalmente no VMware (pesquisa citada pela InformationWeek), fim do suporte ao vSphere 8 em outubro de 2027, +417% VMs na virtualização OpenShift (Red Hat, 2026)
O que se desfaz após a migração é o próprio modelo de backup. No vSphere, o software de backup se comunica com o hipervisor por meio do VADP (vSphere APIs for Data Protection), rastreia os blocos alterados e lê arquivos VMDK do datastore. No KubeVirt, não há vCenter, VADP ou VMDK. Uma máquina virtual é um recurso personalizado do tipo VirtualMachine. Seus discos são PVCs (Persistent Volume Claims), normalmente provisionados a partir de DataVolumes pelo KubeVirt CDI (Containerized Data Importer), que importa uma imagem qcow2 ou raw para um volume. A instância em execução é um pod virt-launcher agendado como qualquer outra carga de trabalho.
Uma ferramenta que entende apenas armazenamento pode copiar bytes de PVC, mas perde a especificação da VM, as definições de conexão de rede, os segredos do cloud-init e os relacionamentos entre eles, de modo que a restauração se torna uma reconstrução manual sob pressão. Há também um risco mais silencioso: durante a replataformação, a cobertura de backup geralmente expira sem deixar rastros, porque o antigo agente vSphere desaparece e nada equivalente foi configurado no Kubernetes.
Como funciona o backup do KubeVirt: snapshots CSI e congelamento/descongelamento
Uma VM do KubeVirt é um pod com um ou mais PVCs anexados como discos, portanto, um backup possui duas camadas: os objetos do Kubernetes (VirtualMachine, DataVolume, PVC, Secrets, Services, NetworkAttachmentDefinitions) e os dados em bloco dentro dos PVCs. A camada de objetos é YAML simples; a camada de dados é protegida pela API VolumeSnapshot do Kubernetes, implementada pelo driver CSI do seu fornecedor de armazenamento.
Figura 2. Como funciona o backup do KubeVirt: congelamento/descongelamento do agente convidado, CSI VolumeSnapshot por PVC, pacote VirtualMachineSnapshot e a cópia fora do cluster que transforma um ponto de restauração em um backup.
Ao criar um VirtualMachineSnapshot, o objeto de snapshot de máquina virtual do KubeVirt, o controlador cria um VolumeSnapshot para cada volume com suporte a CSI anexado à VM e armazena uma cópia da especificação e dos metadados da VM junto com ele. Os pré-requisitos são uma StorageClass cujo driver CSI suporte snapshots, uma VolumeSnapshotClass para esse driver e o recurso Snapshot, que o OpenShift Virtualization habilita por padrão. De acordo com o Documentação de snapshots do KubeVirt, Quando a máquina virtual está em execução, o controlador verifica se o agente convidado QEMU está conectado. Se estiver, o KubeVirt congela os sistemas de arquivos do convidado, cria um snapshot e os descongela posteriormente. Os snapshots online têm um prazo limite padrão de falha de cinco minutos.
O congelamento/descongelamento é o que diferencia os dois níveis de consistência que todo administrador de backup deve ser capaz de definir:
- Backup consistente em caso de falha Captura o disco exatamente como ele ficaria após uma queda repentina de energia. O sistema de arquivos e os aplicativos podem precisar de recuperação na inicialização, e as gravações em andamento no banco de dados podem ser perdidas.
- Backup consistente com o aplicativo O sistema pausa as gravações e limpa os buffers antes da captura do snapshot, utilizando o congelamento/descongelamento por meio do agente convidado e, quando necessário, scripts pré e pós-snapshot que colocam os bancos de dados em estado quiescente. O resultado é uma restauração limpa, sem necessidade de reprodução do journal ou recuperação do banco de dados.
Figura 3. Backup do KubeVirt consistente com falhas versus backup consistente com a aplicação
O KubeVirt registra o nível obtido: sem um agente conectado, o snapshot é marcado como best-effort (consistente em caso de falha), e um congelamento com falha é sinalizado com a indicação QuiesceFailed. Para bancos de dados, brokers de mensagens e workloads do Windows, considere a condição AgentConnected da VM como um pré-requisito de backup.
Uma regra permanece inalterada em relação ao VMware: um snapshot não é um backup. Os VolumeSnapshots residem no mesmo armazenamento que o PVC de origem. Para sobreviver a uma falha de armazenamento ou perda de cluster, mova os dados para um armazenamento independente por meio do gerenciador de dados do Velero, da API VirtualMachineExport do CDI ou de um mecanismo de replicação que transmita os blocos alterados para outro cluster ou nuvem.
Virtualização KubeVirt vs OpenShift: qual a diferença?
KubeVirt é o projeto de código aberto upstream que adiciona gerenciamento de máquinas virtuais ao Kubernetes por meio de recursos personalizados; o OpenShift Virtualization é a distribuição comercialmente suportada do KubeVirt pela Red Hat, empacotada como um operador no OpenShift. O KubeVirt foi iniciado na Red Hat em 2017, ingressou na CNCF como um projeto sandbox em setembro de 2019 e migrou para o OpenShift Virtualization. nível de maturidade de incubação em abril de 2022 e concluiu sua primeira auditoria de segurança de terceiros em 2025 como parte de seu processo de graduação.
Para fins de backup, os dois compartilham as mesmas APIs: Máquina Virtual, Instantâneo da Máquina Virtual, Volume de dados A integração do CSI VolumeSnapshot e do OpenShift Virtualization se comportam de maneira idêntica. As diferenças estão nas configurações padrão e no suporte. O OpenShift Virtualization fornece modelos de VM com o agente convidado QEMU pré-instalado, habilita o recurso Snapshot, inclui o Migration Toolkit for Virtualization para migrar VMs do vSphere e oferece o OADP (OpenShift API for Data Protection), uma distribuição Velero compatível com um plugin para KubeVirt. No KubeVirt original ou em distribuições que o incorporam, como o SUSE Harvester, você monta os mesmos componentes por conta própria. Tudo o que segue abaixo se aplica a ambos.
O Hystax Acura replica suas cargas de trabalho VMware, KVM e de nuvem pública para o KubeVirt em segundo plano e continua protegendo-as após a migração com recuperação de desastres e backup automatizados. Deixe seu e-mail comercial e um especialista da Hystax apresentará uma demonstração personalizada em sua infraestrutura.
Obrigado pelo seu pedido!
Entraremos em contato em breve.
Comparação de métodos de backup do KubeVirt
Quatro abordagens abrangem a maioria das implementações. A tabela compara-as com base nos critérios que determinam se uma restauração realmente funciona.
Figura 4. Quatro métodos de backup do KubeVirt avaliados quanto à consistência, cópia fora do cluster, reconhecimento de aplicativos e RTO típico.
| Método | Consistência | Cópia fora do cluster | Consciência de VM/aplicativo | RTO típico | Ideal para |
|---|---|---|---|---|---|
| Captura instantânea nativa da VM (CSI VolumeSnapshot) | Consistente com o agente convidado; caso contrário, consistente com a falha. | Não, o snapshot permanece no mesmo armazenamento. | Somente congelamento/descongelamento; captura especificações VM + PVCs | Minutos para reversão no local | Pontos de verificação antes de aplicar patches ou atualizações |
| Velero + CSI (OADP no OpenShift) | Igual à versão nativa via hooks do plugin KubeVirt. | Sim, o Data Mover copia para armazenamento de objetos compatível com S3. | Congelamento/descongelamento mais ganchos pré/pós; espaços de nomes completos | Dezenas de minutos a horas; os dados são reidratados a partir do armazenamento de objetos. | Backup agendado de VMs e suas dependências do Kubernetes |
| Instantâneos/replicação de arrays de armazenamento | Consistente em caso de falha, a menos que integrado ao agente convidado. | Sim, se a matriz for replicada para um segundo site. | Nenhum; objetos VM restaurados separadamente | Minutos para dados, mais recuperação manual de objetos de VM | Grandes propriedades padronizadas em um único fornecedor de armazenamento |
| Plataforma dedicada de backup e recuperação de desastres (ex: Hystax Acura) | Pontos de restauração consistentes com a aplicação e orquestrados pelo agente | Sim, replicação incremental em nível de bloco para qualquer nuvem, cluster ou armazenamento de objetos. | Compatível com máquinas virtuais e aplicativos; planos de recuperação de desastres, ordem de inicialização, teste de failover, failback. | Em minutos, passe para uma réplica pré-configurada. | Recuperação de desastres em várias nuvens, MSPs, ambientes mistos de VMware e KubeVirt |
Regra geral: use snapshots nativos para pontos de verificação de curta duração, Velero ou OADP para backups agendados que precisam sair do cluster e uma plataforma dedicada quando o requisito for expresso em minutos de RPO e RTO, ou quando uma ferramenta precisar proteger cargas de trabalho ainda no VMware juntamente com aquelas já presentes no KubeVirt.
Recuperação de desastres para KubeVirt: RPO, RTO e failover
O objetivo de ponto de recuperação (RPO) é a perda máxima de dados medida em termos de tempo; o objetivo de tempo de recuperação (RTO) é o tempo entre o incidente e a restauração do serviço. O backup fornece pontos de restauração; a recuperação de desastres fornece uma cópia executável da infraestrutura em outro local, além da automação para colocá-la em funcionamento normalmente. O KubeVirt possui três cenários com diferentes perfis de RPO/RTO:
- Restauração de snapshot no mesmo cluster. Protege contra alterações maliciosas, falhas em atualizações ou ransomware dentro da máquina virtual, não contra a perda de armazenamento ou do cluster.
- Restauração entre clusters a partir do armazenamento de objetos. O Velero ou OADP restaura VMs em um novo cluster a partir do S3. Ele sobrevive à perda do cluster, mas o RTO (tempo de recuperação) chega a horas em ambientes de escala de terabytes, porque todos os discos são reidratados antes que a VM possa inicializar.
- Replicação contínua para uma plataforma de espera. Os blocos alterados são replicados em segundo plano para um segundo cluster de virtualização KubeVirt ou OpenShift, para o OpenStack ou para uma nuvem pública, e os planos de recuperação de desastres iniciam as VMs na ordem de dependência. O RPO cai para minutos e o RTO para o tempo necessário para inicializar as réplicas.
Hystax Acura para KubeVirt Implementa o terceiro cenário. Replica VMs do KubeVirt em segundo plano com pontos de restauração incrementais em nível de bloco, deduplicados e otimizados para WAN, mantendo-os em armazenamento de blocos para recuperação de desastres ou em armazenamento de objetos para backup de longo prazo, gera planos de recuperação de desastres automaticamente a partir da infraestrutura replicada e executa testes de failover não disruptivos sob demanda. O failback retorna as alterações feitas no site de recuperação de desastres para a produção sem perda de dados. O mesmo mecanismo realiza migração ao vivo da nuvem a partir de VMware, KVM e nuvens públicas para o KubeVirt ou Virtualização Red Hat OpenShift, Assim, a migração e a proteção tornam-se um único fluxo de trabalho, eliminando a lacuna de cobertura que ocorre durante a saída do VMware.
Um termo precisa ser esclarecido. A migração dinâmica do KubeVirt move uma máquina virtual em execução entre nós do mesmo cluster para fins de manutenção; trata-se de um recurso de disponibilidade, não de proteção de dados, e não cria um ponto de restauração. migração ao vivo para KubeVirt O que a Hystax oferece é uma operação diferente: replicar uma carga de trabalho de outra plataforma e transferi-la durante uma janela de manutenção que dura em média de um a três minutos.
Como fazer backup de uma VM do KubeVirt: passo a passo
Este procedimento gera um backup fora do cluster, consistente com a aplicação, e comprova que sua restauração é bem-sucedida. Ele se aplica tanto ao KubeVirt quanto ao OpenShift Virtualization.
Figura 5. Seis etapas para um backup de VM KubeVirt fora do cluster e consistente com a aplicação.
- Instale o controlador de snapshots e os CRDs. O Kubernetes upstream precisa dos componentes external-snapshotter; o OpenShift os inclui. Verifique com kubectl get crd volumesnapshotclasses.snapshot.storage.k8s.io.
- Configure uma classe VolumeSnapshotClass. Crie um para o seu driver CSI e configure-o. Política de exclusão: Reter Para a classe usada pelos backups. Confirme se a StorageClass da VM suporta snapshots; no OpenShift, o objeto StorageProfile mostra essa capacidade.
- Instale o agente convidado QEMU em todas as máquinas virtuais. Utilize o pacote de distribuição no Linux e as ferramentas de convidado virtio-win no Windows e, em seguida, confirme a instalação. AgenteConectado condição no estado da VM. Sem ela, você só obtém cópias consistentes em caso de falha.
- Tire uma foto. Aplique um Instantâneo da Máquina Virtual referenciando a VM, opcionalmente com um prazo de falha. Leia as indicações de status: você deseja "Online com participação de agente convidado", não "Sem agente convidado" ou "Falha na quiescência".
- Exporte os dados para fora do cluster. Execute um backup Velero ou OADP de todo o namespace com os plugins CSI e KubeVirt e snapshotMoveData: true, direcionando para armazenamento de objetos externo, de forma que VMs, DataVolumes, PVCs, Secrets e definições de rede sejam transferidos juntos. Ou permita que um mecanismo de replicação transmita os blocos alterados para um site de recuperação de desastres.
- Teste a restauração. Restaure em um namespace separado por meio de mapeamento de namespace, inicialize a VM, verifique o aplicativo e meça o RTO real. Repita o processo periodicamente; um backup que nunca foi restaurado é uma suposição, não um plano.
Resumo
O KubeVirt e o OpenShift Virtualization executam máquinas virtuais como pods do Kubernetes, portanto, um backup do KubeVirt protege duas camadas simultaneamente: os objetos Kubernetes da VM e seus dados PVC, capturados por meio de CSI VolumeSnapshots com congelamento/descongelamento do agente convidado QEMU para garantir a consistência da aplicação. Um snapshot isolado permanece no mesmo armazenamento e não é um backup; a cópia precisa sair do cluster por meio de Velero/OADP ou replicação em nível de bloco, e a recuperação de desastres com RPO e RTO baixos exige replicação contínua para uma plataforma de espera com failover testado. Para equipes que estão migrando do VMware, isso representa uma reformulação da proteção de dados, e não apenas uma troca de ferramentas, e o Hystax Acura abrange tanto a migração para o KubeVirt quanto a recuperação de desastres e o backup subsequentes.
Fale com um engenheiro da Hystax sobre suas metas de RPO e RTO, layout de armazenamento e cenário de recuperação de desastres entre nuvens. Mostraremos como o Hystax Acura testa o failover sem afetar a produção e como seria um plano de recuperação realista para seu ambiente de virtualização OpenShift.
Obrigado pelo seu pedido!
Entraremos em contato em breve.
Perguntas frequentes
Posso usar o Veeam ou minha ferramenta de backup do vSphere existente para o KubeVirt?
Não na configuração do vSphere: tarefas baseadas em VADP e acesso a VMDK não têm equivalente no KubeVirt. Vários fornecedores adicionaram suporte ao KubeVirt por meio da API de snapshots CSI, portanto, verifique três coisas primeiro: se a ferramenta faz backup do recurso VirtualMachine e dos DataVolumes, não apenas dos PVCs; se ela aciona o congelamento/descongelamento por meio do agente convidado QEMU; e se ela é compatível com seu driver CSI. Trate a migração como um novo projeto de backup, não como uma tarefa redirecionada.
Um snapshot CSI é suficiente para fazer backup de uma VM do KubeVirt?
Não. Um VolumeSnapshot é um ponto de restauração no mesmo armazenamento que o volume de origem e abrange apenas os dados do PVC. Um backup também precisa da especificação da VM e dos objetos relacionados, além de uma cópia em um armazenamento independente. Use snapshots para reversão rápida e combine-os com Velero, OADP ou uma plataforma de replicação para proteção completa.
Qual a diferença entre um backup do KubeVirt consistente em caso de falha e um backup consistente com a aplicação?
Um backup consistente com falhas preserva o disco como ele estaria após um desligamento abrupto; o sistema operacional convidado pode precisar de recuperação do sistema de arquivos e do banco de dados na inicialização. Um backup consistente com a aplicação congela os sistemas de arquivos do sistema operacional convidado e limpa os buffers primeiro, por meio do agente convidado QEMU, para que a restauração seja feita sem problemas. O KubeVirt faz isso automaticamente quando o agente está conectado e recorre ao backup consistente com falhas quando não está.
Como configurar a recuperação de desastres para o KubeVirt com RPO e RTO baixos?
Em vez de fazer backups noturnos, replique continuamente, mantenha as réplicas em uma plataforma que possa inicializá-las imediatamente e defina planos de recuperação de desastres que iniciem as VMs na ordem de dependência, com as redes corretas. Teste o failover regularmente sem afetar a produção. O Hystax Acura implementa esse modelo para virtualização KubeVirt e OpenShift, com RPO e RTO em minutos e um caminho de failback para a produção.
Como faço para adaptar minha estratégia de backup do vSphere para a virtualização do OpenShift?
Mapeie os componentes, não os produtos: o VADP torna-se a API CSI VolumeSnapshot; o processo de quiescência do VMware Tools torna-se o congelamento/descongelamento do agente convidado do QEMU; os proxies de backup tornam-se agentes de nó ou agentes de replicação do Velero; o Site Recovery Manager torna-se planos de recuperação de desastres; a retenção do armazenamento de dados torna-se a classe VolumeSnapshotClass e as políticas de ciclo de vida do armazenamento de objetos. Mantenha suas metas de RPO e RTO existentes como critérios de aceitação.
Posso fazer backup ou replicar VMs do KubeVirt para uma nuvem diferente ou para outro cluster KubeVirt?
Sim. O Velero e o OADP restauram dados do armazenamento de objetos para qualquer cluster com armazenamento compatível, e plataformas de replicação como o Hystax Acura suportam cenários de qualquer tipo: KubeVirt para outro cluster KubeVirt, para OpenStack ou para AWS, Azure e Google Cloud, e vice-versa.