Home > Blog de Apoio e Recuperação > Por que fazer backup de VMs QEMU: Métodos, configuração e práticas recomendadas
Atualizado 21st abril 2025, Rob Morrison

Por que fazer backup de VMs QEMU?

As máquinas virtuais são a espinha dorsal de quase todas as infraestruturas de TI modernas, e as VMs baseadas em QEMU são uma escolha popular em ambientes virtuais. A criação de backups adequados desses ambientes virtuais não é apenas uma recomendação, mas, normalmente, uma parte obrigatória de qualquer plano adequado de continuidade dos negócios e recuperação de desastres. Os backups mantidos adequadamente tornam-se a rede de segurança de uma empresa quando o hardware falha (e não existe hardware infalível).

Os ambientes virtuais têm vantagens exclusivas sobre o hardware físico na criação de backups eficientes e consistentes. Quanto ao QEMU em si, ele é um emulador gratuito e de código aberto que usa tradução binária dinâmica para emular o processador de um computador. O QEMU pode emular uma variedade de arquiteturas de computador, operar sistemas operacionais convidados e até mesmo suportar muitas opções de hardware diferentes. Além disso, o QEMU opera facilmente como um back-end de emulação de dispositivo ou hipervisor para VMs, o que o torna muito atraente para uma ampla gama de usuários.

As VMs QEMU incorporam sistemas operacionais personalizados, dados críticos de aplicativos e configurações valiosas. Perder um ambiente como esse normalmente significa perder horas ou dias de trabalho de instalação e configuração, além de poder interromper as operações comerciais, as operações de atendimento ao cliente e, possivelmente, resultados ainda piores. Por isso, essas informações devem ser protegidas, e os backups costumam ser vistos como uma das maneiras mais confiáveis e versáteis de fazer isso.

A maioria das estruturas de conformidade regulamentar agora exige backups, inclusive estruturas de retenção específicas. Acrescente isso ao fato de que os backups também podem proteger as informações contra ataques de ransomware, e é fácil ver por que esse tópico é tão importante.

O investimento em estratégias adequadas de backup de VMs rende dividendos de várias maneiras: redução do tempo de inatividade, melhoria da continuidade dos negócios e a tranquilidade geral que advém do fato de saber que seus dados podem ser recuperados após praticamente qualquer desastre possível. A arquitetura aberta do QEMU também torna as estratégias de backup mais flexíveis, possibilitando o uso de abordagens simples baseadas em arquivos e soluções incrementais complexas. Este artigo explora os backups do QEMU, analisando diferentes métodos, processos de configuração e possíveis práticas recomendadas.

Métodos de backup para o QEMU

Há vários tipos diferentes de backup que podem ser usados para proteger as máquinas virtuais QEMU, sendo que cada abordagem tem suas próprias vantagens e desvantagens. A solução de backup e recuperação mais eficaz para qualquer situação específica dependerá dos requisitos de desempenho e segurança da empresa, das políticas, das restrições de armazenamento, entre outros fatores, o que torna irreal identificar uma solução de backup que seja melhor em todas as situações.

A seguir, o artigo explora as principais estratégias de backup que se mostraram eficazes em ambientes QEMU.

Backup completo

Os backups completos devem capturar todas as informações em um local específico de uma só vez, o disco virtual inteiro com todos os seus arquivos de configuração e outras informações da VM associadas a ele. Em outras palavras, um backup completo cria uma réplica completa e independente de uma VM, tornando-a facilmente restaurável sem a necessidade de qualquer outro conjunto de backup.

A combinação de simplicidade e velocidade de recuperação é, sem dúvida, a maior vantagem dos backups completos. Um backup completo elimina a necessidade de reunir vários componentes de backup para restaurar informações quando ocorre um desastre: basta restaurar o backup completo e continuar suas tarefas de negócios. É um método particularmente útil para proteger as VMs mais importantes do ambiente, em que o custo do tempo de inatividade é significativamente maior do que o custo do armazenamento.

Dito isso, os backups completos exigem uma quantidade significativa de espaço de armazenamento e largura de banda de rede para serem realizados. Há também o risco de que as informações sejam duplicadas várias vezes, devido à falta de granularidade dos backups completos, o que os torna ainda menos eficientes em termos de armazenamento. Dessa forma, ambientes com capacidade de armazenamento limitada considerariam os backups completos impraticáveis como a única estratégia, e o mesmo poderia ser dito para VMs geralmente grandes.

Backup incremental

Os backups incrementais podem ser considerados como o “meio termo” da metodologia de backup. Depois que um backup completo é concluído, todos os backups incrementais posteriores capturam apenas as informações que foram alteradas desde a ocorrência do último backup (de qualquer tipo). Dessa forma, os backups se tornam significativamente mais eficientes em termos de armazenamento e exponencialmente mais rápidos do que os backups completos.

A abordagem de backup incremental do QEMU usa o “rastreamento de sujeira do dispositivo de bloco” por meio de bitmaps para monitorar quais blocos foram alterados desde o último backup. Esse mecanismo ajuda a minimizar o impacto do backup no desempenho do sistema e, ao mesmo tempo, cria uma cadeia de arquivos de backup gerenciáveis que representam o estado completo da VM.

Dito isso, o processo de restauração é onde as vantagens dos backups incrementais se tornam um pouco menos impressionantes. Cada processo de restauração exige o processamento do backup completo original e de cada arquivo incremental em uma sequência específica. É necessária uma atenção cuidadosa ao gerenciamento dessas cadeias para garantir que não haja corrupção de arquivos ou links ausentes que possam comprometer toda a estratégia de backup.

Os backups incrementais ainda são bastante populares na maioria dos ambientes em que a eficiência do armazenamento e janelas de backup menores são a prioridade.

Backup diferencial

Os backups diferenciais, por outro lado, oferecem um equilíbrio entre os métodos de backup completo e incremental. Depois que o backup completo inicial é criado, cada operação diferencial subsequente captura todas as alterações feitas desde o backup original.

Em comparação com os backups incrementais, os backups diferenciais oferecem um processo de restauração muito mais fácil, pois são necessários apenas o backup completo e o backup diferencial mais recente. Como resultado, os processos de restauração que usam backups diferenciais são mais rápidos e previsíveis, em contraste com o lento processo de reconstrução de longas cadeias incrementais. Os backups diferenciais são um bom compromisso para ambientes de médio porte que precisam de simplicidade de recuperação e eficiência de storage.

O maior problema com os backups diferenciais é simplesmente a passagem do tempo. À medida que o tempo passa desde o último backup completo, cada arquivo diferencial subsequente aumenta, às vezes rivalizando com o tamanho original de um backup completo, caso tenha passado muito tempo. Como resultado, os backups diferenciais geralmente são mais eficazes quando há backups completos regulares que redefinem a linha de base dos backups diferenciais e mantêm a eficiência operacional.

Como configurar o backup incremental no QEMU?

A implementação do backup incremental no QEMU é particularmente interessante, pois geralmente é o método preferido para lidar com esse tipo de virtualização. Mais uma vez, a configuração e a implementação adequadas exigem um entendimento completo de vários mecanismos subjacentes, algo que este artigo aborda a seguir. Aqui, o artigo aborda três etapas importantes do processo: a criação da infraestrutura de backup inicial, o uso da libvirt para o gerenciamento de backup e o estabelecimento de procedimentos consistentes para operações regulares no futuro.

Criação do trabalho de backup inicial

Estabelecer o backup completo inicial com rastreamento de bitmap é a base de qualquer estratégia futura de backup incremental no QEMU. É uma etapa muito importante que cria um ponto de referência para todos os backups futuros.

O processo em questão não é particularmente difícil, mas pode ser desafiador em algumas situações. A primeira etapa é criar um bitmap persistente para rastrear os blocos alterados em um disco virtual. Esse bitmap pode ser tratado como a memória do QEMU, de modo que o QEMU saiba quais setores do disco foram modificados desde a última operação de backup.

Um comando executável para ativar o bitmap (no monitor do QEMU) deve ter a seguinte aparência: block-dirty-bitmap-add drive0 backup-bitmap persistent=on

Depois que o bitmap for estabelecido, é hora de executar o backup completo inicial com a VM em execução em mente. Esse comando específico deve incluir apenas o mínimo de configurações: local de destino, formato, etc.

drive-backup drive0 sync=full target=/backup/path/vm-base.qcow2 format=qcow2
Esse exemplo cria um arquivo de backup de linha de base usando o formato qcow2, que serve como ponto de partida para a cadeia incremental. É fundamental armazenar essa imagem de base em um ambiente seguro, pois sua corrupção pode comprometer todos os backups incrementais que a utilizam como ponto de partida.

Uso do Libvirt para gerenciar operações de backup

O Libvirt é um conjunto de bibliotecas e software de código aberto que fornece gerenciamento centralizado para uma variedade de hipervisores diferentes, incluindo QEMU, Xen, KVM, LXC, VMware e outros. O Libvert consiste em um daemon, uma API e utilitários de linha de comando para operar essa API.

O Libvirt ajuda a elevar o gerenciamento de backup do QEMU usando uma camada de API consistente que abstrai as diversas complexidades do ambiente. O Libvirt é um kit de ferramentas avançado que pode aprimorar as tarefas do hipervisor, fornecendo recursos de automação e uma estrutura flexível, que, de outra forma, devem ser executados por meio de sequências de comandos manuais.

A primeira coisa a fazer depois de tentar configurar os backups da libvirt no QEMU é verificar se a instalação atual oferece suporte a recursos de backup incremental (todas as versões acima da 6.0.0 devem oferecer suporte a isso). O comando correto para verificar a versão do libvirt é o seguinte:

$ virsh –version
Em seguida, configure o XML do domínio para incluir as definições de backup necessárias. O arquivo XML do domínio atual pode ser visualizado com:
$ virsh dumpxml vm_name > vm_config.xml
Depois que o arquivo for extraído, modifique a configuração para incluir elementos de backup como este:
<domain>

<backup>
<discos>
<disco name=’vda’ backup=’yes’ type=’file’>
<target file=’/backup/path/incremental1.qcow2’/>
</disco>
</discos>
</backup>

</domain>
Uma vez que a configuração tenha sido alterada, a operação de backup pode ser executada com o seguinte comando:
$ virsh backup-begin vm_name –backupxml vm_config.xml
A capacidade da funcionalidade de ponto de verificação do Libvirtde lidar com a coordenação em vários discos, se necessário, pode ser extremamente valiosa para os usuários.
$ virsh checkpoint-create vm_name checkpoint_config.xml

Guia passo a passo para emitir um novo backup incremental

Quando todos os processos de configuração básica estiverem concluídos, os backups incrementais regulares poderão ser executados usando a seguinte sequência de comandos:

  1. Para congelar o sistema de arquivos guest (se o agente guest já estiver configurado):
$ virsh qemu-agent-command your_vm_name ‘{“execute”: “guest-fsfreeze-freeze”}’
  1. Para criar um novo backup incremental enquanto especifica o bitmap de rastreamento:
drive-backup drive0 sync=incremental bitmap=backup-bitmap \
target=/path/to/backup/vm-incremental-$(date +%Y%m%d).qcow2 format=qcow2
  1. Para descongelar o sistema de arquivos convidado e retomar as operações normais:
$ virsh qemu-agent-command vm_name ‘{“execute”: “guest-fsfreezeze-thaw”}’
  1. Para redefinir o bitmap de rastreamento de alterações para se preparar para o ciclo de backup subsequente:
block-dirty-bitmap-clear drive0 backup-bitmap
  1. Para verificar a conclusão e a documentação do backup:
$ qemu-img info /backup/path/vm-incremental-$(date +%Y%m%d).qcow2
  1. Para testar a integridade do backup regularmente para garantir a capacidade de recuperação:
$ qemu-img check /backup/path/vm-incremental-$(date +%Y%m%d).qcow2

Esse fluxo de trabalho específico consegue equilibrar a eficiência e a minúcia, minimizando o impacto sobre as cargas de trabalho em execução e também garantindo uma cadeia de backup confiável para possíveis cenários de recuperação de desastres.

O que são comandos QMP para backup incremental?

O QEMU Machine Protocol, geralmente chamado de QMP, oferece uma interface baseada em JSON para monitorar e controlar programaticamente várias instâncias do QEMU. No que diz respeito especificamente às operações de backup, o QMP pode fornecer um controle preciso, valioso especialmente para automação ou integração com soluções de backup personalizadas. Os comandos a seguir podem ser executados usando o monitor QEMU diretamente ou usando scripts para criar operações programadas:

Introdução aos comandos básicos do QMP

Os comandos do QMP usam uma estrutura JSON consistente para facilitar tarefas como a criação de scripts e a automação. A criação de scripts e a automação fornecem controle refinado sobre os mecanismos internos do QEMU sem acesso direto à interface do console de um hipervisor.

Para entrar no modo QMP enquanto o QEMU estiver em execução, conecte-se ao soquete do monitor do QEMU e inicialize a conexão da seguinte maneira:

$ socat UNIX:/path/to/qemu-monitor-socket –
{“execute”: “qmp_capabilities”}

Alguns dos comandos mais valiosos para operações de backup incluem:

  • block-dirty-bitmap-add para rastreamento de alterações;
  • drive-backup para execução de backups; e
  • transaction para várias tarefas de agrupamento, etc.

Cada um desses comandos também aceita uma série de parâmetros específicos em JSON:

{“execute”: “block-dirty-bitmap-add”,
“arguments”: {“node”: “drive0”, “name”: “backup-bitmap”, “persistent”: true}}
As respostas estruturadas do QMP são perfeitas para analisar recursos programáticos. Cada comando produz um objeto JSON que representa sucesso ou falha e uma abundância de detalhes relevantes. Essa abordagem estruturada torna o tratamento de erros de scripts de backup automatizados muito mais eficaz, o que é um recurso inestimável em qualquer ambiente de produção.

Como criar um novo backup incremental usando o QMP

A criação de backup incremental usando o QMP é uma sequência de operações lógicas que captura apenas os blocos alterados, mantendo a consistência dos dados. Ele também usa o rastreamento de bitmap para minimizar a duração e o tamanho do backup, da mesma forma que foi usado nos diferentes exemplos acima.

O estabelecimento de um bitmap de rastreamento, se nem sempre existir um, deve ser realizado apenas uma vez antes de um backup completo. Veja como isso pode ser feito:

{“execute”: “block-dirty-bitmap-add”,
“arguments”: {“node”: “drive0”, “name”: “backup-bitmap”, “persistent”: true}}
Depois que o bitmap for estabelecido, o drive-backup deve ser usado para executar um backup completo usando os parâmetros necessários:
{“execute”: “drive-backup”,
“arguments”: {“device”: “drive0”, “sync”: “full”,
“target” (destino): “/path/to/vm-base.qcow2”, “format”: “qcow2”}}
Quaisquer backups incrementais subsequentes alteram essa sequência apenas de forma secundária, trocando o tipo de backup completo pelo incremental e fazendo referência ao mapa de bits de rastreamento criado acima para capturar apenas os blocos alterados:
{“execute”: “drive-backup”,
“arguments”: {“device”: “drive0”, “sync”: “incremental”, “bitmap”: “backup-bitmap”,
“target” (destino): “/path/to/vm-incr-20250407.qcow2”, “format”: “qcow2”}}

Entendendo as imagens de apoio e os bitmaps

A relação entre imagens de backup e bitmaps sujos cria a base técnica para backups incrementais eficientes no QEMU. A manutenção de cadeias de backup limpas só é possível com um entendimento adequado dessas relações.

As imagens de apoio criam relações pai-filho entre os arquivos qcow2 para que cada backup incremental possa fazer referência ao seu antecessor. Consulte a cadeia de backup de qualquer imagem qcow2 com o seguinte comando QMP:

{“execute”: “query-block”,
“arguments”: {“query-backing-chain”: true}}

O mesmo comando também pode ser usado para visualizar bitmaps existentes em uma unidade específica, alterando um dos argumentos:
{“execute”: “query-block”,
“arguments”: {“filter-node-name”: “drive0”}}
A consistência do bitmap deve ser cuidadosamente mantida nas operações de backup para criar cadeias incrementais confiáveis. Após a conclusão de um backup incremental, recomenda-se também limpar o bitmap para começar a rastrear todas as alterações do zero para a próxima operação em potencial:
{“execute”: “block-dirty-bitmap-clear”,
“arguments”: {“node”: “drive0”, “name”: “backup-bitmap”}}

Uma operação de reinicialização como essa marca a conclusão de um único ciclo de backup e prepara o sistema para executar também o ciclo seguinte.

Problemas comuns e solução de problemas de backups incrementais do QEMU

Todo o planejamento do mundo pode não evitar que as operações de backup do QEMU encontrem obstáculos ou problemas. Saber como diagnosticá-los e resolvê-los com eficiência é um conhecimento crucial que pode significar a diferença entre incorrer em pequenos inconvenientes e perdas substanciais de dados. Esta seção aborda alguns dos desafios mais comuns que os administradores enfrentam em relação às soluções de backup incremental.

“Bitmap não encontrado”

Os errosde “Bitmap não encontrado ” geralmente resultam de problemas com a persistência de bitmap. Para que o rastreamento incremental seja consistente usando o QEMU, os bitmaps devem persistir entre as reinicializações da VM. O sinalizador persistent=on deve ser usado ao criar cada novo bitmap, pois não há como alterar a configuração de persistência do bitmap existente a não ser recriando-o do zero.

“Permissão negada”

Erros de permissão são bastante comuns em operações de backup, especialmente em ambientes com regras de segurança complexas. Há um determinado comando de teste que pode ser iniciado para garantir que o processo QEMU tenha permissão para gravar no destino do backup:

$ sudo -u libvirt-qemu touch /path/to/backup/test-write.tmp
$ rm /path/to/backup/test-write.tmp
Se esse teste falhar, a única solução é ajustar manualmente as permissões ou a propriedade em um diretório de backup.

“O dispositivo está bloqueado”

Se determinadas operações tiverem bloqueios exclusivos no dispositivo de destino, as operações de backup poderão falhar com a mensagem “device is locked” (o dispositivo está bloqueado). Esses bloqueios podem ocorrer durante instantâneos ou trabalhos de backup simultâneos, e a única maneira de evitá-los é listar previamente os trabalhos de backup ativos para poder encontrar possíveis conflitos manualmente:

block-job-list
Também é possível cancelar determinadas operações, quando apropriado, com o seguinte comando:
block-job-cancel job-id

Cadeias de backup corrompidas

A corrupção da cadeia de backup é particularmente desafiadora nesse contexto, tornando imediatamente inutilizáveis todos os backups incrementais subsequentes. A melhor abordagem de recuperação em situações como essa é criar um novo backup completo e estabelecer uma nova cadeia para começar de novo:

drive-backup drive0 sync=full target=/path/to/backup/new-base.qcow2 format=qcow2

Estados inconsistentes do aplicativo

A inconsistência pode interromper o processo de backup e resultar em backups incompletos ou danificados. Nesse caso, a resolução exata depende da essência do problema, portanto, não há uma solução única para todos os problemas.

Por exemplo, se um aplicativo estiver executando operações de gravação durante o backup, isso poderá resultar em backups com dados gravados apenas parcialmente. Isso pode ser resolvido apenas interrompendo todas as VMs associadas antes de realizar operações de backup e descongelando-as depois com estes comandos:

$ virsh qemu-agent-command vm-name ‘{“execute”: “guest-fsfreeze-freeze”}’
# Executar operações de backup
$ virsh qemu-agent-command vm-name ‘{“execute”: “guest-fsfreeze-thaw”}’

Esgotamento do espaço em disco

O esgotamento do espaço em disco pode interromper as operações de backup, deixando para trás arquivos de backup incompletos. Esses arquivos apenas consomem espaço de armazenamento: eles não têm valor de recuperação em sua forma incompleta. O monitoramento de espaço é outra camada de comandos que deve ser implementada nos scripts de backup para evitar o início de qualquer operação quando o espaço disponível estiver abaixo de um determinado limite.

$ df -h /backup/path/ | awk ‘NR==2 {print $5}’ | sed ‘s/%//’

Deve-se considerar a implementação de processos de limpeza regulares para remover arquivos de backup parciais.

“A imagem não está no formato qcow2”

As operações de backup podem falhar com o erro “Image not in qcow2 format” (A imagem não está no formato qcow2), mesmo quando o formato correto é especificado previamente. Esses problemas geralmente ocorrem ao tentar fazer backups incrementais quando as imagens de base são armazenadas em um formato incompatível.

Isso pode ser resolvido verificando primeiro o formato da imagem de base:

$ qemu-img info /backup/path/base-image.qcow2

Depois que o formato for verificado, a imagem em questão poderá ser convertida em qcow2, enquanto se inicia uma nova cadeia de backup, com o seguinte comando:
$ qemu-img convert -O qcow2 original-image.raw /backup/path/converted-base.qcow2
A solução eficaz de problemas sempre começa com um registro complexo. O registro detalhado das operações de backup é fundamental para capturar informações detalhadas quando vários erros ou problemas aparecem:
$ QEMU_MONITOR_DEBUG=1 virsh backup-begin vm-name backup-xml.xml
Esses registros se mostram inestimáveis ao diagnosticar problemas complexos que, de outra forma, poderiam ser praticamente insolúveis.

Métodos de backup para execução de VMs QEMU

Há várias diferenças dignas de nota nas duas abordagens do gerenciamento de backup do QEMU que foram abordadas aqui.

A primeira é com a ajuda dos comandos do QEMU Monitor: eles são executados diretamente pelo console do QEMU Monitor usando sintaxe baseada em texto e normalmente são usados para executar várias tarefas manualmente. Embora seja verdade que a libvirt ofereça determinados recursos para ajudar na automação, sua ideia básica ainda está mais próxima dos comandos diretos do monitor QEMU por natureza.

O segundo usa o QMP, ou QEMU Machine Protocol, um sistema projetado para interações programáticas que podem ser acessadas usando uma conexão de soquete. Ele é perfeito para criação de scripts, automação e sequenciamento de backup com todos os seus comandos e respostas formatados em JSON.

Sua funcionalidade é essencialmente a mesma em seu núcleo; são apenas interfaces diferentes para acessar os mesmos recursos do QEMU.

Ambas as abordagens oferecem várias maneiras diferentes de criar um backup de uma VM em execução no QEMU. Algumas dessas possibilidades já foram exploradas, como o rastreamento de blocos sujos, os recursos de congelamento/descongelamento do agente convidado do QEMU e o recurso de ponto de verificação da libvirt.

Uma alternativa que ainda não foi mencionada é o recurso de snapshot externo. Ele também é frequentemente considerado uma das abordagens mais simples para trabalhar com VMs em execução, criando um novo arquivo de sobreposição para o qual todas as operações de gravação são redirecionadas, enquanto a imagem de disco original é preservada no estado em que se encontra para o processo de backup. Um comando para usar esse método tem a seguinte aparência:

$ virsh snapshot-create-as –domain vm-name snap1 –diskspec vda,file=/path/to/overlay.qcow2 –disk-only
Depois que todo o processo de backup tiver sido concluído, é importante confirmar todas as alterações do arquivo de sobreposição para a imagem de base de uma maneira específica:

$ virsh blockcommit vm-name vda –active –pivot
Deve-se observar também que algumas soluções de backup de terceiros oferecem recursos de integração com o QEMU que fornecem uma variedade de recursos adicionais: gerenciamento centralizado, compactação, deduplicação, suporte para backup de VMs ativas, etc. Eles aproveitam a API do QEMU e adicionam suas próprias camadas de orquestração e ajustes de otimização de armazenamento. Para tornar o tópico mais claro, podemos pegar uma dessas soluções e explorar seus recursos em mais detalhes, que é exatamente o que o artigo faz abaixo com o Bacula Enterprise.

Todos esses métodos de backup têm suas vantagens distintas e contextos de produção nos quais eles superam os demais, como, por exemplo

  • Rastreamento de blocos sujos com backups incrementais: uma das abordagens mais equilibradas, oferecendo impacto mínimo no desempenho e alta eficiência; uma ótima opção para ambientes de produção com limitações de janela de backup e VMs razoavelmente grandes.
  • Integração do agente convidado (congelamento/descongelamento): uma opção comum para aplicativos com muitas transações e servidores de banco de dados que exigem consistência total dos dados, mesmo ao custo de breves janelas de tempo de inatividade durante os backups.
  • Recursos de ponto de verificação: fornecem a recuperação mais completa, mas ao custo de alto uso de recursos, o que os torna a opção preferida em ambientes de desenvolvimento e sistemas críticos nos quais a sobrecarga adicional é justificada pela preservação do estado do aplicativo.
  • Instantâneos externos: ótimos em ambientes que precisam de backups com pouca ou nenhuma configuração, o que os torna perfeitos em VMs pequenas e médias com tolerância suficiente para breves lentidões.
  • Soluções de backup de terceiros: proporcionam a melhor experiência para empresas com uma grande quantidade de VMs e hosts, enfatizando o gerenciamento centralizado e os recursos avançados para justificar seus altos custos de licenciamento.

APIs de backup e ferramentas de integração do QEMU

O rico ecossistema de APIs do QEMU oferece aos desenvolvedores e administradores acesso programático profundo a recursos versáteis de virtualização. Essas APIs funcionam como a base das operações de backup, fornecendo interfaces consistentes e abstraindo as complexidades do gerenciamento de vários ambientes de máquinas virtuais.

A Block Device Interface está no centro dos recursos de backup do QEMU. Ela permite operações de gerenciamento de discos virtuais, incluindo, mas não se limitando apenas aos recursos de backup e instantâneos explicados acima. Essa interface pode oferecer suporte a operações como gerenciamento de bitmap, blockdev-backup e backup de unidade por meio do QMP e do monitor QEMU. Essas funções de baixo nível também são perfeitas para os desenvolvedores que criam soluções de backup personalizadas, oferecendo controle granular sobre praticamente todos os aspectos do processo de backup.

A API libvirt é outra opção popular nesse contexto, envolvendo as interfaces nativas do QEMU com uma camada de abstração padronizada que pode até operar em diferentes hipervisores. Como mencionado anteriormente, a libvirt ajuda a simplificar as operações de backup com funções de alto nível que podem lidar automaticamente com vários detalhes subjacentes. Por exemplo, a função virDomainBackupBegin() pode gerenciar todos os aspectos do início de um backup incremental, desde o rastreamento de bitmap até instantâneos temporários.

Quanto aos desenvolvedores Python, as ligações libvirt-python podem ser usadas como um ponto de entrada relativamente conveniente para o conjunto de ferramentas de backup do QEMU. As associações fornecem a API completa do libvirt em uma sintaxe Python, tornando os scripts de automação muito mais legíveis e fáceis de manter. Veja como seria um script de backup simples em Python:

import libvirt
conn = libvirt.open(‘qemu:///system’)
dom = conn.lookupByName(‘vm-name’)
dom.backupBegin(backup_xml, None)
A natureza padronizada dessas APIs cria um rico ecossistema de soluções de backup de terceiros para expandir os recursos existentes do QEMU. Há muitas ferramentas diferentes que podem aproveitar essas APIs para criar experiências de backup repletas de recursos e, ao mesmo tempo, simplificar muitas das complexidades técnicas que este artigo analisou. O restante do artigo explora os recursos essenciais das soluções de backup QEMU de terceiros, usando o Bacula Enterprise para ilustrar como uma solução de backup pode funcionar com o conjunto de recursos originais do QEMU.

Recursos essenciais em uma solução de backup QEMU

Certos recursos essenciais separam as soluções de backup robustas das abordagens básicas dos processos de backup. Os recursos essenciais, como os mencionados abaixo, devem garantir que uma estratégia de backup do QEMU permaneça confiável, eficiente e recuperável em uma gama diversificada de ambientes de virtualização.

Os mecanismos de consistência de dados são o recurso mais importante de qualquer solução de backup competente nesse contexto. Uma solução de backup deve ser facilmente integrada à API do agente convidado do QEMU ou oferecer seus próprios plug-ins com reconhecimento de aplicativos para garantir a consistência do banco de dados. A capacidade de coordenação com aplicativos em execução pode ajudar a criar backups em um estado limpo e recuperável, sem qualquer corrupção no meio da transação. Soluções avançadas para casos de uso específicos de armazenamento que vão além dos ciclos de congelamento e descongelamento também devem ser consideradas quando aplicáveis, possibilitando o gerenciamento de estados de transação de aplicativos específicos em uma base separada.

O gerenciamento eficiente do armazenamento é outro ponto importante para soluções abrangentes de backup, com recursos comuns que incluem deduplicação, compactação, retenção automatizada e muito mais. As abordagensincrementais para sempre oferecem janelas mínimas de backup e consumo de storage por meio do rastreamento inteligente de alterações. Nesse contexto, a verificação automatizada em uma base regular é praticamente obrigatória, testando a integridade e a capacidade de recuperação do backup sempre que possível para garantir que os backups ainda sejam viáveis e completos em todos os momentos.

A orquestração e o agendamento são incrivelmente importantes para ambientes mais complexos, transformando os procedimentos manuais de backup em processos confiáveis e automatizados, sem a necessidade de criar scripts complexos no processo. A limitação inteligente de recursos, o gerenciamento de dependências e as opções flexíveis de agendamento são praticamente esperados aqui. Além dessa funcionalidade básica,mecanismos abrangentes de relatórios e alertas devem estar presentes em qualquer solução de backup competente para QEMU, bem como a integração com sistemas de monitoramento existentes e suporte a RBAC para melhor controle de acesso.

Todos esses recursos se tornam cada vez mais importantes à medida que a infraestrutura virtual de negócios cresce em tamanho e complexidade, transformando o backup de um processo técnico em um aplicativo de negócios com requisitos de governança específicos e responsabilidades definidas.

Como fazer backup do QEMU com o Bacula?

O Bacula Enterprise pode fornecer suporte extensivo para ambientes QEMU usando seu módulo de virtualização – entre outros recursos. O Bacula combina a natureza de código aberto do ambiente com gerenciamento centralizado, suporte premium e controle refinado sobre praticamente todos os processos. Essa incrível combinação de parâmetros faz com que ele seja a solução preferida de grandes empresas com diversos requisitos de infraestrutura virtual.

A configuração do Bacula para backups QEMU começa com a instalação do Bacula File Daemon nos hosts do hipervisor. O daemon deve ser configurado para acessar suas instâncias QEMU com a ajuda da libvirt, possibilitando backups completos e incrementais sem possíveis instâncias de corrupção de dados.

Uma configuração central para esses backups é armazenada no arquivo de configuração do Bacula Director, onde os usuários podem definir trabalhos de backup para direcionar VMs específicas:

Job {
Nome = “QEMU-VM-Backup”
JobDefs = “DefaultJob” (Trabalho Padrão)
Cliente = qemu-host-fd
Pool = VMPool
FileSet = “QEMU-VMs”
}
FileSet {
Nome = “QEMU-VMs”
Include {
Options {
signature = MD5
compression = GZIP
}
Plugin = “qemu: VM=nome-vm”
}
}
Uma configuração como essa aproveita o plug-in QEMU do Bacula para lidar automaticamente com todas as complexidades e nuances desse processo de backup (incluindo o rastreamento de bitmap).

Um dos recursos mais fortes do Bacula é o uso de uma abordagem baseada em catálogo para os recursos de recuperação de várias VMs. O Bacula pode manter metadados detalhados de cada backup e todas as relações entre eles, quando necessário. Dessa forma, a recuperação precisa em um ponto no tempo torna-se possível sem a necessidade de rastrear cadeias de backup ou dependências de restauração manualmente.

Para a recuperação de desastres, o Bacula usa seus recursos de recuperação bare-metal para restaurar hipervisores inteiros e todas as suas configurações de VM e imagens de disco. As abrangentes trilhas de auditoria e as imposições de retenção do Bacula são particularmente úteis em empresas com requisitos rigorosos de conformidade.

Os muitos recursos empresariais do Bacula, combinados com sua arquitetura aberta, fazem dele uma opção interessante para empresas que precisam de recursos robustos de backup QEMU capazes de escalonar desde implantações de um único servidor até vastos ambientes de vários data centers.

Perguntas frequentes

Quais são os diferentes métodos de backup de uma máquina virtual QEMU?

As máquinas virtuais QEMU têm várias maneiras de criar backups a partir delas, incluindo backups completos, backups incrementais, backups diferenciais e instantâneos externos.

  • Os backups completos capturam a VM inteira, mas exigem um espaço de armazenamento considerável.
  • Os backups incrementais usam o rastreamento de blocos sujos para monitorar os blocos alterados com eficiência, mas são difíceis de restaurar.
  • Os backups diferenciais são o meio termo entre os dois, mas também não são particularmente universais em sua variedade de casos de uso.
  • Os instantâneos externos redirecionam as operações de gravação para arquivos de sobreposição em uma base temporária enquanto o backup da imagem base é feito.

É possível fazer backup de uma máquina virtual QEMU em execução sem tempo de inatividade?

Sim, o QEMU tem suporte para backups em tempo real de VMs em execução usando seus próprios mecanismos, como rastreamento de blocos sujos ou instantâneos externos. Para obter a consistência ideal, os administradores geralmente usam agentes convidados para congelar brevemente o sistema de arquivos para backups críticos, garantindo a integridade dos dados do aplicativo, mas tornando esses backups inaceitáveis para tipos de negócios específicos.

Qual é a função do recurso de snapshot do QEMU nas soluções de backup?

Os instantâneos do QEMU criam capturas pontuais do estado atual da VM para servir como base para diferentes estratégias de backup. O estado dos instantâneos internos é armazenado no arquivo original, enquanto os instantâneos externos redirecionam as operações de gravação para arquivos de sobreposição separados. Os instantâneos também ajudam a ativar vários recursos úteis, como reversão, clonagem, migração e muito mais.

O uso de uma solução de backup e recuperação de alta segurança para proteger os ambientes QEMU normalmente também oferece proteção em um único painel de vidro para todo o ambiente de TI de uma organização, o que é muito vantajoso. Ela também oferece muito mais recursos de monitoramento, geração de relatórios, conformidade, segurança e conveniência, geralmente necessários para a execução de negócios de médio e grande porte. Esperamos que essas informações tenham sido úteis para você, que pode obter mais informações em www.baculasystems.com.

Sobre o autor
Rob Morrison
Rob Morrison é o diretor de marketing da Bacula Systems. Ele começou sua carreira de marketing de TI na Silicon Graphics, na Suíça, e desempenhou intensamente várias funções de administração de marketing por quase 10 anos. Nos 10 anos seguintes, Rob também ocupou vários cargos de administração de marketing na JBoss, Red Hat e Pentaho, assegurando o crescimento da participação no mercado dessas empresas reconhecidas. Ele é formado pela Universidade de Plymouth e tem um diploma de honras em mídia digital e comunicação, além de ter feito um programa de estudos no exterior.
Deixe um comentário

Seu e-mail não será publicado. Os campos obrigatórios estão marcados com *