Backup incremental para KVM: restaure VM em instantes
Backup é aquele recurso que todo ambiente de virtualização precisa ter, mas que ninguém quer precisar usar. O problema é quando a recuperação de uma VM significa esperar horas pela cópia de gigabytes ou ter que lidar com processos que consomem storage e infraestrutura em excesso. No KVM, esse cenário está mudando. O backup incremental para KVM permite que, depois da primeira cópia completa, os backups seguintes armazenem apenas o que foi alterado. E, com recursos como layering e Quick Restore, a recuperação pode começar antes mesmo de todos os dados serem consolidados.
Mas como isso funciona na prática? E até onde essa abordagem consegue acelerar a restauração de uma VM? Neste artigo, vamos entender como funciona o backup incremental para KVM no Apache CloudStack, quais são suas vantagens, como o Quick Restore reduz o tempo de recuperação e quais cuidados devem ser considerados na implementação.
Por que o KVM precisava de um backup incremental próprio
O framework de backup do CloudStack existe desde 2019, mas nasceu atrelado à integração com Veeam. Como resultado, o backend do Veeam concentrava praticamente toda a configuração (políticas, retenção, agendamento, etc), enquanto o CloudStack apenas orquestrava o processo. Além disso, o KVM ficou de fora dessa equação por muitos anos.
Com o tempo, surgiram outras integrações, como a do Dell NetWorker em 2023, e, no fim de 2024, o Apache CloudStack 4.20 introduziu o Simple NAS Backup and Recovery Provider, um provedor nativo para KVM baseado em NAS. A solução permitia realizar backups completos, mas ainda trazia limitações importantes: exigia uma nova área de armazenamento e funcionava apenas com storages NFS ou local. Em um Webcast realizado recentemente, a SC Clouds apresentou uma abordagem própria para superar essas restrições, com um provedor mais robusto e genuinamente nativo para KVM.
Como o backup incremental para KVM funciona na prática
A solução aproveita um recurso já conhecido do QEMU/KVM: o uso de camadas, também chamada de deltas. Cada delta pode manter um backing file, formando uma cadeia de camadas sobre a base original. O CloudStack reutiliza exatamente essa lógica para os backups, só que agora também copia as camadas para uma área de armazenamento secundária.
Primeiro, o CloudStack cria um novo delta sobre o volume da VM e copia o volume base inteiro para o armazenamento secundário: esse é o backup completo. Em seguida, cada novo backup gera outro delta e copia apenas o delta anterior, que contém somente os dados escritos desde a última cópia. Dessa forma, o processo forma uma cadeia encadeada de backups incrementais.
Vale destacar um ponto que costuma gerar confusão: o tamanho da cadeia de backups não define quantos backups o CloudStack mantém guardados. Na verdade, esse parâmetro apenas determina de quantos em quantos backups o CloudStack gera um novo full. A retenção, por sua vez, define quantos backups o sistema mantém armazenados e o CloudStack permite ajustar esse valor separadamente nos agendamentos.
Compressão assíncrona: eficiência sem travar a VM
Depois que o CloudStack cria o backup, ele pode executar a compressão de forma assíncrona. Nesse processo, o backup original não é sobrescrito imediatamente: primeiro, o CloudStack gera um novo arquivo já comprimido e, somente após a conclusão, substitui o arquivo original.
Na prática, isso permite que a compressão aconteça em segundo plano, sem bloquear a conclusão da etapa de criação do backup. Além disso, o CloudStack permite controlar quantos jobs de compressão podem ser executados simultaneamente em cada host, evitando que várias operações concorrentes consumam recursos excessivos.
Esse controle também dá mais flexibilidade ao administrador: é possível aumentar o nível de paralelismo quando há recursos disponíveis ou limitar a quantidade de operações simultâneas para preservar o desempenho dos hosts.
Quick Restore: a virada na restauração
É aqui que o processo ganha uma vantagem importante. Em vez de esperar a cópia completa dos dados antes de disponibilizar a VM, o Quick Restore cria novos deltas no armazenamento primário e usa o backup armazenado no secundário como backing file. Em seguida, o CloudStack inicia a VM e começa a consolidação dos volumes em segundo plano.
Na prática, a VM volta a operar em pouco tempo, enquanto o CloudStack continua a restauração. A consolidação, porém, leva mais tempo do que uma restauração tradicional. Isso acontece porque o Quick Restore prioriza a disponibilidade inicial da VM e deixa a consolidação completa dos dados para uma etapa posterior.
Durante a consolidação, a VM continua disponível para uso, mas o processo pode reduzir o desempenho dos discos. Depois que o CloudStack conclui a consolidação, o desempenho volta ao normal. Assim, o Quick Restore reduz o tempo necessário para recuperar o acesso à VM, mesmo que a restauração completa leve mais tempo.
Limitações e boas práticas
Vale lembrar que o backup incremental para KVM depende do recurso de camadas do QEMU, o que restringe seu uso a storages baseados em arquivo, como NFS, SharedMountPoint ou armazenamento local. Esse recurso não funciona com RBD, por exemplo. Além disso, nenhuma das funcionalidades apresentadas aqui (snapshot de volume, snapshot de VM ou backup) é compatível com snapshots de VM que incluem memória.
Logo, para evitar problemas com bancos de dados dentro das VMs, a SC Clouds recomenda habilitar o parâmetro de quiesce. Com essa opção, o QEMU Guest Agent congela o sistema de arquivos durante a criação de cada delta. Assim, cada camada do backup mantém consistência no nível do sistema de arquivos, reduzindo o risco de encontrar transações incompletas durante a restauração.
Backup incremental para KVM: mais eficiência na prática
O backup incremental para KVM apresentado pela SC Clouds em webcast mostra como o CloudStack pode aproveitar recursos nativos do QEMU para tornar a proteção e a recuperação mais eficientes. A solução trabalha com camadas, registra apenas as alterações necessárias, comprime os dados de forma assíncrona e usa o Quick Restore para colocar a VM novamente em operação antes de concluir toda a consolidação.
No fim, o resultado é uma estratégia mais eficiente para quem opera CloudStack em escala: menos dados transferidos e armazenados, processos mais eficientes e recuperação mais rápida das cargas críticas. Para entender cada etapa na prática, assista à demonstração completa no webcast da SC Clouds, disponível no vídeo abaixo.