Hot Backup de Máquinas Virtuais no ODA com KVM

(Safe Harbor) Antes de iniciarmos, informo que este procedimento não está documentado em nenhuma nota oficial da Oracle (MOS), embora eu mencione algumas referências ao longo do texto. Cheguei a este procedimento após conversar com vários profissionais de KVM e após extensa leitura em fóruns; ele foi testado diversas vezes antes da publicação deste artigo. Ainda assim, recomendo cautela: valide primeiro em ambiente de testes/homologação e só então aplique no ambiente de produção, após testes exaustivos. Já que o Safe Harbor foi pronunciado, bora colocar a mão na massa!!!

Hoje trago para vocês uma forma diferente de realizar backups no Oracle Database Appliance (ODA). Este artigo será dividido em duas partes: uma destinada às VMs Linux e outra às VMs Windows.

Normalmente, as notas de backup sugerem duas abordagens:

Parar a máquina e copiar os discos.
Congelar a maquina, criar um snapshot do volume ACFS e copiar os arquivos para outro disco, conforme descrito na nota 2779329.1.

A primeira opção é, sem dúvida, a mais rápida e segura. Sempre que possível, escolha essa abordagem. Porém, na prática, raramente temos a chance de parar a máquina, e quase sempre precisamos realizar o backup das VMs em modo hot (a quente).

De acordo com a nota 2779329.1, para esse cenário é necessário criar snapshots do ACFS, e mesmo assim os discos são colocados em modo “Freeze". E aí surgem dois problemas:

• Discos em locais diferentes: no ODA, caso exista um segundo disco anexado à VM, ele é armazenado em uma área distinta do disco de boot. Isso significa que será necessário criar dois snapshots em momentos diferentes, gerando inconsistências de data e hora, o que pode se tornar uma verdadeira dor de cabeça.

• Gestão dos snapshots: após o backup, é preciso excluir os snapshots do ACFS. Essa atividade, além de repetitiva, aumenta bastante a carga de trabalho administrativo.

E, ao realizar os backups pelas formas mencionadas acima, em determinado momento me surgiu a seguinte pergunta:

Existe alguma forma de os utilitários do KVM realizarem o backup em vez de depender apenas de procedimentos via storage?

Uma vez que a pergunta ficou ‘instalada’ na minha cabeça, comecei a conversar com alguns mestres em KVM e encontrei a seguinte solução.

virsh snapshot-create-as --domain linux_vm --name FILE_STAGE_BACKUP.TEMP --disk-only --atomic --quiesce

Mas calma, não vá executando o comando logo de cara (rs). Ainda temos um longo caminho de explicação e é preciso cautela quanto ao comando que será utilizado.

Agora vamos começar a analisar as estruturas da VM no KVM/ODA. Os comandos apresentados aqui podem ser executados tanto em um ODA quanto em um ambiente de KVM Server.

O primeiro passo é compreender quantos discos a VM possui. Para verificar isso, vamos executar o seguinte comando:

root@kvm-001:/kvm# virsh domblklist linux_vm
 Target   Source
---------------------------------
 vda      /kvm/linux_boot
 vdb      /kvm/disco_secundario

Como podemos ver, temos 2 discos: o disco de boot e o disco secundário. Neste caso, o ambiente que estou utilizando é um KVM Server, mas a mesma regra se aplica ao ODA.

A outra verificação necessária é confirmar se o KVM guest agent está instalado na máquina virtual. Para isso, utilizamos o seguinte comando:

[root@guestvm ~]# rpm -qa | grep guest
qemu-guest-agent-9.0.0-10.el9_5.x86_64

Agora que já verificamos as informações sobre a quantidade de discos e a presença do guest agent, vamos de fato falar sobre o hot-backup.

Chegou o momento de executar o comando para iniciarmos o backup a quente. Esse comando, na prática, faz com que o próprio KVM crie o snapshot dos discos — e não o ACFS. Dessa forma, a máquina continuará online e todas as operações passarão a ser gravadas em um novo arquivo.

root@kvm-001:/kvm# virsh snapshot-create-as --domain linux_vm --name FILE_STAGE_BACKUP.TEMP --disk-only --atomic --quiesce
Domain snapshot FILE_STAGE_BACKUP.TEMP created

Como dito anteriormente, esse comando colocará todos os discos em modo snapshot, criando novos apontamentos para eles. Assim, o disco boot_linux será transformado em boot_linux.FILE_STAGE_BACKUP.TEMP e o disco_secundario em disco_secundario.FILE_STAGE_BACKUP.TEMP, como demonstrado na saída abaixo:

root@kvm-001:/kvm# virsh snapshot-create-as --domain linux_vm --name FILE_STAGE_BACKUP.TEMP --disk-only --atomic --quiesce
Domain snapshot FILE_STAGE_BACKUP.TEMP created
root@kvm-001:/kvm# ls -lrt
total 6488960
drwxr-xr-x 2 root         root       4096 Sep 10 13:54 outras_maquinas
-rw------- 1 libvirt-qemu kvm    35651584 Sep 10 19:07 disco_secundario
-rw------- 1 libvirt-qemu kvm  6605111296 Sep 10 19:07 linux_boot
-rw------- 1 libvirt-qemu kvm     1835008 Sep 10 19:10 linux_boot.FILE_STAGE_BACKUP.TEMP
-rw------- 1 libvirt-qemu kvm     2031616 Sep 10 19:10 disco_secundario.FILE_STAGE_BACKUP.TEMP

Dessa forma, as escritas passam a ser direcionadas para um novo ponto, encerrando as operações no linux_boot e iniciando em linux_boot.FILE_STAGE_BACKUP.TEMP e disco_secundario.FILE_STAGE_BACKUP.TEMP.

A partir desse momento, podemos copiar o disco para o diretório de nossa preferência.

root@kvm-001:/kvm# scp linux_boot disco_secundario root@serverbackup:/backup

Agora vamos resumir o que aconteceu:

Primeiro, criamos um snapshot online da VM, forçando-a a escrever tudo em novos arquivos, com o sufixo .FILE_STAGE_BACKUP.TEMP.

Ao executar o comando de backup, os arquivos da VM (linux_boot e disco_secundario) ficaram em um ponto consistente, permitindo que fossem copiados de forma segura para outro local.
Por fim, copiamos os arquivos para outro servidor.

Pronto! Até aqui realizamos o backup, mas agora precisamos executar alguns passos para que as escritas voltem a ser direcionadas inteiramente para o disco linux_boot, e não mais para o linux_boot.FILE_STAGE_BACKUP.TEMP.

Como criamos o snap, vamos agora verificar e deletar apenas os metadados do mesmo.

root@kvm-001:/kvm# virsh snapshot-list linux_vm
 Name                     Creation Time               State
---------------------------------------------------------------------
 FILE_STAGE_BACKUP.TEMP   2025-09-10 19:07:30 -0300   disk-snapshot

Caminho atual de onde o VM estava escrevendo:

root@kvm-001:/kvm# virsh domblklist linux_vm
 Target   Source
--------------------------------------------------------
 vda      /kvm/linux_boot.FILE_STAGE_BACKUP.TEMP
 vdb      /kvm/disco_secundario.FILE_STAGE_BACKUP.TEMP

Agora chegamos a um ponto importante: neste momento vamos deletar apenas os METADADOS do snapshot, de forma que os arquivos ainda permanecerão no local.(sempre verifique e o sintaxe --metadata esta no final do comando)

root@kvm-001:/kvm# virsh snapshot-delete --domain linux_vm FILE_STAGE_BACKUP.TEMP --metadata
Domain snapshot FILE_STAGE_BACKUP.TEMP deleted

Podemos ver agora que não existe mais snapshot:

root@kvm-001:/kvm# virsh snapshot-list linux_vm
 Name   Creation Time   State
-------------------------------

Podemos observar que a máquina ainda continua apontando para os discos do snapshot, mesmo após a exclusão:

root@kvm-001:/kvm# virsh domblklist linux_vm
 Target   Source
--------------------------------------------------------
 vda      /kvm/linux_boot.FILE_STAGE_BACKUP.TEMP
 vdb      /kvm/disco_secundario.FILE_STAGE_BACKUP.TEMP

Nesse momento a VM esta nessa situação:

Agora temos um impasse: o metadata do snapshot foi deletado, mas a máquina ainda está apontando para o arquivo gerado. Como fazer para voltar ao disco original sem perder as transações que ocorreram nesse período?

Para resolver isso, precisamos realizar um merge dos discos. No nosso caso, a VM possui dois discos: vda e vdb.

Nesse momento, precisamos realizar o merge do disco /kvm/linux_boot.FILE_STAGE_BACKUP.TEMP para o disco /kvm/linux_boot, e do disco /kvm/disco_secundario.FILE_STAGE_BACKUP.TEMP para /kvm/disco_secundario.

O merge deve ser feito disco por disco. No nosso caso, a VM possui 2 discos, mas se a sua VM tiver 5 discos, será necessário executar o merge em cada um deles. Como aqui são apenas 2 discos, vamos ao comando:

Primeiro do VDA:

root@kvm-001:/kvm# virsh blockcommit linux_vm vda --active --verbose --pivot
Block commit: [100.00 %]
Successfully pivoted

Depois do VDB:

root@kvm-001:/kvm# virsh blockcommit linux_vm vdb --active --verbose --pivot
Block commit: [100.00 %]
Successfully pivoted

Pronto, agora vamos ver onde o KVM esta escrevendo as operações das VMs:

root@kvm-001:/kvm# virsh domblklist linux_vm
 Target   Source
---------------------------------
 vda      /kvm/linux_boot
 vdb      /kvm/disco_secundario

Pronto, ao executar os comando de merge, ele sai dessa situação:

E retorna para essa situação:

Podemos ver agora, que as escritas de fatos voltaram para os arquivos “originais”:

Mas, como podemos observar, os arquivos do snapshot ainda continuam no diretório. Nesse caso, por segurança, recomendo movê-los para um diretório temporário e, após algum tempo de validação, deletá-los.

root@kvm-001:/kvm# ls -lrt
total 7177096
drwxr-xr-x 2 root         root       4096 Sep 10 13:54 outras_maquinas
-rw------- 1 libvirt-qemu kvm   575406080 Sep 11 11:16 linux_boot.FILE_STAGE_BACKUP.TEMP
-rw------- 1 libvirt-qemu kvm    68747264 Sep 11 11:16 disco_secundario.FILE_STAGE_BACKUP.TEMP
-rw------- 1 libvirt-qemu kvm  6631194624 Sep 11 11:22 linux_boot
-rw------- 1 libvirt-qemu kvm    73924608 Sep 11 11:22 disco_secundario
root@kvm-001:/kvm# mkdir retencao
root@kvm-001:/kvm# mv linux_boot.FILE_STAGE_BACKUP.TEMP retencao/
root@kvm-001:/kvm# mv disco_secundario.FILE_STAGE_BACKUP.TEMP retencao/
root@kvm-001:/kvm# ls -lrt
total 6548156
drwxr-xr-x 2 root         root       4096 Sep 10 13:54 outras_maquinas
drwxr-xr-x 2 root         root       4096 Sep 11 11:25 retencao
-rw------- 1 libvirt-qemu kvm  6631194624 Sep 11 11:25 linux_boot
-rw------- 1 libvirt-qemu kvm    73924608 Sep 11 11:25 disco_secundario

Pronto, pessoal! Neste artigo descrevi os procedimentos para realizar o backup online de uma VM Linux. No próximo artigo, irei abordar o backup online de máquinas Windows.

Problemas conhecidos:

Existe um bug na estrutura do KVM (em guest VMs Linux). Ao criar um snapshot em máquinas que possuem mais de um disco, pode ocorrer o seguinte erro:

root@kvm-001:/kvm# virsh snapshot-create-as --domain linux_vm --name FILE_STAGE_BACKUP.TEMP --disk-only --atomic --quiesce
error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to open /disco_secundario: Permission denied

Esse erro pode ser contornado conforme a nota Doc ID 3087488.1 com seguinte comando (Comando dentro das guest VMs Linux):

[root@guestvm ~]# setsebool -P virt_qemu_ga_read_nonsecurity_files 1
[root@guestvm ~]# sestatus -b |grep qemu

OLVM: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to open /: Permission denied (Doc ID 3087488.1)

Após a implementação da solução descrita na nota, o comando para criar o snapshot será concluído com sucesso.

Observação: todos esses procedimentos foram testados em ambientes de guest VMs com partições dos tipos XFS e EXT4. Caso a sua guest VM utilize outro sistema de arquivos, recomendo realizar testes exaustivos antes de aplicar em produção.

É isso pessoal, qualquer coisa só me chamar no linkedin 🙂