Visão Geral das Funcionalidades
- Backup online baseado em transações de quaisquer VMs QEMU em execução
- Backup de imagem de disco virtual completo e incremental em nível de blocos
- Recuperação fácil de VM para o cluster original ou alternativo
- Capacidade de restaurar imagens de disco virtual como arquivos QCOW2
- Capacidade de restaurar completamente um convidado VM, incluindo configurações da VM
- Capacidade de restaurar completamente imagens de disco de destino para QEMU genuíno
- Capacidade de restaurar imagens de disco virtual VM para um diretório alternativo
Backup de Imagem com Plugin QEMU
Com a estratégia de backup em nível de imagem, o Plugin Bacula Enterprise QEMU salvará discos de VM como imagens QCOW2 para VMs QEMU, tanto para backups completos quanto incrementais.
Para que isso funcione, não é necessário um Daemon de Arquivo Bacula em cada convidado VM. O Plugin Bacula QEMU entrará em contato com o hipervisor QEMU para ler e salvar o conteúdo dos discos da máquina virtual usando a função de backups de transações QMP e os despejará usando a API QMP.
O Bacula não precisa percorrer os sistemas de arquivos do cliente para iniciar, abrir, ler e fechar arquivos, portanto, ele consome menos recursos na infraestrutura QEMU do que um backup de nível de arquivo em cada VM faria. Por outro lado, o Bacula também lerá e salvará dados inúteis nas VMs, como arquivos swap ou temporários.
Visão Geral do Backup e Restauração
Backup
O Plugin QEMU suporta o protocolo de controle QMP, que é uma interface de gerenciamento de baixo nível para todos os sabores de hipervisores QEMU. Na maioria dos casos, essa interface é usada por ferramentas de gerenciamento de hipervisor para gerenciar convidados VM QEMU.
A versão atual do Plugin foi testada em alguns tipos de hipervisores QEMU:
- QEMU genuíno – modo=QEMU (o padrão)
- Proxmox (PVE) – modo=PVE
- Oracle Virtualization
- KVM
O procedimento central de backup e restauração é o mesmo para cada tipo de hipervisor QEMU. A principal diferença é a maneira como um VM é selecionado para ser restaurado e como o processo de restauração é finalizado.
O backup central de um único convidado VM consiste nos seguintes passos:
- Consultar informações do VM e salvá-las
- Para um nível de backup completo, durante a transação de backup, criar ou limpar o dirtyblock e despejar a imagem do disco VM na área de trabalho (verificar a Localização do Diretório de Trabalho)
- Para um nível de backup incremental, durante a transação de backup, despejar a imagem incremental do disco VM na área de trabalho e limpar o bitmap sujo
- Quando o despejo da imagem do disco VM estiver pronto, o FileDaemon do Bacula enviará os dados para o Storage Daemon.
Os backups podem ser executados apenas para VMs em estado de execução. Qualquer primeiro backup completo criará uma cadeia de backup usada para backups incrementais subsequentes. A versão atual do plugin cria e mantém uma única cadeia de backup para cada VM.
Aviso
Você nunca deve misturar diferentes trabalhos de backup para uma única VM QEMU, pois isso quebrará a cadeia de backup e os backups se tornarão irrecuperáveis!
O Plugin QEMU registrará o início e o fim de cada backup da VM:
JobId 104: Start Backup JobId 104, Job=proxmox.2021-10-28_12.04.54_42 JobId 104: Recycled volume "vol01" JobId 104: Using Device "FileChgr1-Dev2" to write. JobId 104: qemu: Connected to Proxmox pve-manager/6.4-13/9f411e79 (running kernel: 5.4.143-1-pve) JobId 104: qemu: Start Backup vm: vm1 (100) JobId 104: qemu: Finish backup of vm1/drive-scsi0 ...
O backup criará um único arquivo (.qcow2) para cada dispositivo de disco VM salvo e um único arquivo de configuração de VM (config.json) durante um backup completo.
/@qemu/<nome-vm>/<vmid>/<nome-drive>.qcow2 para cada imagem de disco VM /@qemu/<nome-vm>/<vmid>/config.json para dados de configuração da VM
Dica
Para o modo QEMU genuíno, <vmid> geralmente será sempre definido como zero e <nome-vm> é o valor definido pelo parâmetro de execução do QEMU -name na linha de comando do QEMU.
Vários arquivos serão criados durante um backup se várias VMs de convidados forem copiadas com um trabalho (apenas no modo de backup Proxmox). Os nomes distintos de arquivos, conforme mostrado acima, ajudarão a localizar as imagens adequadas dos convidados para a restauração.
Restauração
O Plugin QEMU permite os seguintes destinos para operações de restauração:
- Restauração para um diretório local como arquivos de imagem de disco QCOW2 e um único arquivo de configuração
- Restauração para um hipervisor QEMU Genuíno no local original do arquivo de dispositivo
- Restauração para a infraestrutura de virtualização Proxmox como um VMID original ou novo
- Restauração para um Diretório Local
Para usar esse modo, o parâmetro where=/algum_diretório de uma restauração Bacula é definido como um caminho completo no servidor onde o Plugin QEMU está instalado. Se o caminho não existir, o Plugin QEMU do Bacula o criará. O Bacula irá automaticamente aplicar os backups incrementais nos discos de destino. O resultado final será um arquivo de imagem de disco QCOW2 “pronto para uso”. Para esse tipo de destino, você sempre obterá imagens de disco no formato QCOW2.
Restauração para QEMU Genuíno
Para usar esse modo de restauração, o parâmetro where=/ de uma restauração Bacula é usado. As imagens de disco dos convidados VM serão restauradas e automaticamente patcheadas com todos os backups incrementais no diretório de trabalho (verifique o Local do Diretório de Trabalho para obter detalhes). Em seguida, todos os arquivos de imagem patcheados e prontos para uso serão convertidos de volta para o local de destino original e o formato de imagem quando o parâmetro de plugin de restauração convdestination: yes for definido. Isso permite obter imagens de VMs de convidados do QEMU prontas para serem executadas em seu local original.
Esse modo de restauração é selecionado para todos os backups executados para o QEMU Genuíno.
Restauração para Proxmox
Para usar esse modo de restauração, o parâmetro where=/ de uma restauração Bacula é usado. As imagens de disco das VMs serão restauradas e automaticamente patcheadas com todos os backups incrementais no diretório de trabalho (verifique o Local do Diretório de Trabalho para obter detalhes). Em seguida, todos os arquivos de imagem patcheados e prontos para uso serão transferidos para o armazenamento Proxmox conectado à imagem original.
O Plugin QEMU tentará criar o mesmo VMID que estava durante o backup. Se o convidado VM já existir com esse VMID, o plugin alocará um novo VMID. Ele nunca sobrescreverá um convidado VM existente.
Todos os outros parâmetros de configuração de convidados VM serão restaurados conforme foram copiados, incluindo os endereços MAC de rede. Por esse motivo, é recomendável inspecionar e possivelmente atualizar a configuração da VM antes de iniciá-la. Caso contrário, conflitos de recursos podem surgir.
O alvo de armazenamento a ser usado para os disco(s) de convidado VM restaurados pode ser definido usando a opção de restauração de armazenamento do plugin. Se essa opção não for definida, todos os discos da VM serão restaurados em seu Armazenamento original.
Para listar os Armazenamentos disponíveis, um modo de listagem está disponível, descrito no capítulo de listagem.
Esse modo de restauração é selecionado para todos os backups executados para o Proxmox.
Atenção
O Plugin QEMU não pode ser usado para migração automática de convidados VM QEMU do QEMU Genuíno para uma infraestrutura de virtualização Proxmox, mas você pode realizar uma migração de Proxmox para QEMU Genuíno usando o modo de backup=QEMU para ambos.
Instalação
O File Daemon do Bacula Enterprise e seu Plugin QEMU precisam ser instalados no host do hipervisor Proxmox que executa os convidados VM que serão copiados. O Proxmox usa uma distribuição Debian personalizada, portanto, o File Daemon do Bacula Enterprise para essa plataforma deve ser usado.
A instalação do File Daemon e Plugin Bacula Enterprise QEMU é mais facilmente realizada utilizando o bee_installation_manager: https://www.bacula.lat/automatic-server-installation-with-bacula-enterprise-manager-centos-debian-etc/
Na falta de conexão do cliente com a Internet, os pacotes bacula-enterprise-client, libs/common, e do plugin qemu, podem ser baixados e instalados manutalmente através dos comandos dpkg (família Debian) ou rpm (família RedHat).
Configuração do Plugin
O plugin é configurado usando Parâmetros de Plugin definidos na seção Include de um FileSet na configuração do Diretor do Bacula Enterprise.
Parâmetros Genéricos do Plugin
Os seguintes parâmetros do Plugin QEMU afetam qualquer tipo de Job (Backup, Estimativa ou Restauração).
- abort_on_error[=<0|1>]
especifica se o plugin deve abortar a execução (e falhar o Job do Bacula) se ocorrer um erro fatal durante uma operação de Backup, Estimativa ou Restauração. Esse parâmetro é opcional. O valor padrão é 0. - working=</path/to/dir>
especifica o diretório usado para qualquer operação de backup ou restauração do Plugin QEMU. O valor padrão é o parâmetro de configuração WorkingDir do Bacula FD (verificar Localização do Diretório de Trabalho). Esse parâmetro é opcional.
Parâmetros Genéricos de Estimativa e Backup do QEMU Autêntico
Esses parâmetros do plugin são relevantes apenas para os jobs de Backup e Estimativa:
- qmpcontrol=</path/to/qmp/socket>
especifica o local do socket de controle QMP usado para operações de backup. Quando este parâmetro é definido, isso implica o modo=QEMU. Este parâmetro é obrigatório para o QEMU Autêntico e é configurado automaticamente para outras plataformas de virtualização. Para outras plataformas de virtualização, esse parâmetro é proibido. - mode=[QEMU|PVE]
especifica o tipo padrão de suporte QEMU. Deve ser definido como QEMU para virtualização QEMU Autêntica e PVE para virtualização Proxmox. Quando não definido, o modo de operação QEMU é configurado, o que requer um parâmetro qmpcontrol=… adequado para ser configurado. - timeout=<segundos>
especifica o tempo que o Plugin QEMU aguardará o término de um despejo de imagem. Quando esse tempo limite for atingido, o job falhará. Se não definido, um valor padrão de 3600 segundos será usado. Esse parâmetro é opcional. - bitmap-persistence=[0|1]
especifica se o QEMU deve persistir um mapa de blocos sujos usado para backups incrementais no próprio dispositivo. A persistência do bitmap é suportada apenas nos arquivos de imagem QCOW2. Definir essa opção em dispositivos que não a suportam causará a falha do job de backup. A persistência do bitmap é definida apenas durante o primeiro job de backup Full. Para o Proxmox, esse parâmetro é definido como ‘0’. Esse parâmetro é opcional.
Importante
O bitmap de bloco sujo efêmero (quando bitmap-persistence=0) será recriado a cada reinicialização da VM, forçando um backup VM completo.
- vm=<nome>
especifica o nome de uma VM convidada para backup. Todas as VMs convidadas com o <nome> fornecido serão selecionadas para backup. Múltiplos parâmetros vm=… são permitidos. Se uma VM convidada com <nome> não puder ser encontrada, um erro de job único será gerado e o backup continuará para a próxima VM, a menos que abort_on_error seja definido, o que fará com que o job de backup falhe. Esse parâmetro é opcional e usado apenas quando o modo é PVE. - vmid=<vmid>
especifica o VMID de uma VM convidada para backup. Múltiplos parâmetros vmid=… podem ser fornecidos. Se uma VM convidada com <vmid> não puder ser encontrada, um erro de job será gerado e o backup continuará para a próxima VM, a menos que abort_on_error seja definido, o que fará com que o job de backup falhe. Esse parâmetro é opcional e usado apenas quando o modo é PVE. - include=<nome-regex>
especifica uma lista de nomes de VMs convidadas para backup usando a sintaxe de expressão regular. Todas as VMs convidadas com nomes que correspondam à expressão regular name-regex fornecida serão selecionadas para backup. Múltiplos parâmetros include=… podem ser fornecidos. A correspondência é insensível a maiúsculas e minúsculas. Se nenhuma VM convidada corresponder à expressão name-regex fornecida, o backup continuará para os próximos parâmetros ou terminará com sucesso sem fazer backup de nenhuma VM. O parâmetro abort_on_error não falhará o job quando nenhuma VM convidada for encontrada usando a correspondência de nome. Esse parâmetro é opcional e usado apenas quando o modo é PVE. - exclude=<nome-regex>
especifica uma lista de nomes de VMs convidadas que serão excluídas do backup usando correspondência de expressão regular. Todas as VMs convidadas com nomes que correspondam à expressão regular fornecida e selecionadas para backup usando o parâmetro include=… serão excluídas. A correspondência não é sensível a maiúsculas e minúsculas. Esse parâmetro não afeta nenhuma VM convidada selecionada para backup usando os parâmetros vm=…, vmid=…, include=… ou exclude=…. Múltiplos parâmetros exclude=… podem ser fornecidos. Esse parâmetro é opcional e usado apenas quando o modo é PVE.
Se nenhum dos parâmetros vm=…, vmid=…, include=… e exclude=… for especificado, todas as VMs convidadas disponíveis no hipervisor Proxmox serão incluídas no backup. Para o QEMU Autêntico, uma única VM apontada pelo parâmetro qmpcontrol=… será incluída no backup.
Localização do Diretório de Trabalho
Para realizar qualquer uma das operações de job de backup ou restauração, o Plugin QEMU requer algum espaço de armazenamento disponível. O espaço necessário depende do tamanho do maior arquivo de imagem de disco durante o backup e da soma das imagens de disco da VM durante a restauração. Para as operações de restauração, o espaço é necessário para o patch incremental adequado da imagem.
Essa limitação é uma consequência direta da limitação de backup da unidade QEMU QMP, que suporta arquivos de imagem de disco salvos apenas em um arquivo regular.
A localização exata da área de trabalho pode ser selecionada com o parâmetro de plugin working=…. Quando esse parâmetro não é definido, um valor padrão do parâmetro WorkingDirectory do Bacula será usado.
Esse espaço de armazenamento é automaticamente limpo após a operação, a menos que você selecione uma operação de restauração sem conversão da imagem de disco para o destino (verifique o parâmetro de restauração convdestination).
Exemplos de FileSet
Como mostrado na Figura 1, tanto o FileSet quanto o job de backup do Plugin QEMU podem ser configurados através da interface gráfica do Bacula Enterprise, atualmente o BWeb.
Figura 1. Exemplo ilustrativo FileSet para backup de VM no Bweb.
No exemplo abaixo, uma única VM QEMU será feita backup.
FileSet {
Name = FS_qemu
Include {
Plugin = "qemu: qmpcontrol=/images/vm1.qmp"
}
}
Agora a mesma VM QEMU, mas com localização de trabalho personalizada.
FileSet {
Name = FS_qemu_working
Include {
Plugin = "qemu: qmpcontrol=/images/vm1.qmp working=/tmp"
}
}
No exemplo abaixo, todas as VMs convidadas do Promox serão feitas backup.
FileSet {
Name = FS_ProxmoxAll
Include {
Plugin = "qemu: mode=PVE"
}
}
Neste exemplo, uma única VM com o nome “VM1” será feita backup.
FileSet {
Name = FS_Proxmox_VM1
Include {
Plugin = "qemu: mode=PVE vm=VM1"
}
}
O mesmo exemplo anterior, mas usando vmid em vez disso:
FileSet {
Name = FS_Proxmox_VM1
Include {
Plugin = "qemu: mode=PVE vmid=101"
}
}
No exemplo a seguir, todas as VMs que contêm “Prod” em seus nomes serão feitas backup.
FileSet {
Name = FS_Proxmox_ProdAll
Include {
Plugin = "qemu: mode=PVE include=Prod"
}
}
Neste exemplo final, todas as VMs convidadas, exceto as VMs cujo nome começa com “Test”, serão feitas backup.
FileSet {
Name = FS_Proxmox_AllbutTest
Include {
Plugin = "qemu: mode=PVE include=.* exclude=^Test"
}
}
Parâmetros de Restauração do Plugin
Durante a restauração, o Plugin QEMU usará os mesmos parâmetros que foram definidos para o job de backup. Essas configurações são salvas no catálogo no momento em que o job de backup é executado. Alguns deles podem ser alterados durante o processo de restauração, se necessário.
- convdestination: [yes|no]
especifica se uma imagem de disco restaurada deve ser convertida para o formato e localização originais, conforme definido durante o backup. Esse parâmetro funciona apenas no modo QEMU Autêntico. Se não definido ou definido como no (o padrão), as imagens de disco virtual do QEMU estarão disponíveis no local de trabalho (consulte o próximo parâmetro) como arquivos no formato QCOW2. Nesse caso, você pode movê-lo manualmente para o destino necessário ou convertê-lo para o formato desejado. Esse parâmetro é opcional. - working: </path/to/dir>
especifica o diretório usado para operações de restauração do Plugin QEMU, conforme descrito em Localização do Diretório de Trabalho. O valor padrão é o mesmo que o de backup e pode ser definido pela configuração do plugin ou pelo parâmetro de configuração WorkingDir do Bacula FD. Esse parâmetro é opcional. - storage: <storage>
especifica um Armazenamento Proxmox para o qual as VMs convidadas restauradas serão restauradas. Se não for definido, uma VM convidada será restaurada no Armazenamento Proxmox do qual foi feito o backup. Se esse parâmetro apontar para um Armazenamento inexistente, o Armazenamento original da VM convidada será usado. Esse parâmetro é opcional.
Exemplos Práticos de Restauração
Como mostrado na Figura 2, todos os jobs de restauração podem ser executados através da interface gráfica do Bacula Enterprise, atualmente o BWeb, pelo Dashboard de VMs ou do Menu Restore, ou através dos comandos CLI arrolados mais adiante.
Figura 2. Exemplo de Restore de VMs pelo Bweb, “VM Dashboard”.
Restauração com o QEMU Genuíno
Para restaurar uma VM ou VMs usando o modo Verdadeiro QEMU, você deve executar o comando de restauração e especificar o parâmetro “where” como neste exemplo:
* restore where=/
e, em seguida, definir quaisquer outros parâmetros de restauração necessários para o plugin de restauração.
No exemplo a seguir de sessão de restauração, a opção de restauração do plugin “convdestination” é definida como “sim”:
* restore where=/ ... Run Restore job JobName: RestoreFiles Bootstrap: /opt/bacula/working/qemu-test-dir.restore.2.bsr Where: / Replace: Always FileSet: Full Set Backup Client: qemu-test-fd Restore Client: qemu-test-fd Storage: File1 When: 2021-11-01 13:19:16 Catalog: MyCatalog Priority: 10 Plugin Options: *None* OK to run? (yes/mod/no): mod Parameters to modify: 1: Level 2: Storage 3: Job 4: FileSet 5: Restore Client 6: When 7: Priority 8: Bootstrap 9: Where 10: File Relocation 11: Replace 12: JobId 13: Plugin Options Select parameter to modify (1-13): 13 Automatically selected : qemu: qmpcontrol=/images/vm1.qmp abort_on_error Plugin Restore Options Option Current Value Default Value working: *None* (*None*) convdestination: *None* (*None*) Use above plugin configuration? (yes/mod/no): mod You have the following choices: 1: working (Plugin working directory) 2: convdestination (Convert qcow2 restore to original destination) Select parameter to modify (1-2): 2 Please enter a value for convdestination: yes Plugin Restore Options Option Current Value Default Value working: *None* (*None*) convdestination: yes (*None*) Use above plugin configuration? (yes/mod/no): yes ...
Durante um trabalho de restauração, você deve obter informações sobre cada processo de restauração, incluindo o incremento de dispositivos de disco restaurados e o processo de conversão de destino.
JobId 121: Start Restore Job RestoreFiles.2021-11-01_13.05.11_03 JobId 121: Restoring files from JobId(s) 115,116,120 JobId 121: Using Device "FileChgr1-Dev1" to read. JobId 121: qemu: VM to restore: VM1 (oid:0) JobId 121: qemu: Start Restore vm: VM1 (rid:0) devices: 2 JobId 121: qemu: Restoring device: ide0-hd0 JobId 121: qemu: Restoring device: ide0-hd1 JobId 121: qemu: Patching incremental: ide0-hd0 JobId 121: qemu: Patching incremental: ide0-hd1 JobId 121: qemu: Patching incremental: ide0-hd0 JobId 121: qemu: Patching incremental: ide0-hd1
A nova VM de hóspede criada durante a restauração receberá um novo VMID (se o VMID original estiver em uso), mas o nome / nome do host permanecerá o mesmo que era com a VM original.
Restauração para um Hypervisor Proxmox
Para restaurar uma VM ou VMs para um hypervisor Proxmox, você deve executar o mesmo comando de restauração acima, e o processo básico de restauração é o mesmo. A principal diferença está na configuração final e no procedimento de importação de dispositivos, conforme mostrado abaixo:
JobId 117: Start Restore Job RestoreFiles.2021-11-02_17.26.25_07 JobId 117: Restoring files from JobId(s) 104,105,106,115,116 JobId 117: Using Device "FileChgr1-Dev2" to read. JobId 117: qemu: VM to restore: vm1 (oid:100) JobId 117: qemu: Start Restore vm: vm1 (rid:104) devices: 1 JobId 117: qemu: Restoring device: drive-scsi0 JobId 117: qemu: Patching incremental: drive-scsi0 JobId 117: qemu: Patching incremental: drive-scsi0 JobId 117: qemu: Patching incremental: drive-scsi0 JobId 117: qemu: Patching incremental: drive-scsi0 JobId 117: Elapsed time=00:06:42, Transfer rate=20.28 M Bytes/second JobId 117: qemu: Successfully imported device drive-scsi0 as local-lvm:vm-104-disk-0 ...
A nova VM criada durante a restauração receberá um novo VMID (se o VMID original estiver em uso), mas o nome / nome do host permanecerá o mesmo que era com a VM original.
Restauração para um Diretório Local
É possível restaurar a(s) imagem(s) de disco da VM de hóspede para um diretório local em vez de restaurá-las para um hypervisor como uma nova VM. Para fazer isso, a opção de restauração “where” deve apontar para um diretório local:
* restore where=/tmp/bacula/restores
Confira o seguinte exemplo para o teste “Restauração local da VM”:
JobId 118: Start Restore Job RestoreFiles.2021-11-02_17.37.34_09 JobId 118: Restoring files from JobId(s) 104,105,106,115,116 JobId 118: Using Device "FileChgr1-Dev1" to read. JobId 118: Ready to read from volume "vol01" on File device "FileChgr1-Dev1" (/opt/bacula/archive). JobId 118: qemu: VM local restore: vm1 (oid:100) JobId 118: Forward spacing Volume "vol01" to addr=227 JobId 118: qemu: Restoring device: drive-scsi0 JobId 118: qemu: Patching incremental: drive-scsi0 JobId 118: qemu: Patching incremental: drive-scsi0 JobId 118: qemu: Patching incremental: drive-scsi0 JobId 118: qemu: Patching incremental: drive-scsi0 JobId 118: Elapsed time=00:06:57, Transfer rate=19.55 M Bytes/second ...
O log do trabalho de restauração mostrará que a restauração foi feita para um diretório local.
Outros
Listagem de Recursos
O Plugin QEMU da Bacula Enterprise suporta o recurso de listagem de plugin da Bacula Enterprise 8.x ou posterior. Esse modo permite que um plugin exiba informações úteis sobre os recursos Proxmox disponíveis, como:
- Lista de nomes de VMs de hóspedes
- Lista de VMIDs de hóspedes
- Lista de Armazenamentos Proxmox
Esse recurso usa o “comando de ponto” .ls especial com o parâmetro “plugin=”. O comando requer os seguintes parâmetros a serem definidos:
- client=
Um nome de Cliente Bacula com o Plugin QEMU instalado. - plugin=
Um nome de plugin, que seria “qemu:” neste caso, com parâmetros opcionais de plugin conforme descrito na seção “genericparameters”. - path=
Um caminho de objeto a ser exibido.
Os valores suportados para o parâmetro “path=” são:
- /
para exibir tipos de objetos disponíveis para listagem. - vm
para exibir uma lista de nomes de etiquetas de VMs de hóspedes. - vmid
para exibir uma lista de VMIDs de hóspedes e ponteiros de etiquetas de nome. - storage
para mostrar a lista de Armazenamentos disponíveis.
Para exibir os tipos de objeto disponíveis, siga o exemplo de comando a seguir:
*.ls client=proxmoxtest-fd plugin="qemu: mode=PVE" path=/ Connecting to Client proxmoxtest-fd at proxmoxtest:9102 drwxr-x--- 1 root root 0 2021-11-01 12:55:55 vm drwxr-x--- 1 root root 0 2021-11-01 12:55:55 vmid drwxr-x--- 1 root root 0 2021-11-01 12:55:55 storage 2000 OK estimate files=3 bytes=0
Para exibir a lista de todas as VMs disponíveis, o exemplo de comando a seguir pode ser usado:
*.ls client=proxmoxtest-fd plugin="qemu: mode=PVE" path=/vm Connecting to Client proxmoxtest-fd at proxmoxtest:9102 -rw-r----- 1 root root 8589934592 2021-11-01 12:56:18 vm1 -rw-r----- 1 root root 8589934592 2021-11-01 12:56:18 vm3 2000 OK estimate files=2 bytes=17,179,869,184
Para exibir a lista de VMIDs de hóspedes, use o exemplo de comando a seguir:
*.ls client=proxmoxtest-fd plugin="qemu: mode=PVE" path=/vmid Connecting to Client proxmoxtest-fd at proxmoxtest:9102 -rw-r----- 1 root root 8589934592 2021-11-01 12:56:46 100 -> vm1 -rw-r----- 1 root root 8589934592 2021-11-01 12:56:46 102 -> vm3 2000 OK estimate files=2 bytes=17,179,869,184
As listas de VM e VMID exibem um tamanho estimado da VM de hóspede com base nos tamanhos de imagens de disco virtuais ou reais.
Para exibir os Armazenamentos Proxmox disponíveis, o exemplo de comando a seguir pode ser usado:
*.ls client=proxmoxtest-fd plugin="qemu: mode=PVE" path=/storage Connecting to Client proxmoxtest-fd at proxmoxtest:9102 brw-r----- 1 root root 0 2021-11-01 12:57:56 data brw-r----- 1 root root 0 2021-11-01 12:57:56 local-lvm 2000 OK estimate files=2 bytes=0
Consulta de Recursos
O Plugin QEMU da Bacula Enterprise suporta o recurso de consulta de plugin da Bacula Enterprise 14.0 ou posterior. Esse modo permite que um plugin exiba as mesmas informações sobre os recursos Proxmox disponíveis que são definidas na listagem de recursos. O Plugin QEMU retorna dados de resposta no formato JSON.
Neste exemplo, há uma consulta sobre as VMs disponíveis:
*.query client=proxmoxtest-fd plugin="qemu: mode=PVE" parameter=vm
[{"name":"vm1","vmid":100},{"name":"vm3","vmid":102}]
*.query client=proxmoxtest-fd plugin="qemu: mode=PVE" parameter=vmid
[{"name":"vm3","vmid":102},{"name":"vm1","vmid":100}]
Neste exemplo, há uma consulta sobre os armazenamentos Proxmox disponíveis:
*.query client=proxmoxtest-fd plugin="qemu: mode=PVE" parameter=storage
[{"name":"local"},{"name":"local-lvm"}]
Limitações
- Não é possível executar o mesmo trabalho de backup da mesma VM de hóspede simultaneamente (trabalho duplicado).
- Não é possível ter trabalhos de backup diferentes que fazem backup da mesma VM de hóspede, pois isso quebrará a cadeia de backup de mapa de bits sujo incremental. Nesse caso, uma recuperação bem-sucedida sequer será possível.
- Os modelos de VM disponíveis no sistema Proxmox não podem ser salvos. Isso é uma limitação do Proxmox.
- No modo de listagem e consulta com os parâmetros vm ou vmid, o plugin exibirá apenas as VMs em execução.
- Toda operação de backup ou restauração de VM requer espaço de armazenamento suficiente no diretório de trabalho (verifique a Localização do Diretório de Trabalho). Isso é uma limitação geral do procedimento de backup QEMU QMP.
Referências
- QEMU plugin (Bacula System SA)
