Como fazer o Backup Proxmox? Proxmox Métodos de Apoio e Recuperação

A criação de backups efetivos é uma prática crítica para quase todas as empresas atualmente, não importa com que tipos de dados e aplicações elas estejam trabalhando. O ambiente virtual Proxmox (VE) não é diferente a esse respeito. Felizmente, o rápido crescimento da popularidade do Proxmox levou a muitas soluções diferentes de backup de terceiros tendo desenvolvido alguma maneira de criar um backup específico do Proxmox, e há também algumas maneiras embutidas de fazer backups.

Métodos de apoio Proxmox incorporados

Em primeiro lugar, é compreensível que os métodos de backup incorporados possam ter limitações e problemas com a personalização. Portanto, e como regra geral, todos os métodos embutidos de backup Proxmox tendem a ser backups completos. Isso, por sua vez, significa que eles vêm com todas as limitações inerentes envolvidas no uso desse nível de backup.

Há duas maneiras principais de iniciar um backup Proxmox incorporado – usando o GUI original ou através do comando específico vzdump na linha de comando. Esses backups também precisam ter um armazenamento de backup em nível de arquivo, e os backups também podem ser programados usando o nível “Datacenter” no GUI.

O Proxmox pode operar tanto com VMs quanto com containers – embora haja algumas diferenças quando se trata de modos de backup diferentes, apesar de haver o mesmo trio de modos tanto para containers quanto para VMs: modo stop, modo suspendido e modo snapshot.

• Stop modo para uma VM é o que proporciona mais consistência entre os três, ao custo de um curto período de inatividade. Como o nome sugere, a VM precisa ser parada antes de executar esse modo de backup.
  A idéia para recipientes é a mesma, mas há um potencial de tempo de parada prolongado.

• Suspend modo para uma VM tenta diminuir o tempo de inatividade potencial não parando completamente a VM inteira, mas o tempo de inatividade ainda é relativamente grande, e a consistência dos dados pode sofrer drasticamente, portanto essa opção não é geralmente recomendada.
  A situação dos contêineres é um pouco diferente, já que esse processo cria uma cópia dos dados do contêiner vivo para um local temporário, suspende o contêiner posteriormente e depois substitui os primeiros arquivos de backup pela cópia do contêiner suspenso. O tempo de inatividade dessa operação é significativamente menor do que no modo de parada, mas requer um espaço livre adicional para guardar a cópia temporária do contêiner.

• Snapshot é provavelmente a opção mais interessante dentre as três, proporcionando a capacidade de criar backups de VM com pouco ou nenhum tempo parado, mas com o risco de um trabalho de backup ser inconsistente. Como os dados são copiados de um VM ativo, há uma possibilidade de copiar alguns arquivos no meio da mudança; é por isso que o snapshot geralmente executa comandos de guest-fsfreeze-freeze e guest-fsfreeze-thaw para tentar mitigar os potenciais problemas de consistência.
  O processo de criar um instantâneo de um contêiner é, em sua maioria, o mesmo, já que o software de backup também suspende as operações dentro de um contêiner específico e depois cria um instantâneo temporário de todo o conteúdo daquele contêiner. A totalidade do conteúdo do contêiner é então arquivada e o próprio instantâneo é apagado em seguida.

O processo de restauração com aparelhos Proxmox embutidos também é relativamente simples – pode ser feito ou através do GUI original ou com a ajuda de dois comandos diferentes:

• qmrestore – para restaurar os VMs.
• pct restore – para restaurar os recipientes.

Um problema potencial com o processo de restauração é que ele pode afetar seriamente seu desempenho geral com VMs/containers, já que não há limite para a quantidade de largura de banda que as operações de restauração podem empreender. Felizmente, esses limites podem ser estabelecidos pelo usuário. Há dois tipos de tais limites: por restauração e por depósito escrito.

por-restauração é tudo uma questão de limitar a largura de banda para uma restauração a partir de um único arquivo de backup, e por-armazenamento escrever limita a quantidade de largura de banda usada no processo de escrita a um armazenamento específico.

Nomes de arquivos e compressão

Algumas das novas versões do vzdump estão codificando tanto o tempo de backup como o tipo de convidado no nome do arquivo. Um exemplo desse tipo de nome de arquivo é apresentado a seguir:

Esse tipo de nomeação permite o armazenamento de vários backups diferentes no mesmo diretório. Há também uma série de opções de retenção disponíveis, que iremos abordar mais tarde.

A compressão de arquivos é outra parte do processo de backup quando se trata de Proxmox. Há três algoritmos de compressão comumente conhecidos: lzo, gzip e zstd. Como está, zstd é atualmente o algoritmo mais rápido dentre os três, já que suporta multithreading. Surpreendentemente, ambos lzo e gzip são freqüentemente as escolhas padrão para muitos casos e são mais comumente usados em geral.

Há também um substituto para gzip disponível chamado pigz, e se vangloria de um melhor desempenho devido à capacidade de usar multithreading. Ambos pigz e zstd, a quantidade de núcleos/threads usados pode ser ajustada manualmente.

Na maioria das vezes é fácil entender que algoritmo de compressão foi usado apenas olhando para a extensão do arquivo de backup.

• .zst – Compressão Zstandard
• .gz ou .tgz – compressão gzip
• .lzo – compressão lzo

Se a extensão do arquivo de reserva não corresponde a nenhum dos exemplos acima – então não foi comprimida por vzdump em primeiro lugar.

Retenção de backups e exemplos

Há uma série de opções diferentes disponíveis quando se trata de retenção de reserva no Proxmox, aqui está a lista de todas elas:

• keep-all <boolean> – Todos os backups são mantidos. Nenhuma outra opção pode ser definida se isso for “true”.
• keep-last <N> – especifica o número de backups que seriam mantidos, contando para trás em relação ao último.
• keep-hourly <N> – especifica o número de horas em que seus reforços seriam mantidos. Se houver mais de uma hora de backup, apenas o backup mais recente será mantido.
• keep-daily <N> – especifica o número de dias em que seus reforços seriam mantidos. Se houver mais de um único backup por um dia, apenas o backup mais recente será mantido.
• keep-weekly <N> – especifica o número de semanas em que seus reforços seriam mantidos. Se houver mais de um único backup durante uma semana, apenas o backup mais recente será mantido.
• keep-monthly <N> – especifica o número de meses em que seus reforços seriam mantidos. Se houver mais de um único backup durante um mês, apenas o backup mais recente será mantido.
• keep-yearly <N> – especifica o número de anos por que seus reforços seriam mantidos. Se houver mais de um único backup durante um ano, apenas o backup mais recente será mantido.

Todas as opções de retenção são processadas nesta ordem, de cima para baixo. Cada uma dessas opções só cobre os backups dentro de seu período de tempo e não cuida dos backups que já eram cobertos pelas opções anteriores. As opções de retenção de sua escolha devem ser especificadas em uma lista separada por vírgulas, como no exemplo abaixo:

Agora vamos rever alguns dos comandos de reserva regulares e suas capacidades adicionais no que diz respeito à configuração

No exemplo acima, estamos criando uma lixeira básica de um hóspede 777 para o diretório de lixeiras padrão, sem qualquer instantâneo.

No exemplo acima, estamos criando um backup do mesmo hóspede usando um instantâneo, o que resulta em um tempo mínimo de inatividade.

No exemplo acima, estamos apoiando todos os nossos sistemas de convidados e enviando e-mails de notificação tanto para os usuários administrativos como para os usuários de raiz.

No exemplo acima, usamos o método de instantâneo com um diretório de despejo personalizado.

No exemplo acima estamos apoiando vários convidados diferentes ao mesmo tempo (101, 102, 103…).

No exemplo acima, estamos apoiando todos os convidados, exceto os especificados (101, 102).

No exemplo acima, estamos restituindo um recipiente a um novo CT 600.

No exemplo acima, estamos restaurando um VM QemuServer como VM 601.

Métodos de backup do Proxmox da Bacula Enterprise

Felizmente, existe uma boa gama de alternativas de terceiros quando se trata de operações de backup e restauração dentro do ambiente virtual do Proxmox. Por exemplo, há o Bacula Enterprise, que é uma solução de backup abrangente, capaz de trabalhar com uma miríade de diferentes tipos de banco de dados/VM, e também tem um módulo Proxmox integrado nativamente.

Surpreendentemente, o Bacula Enterprise também oferece duas formas diferentes de fazer um backup do Proxmox VM, e uma delas nem sequer envolve o módulo Proxmox em primeiro lugar.

O primeiro método envolve a instalação de um Bacula Enterprise File Daemon em cada um dos VMs convidados dos quais o senhor deseja fazer backups. Observe que o senhor terá que programar e priorizar se estiver usando várias VMs com esse método, já que fazer backup de todas elas de uma só vez pode facilmente criar um gargalo para seu subsistema de rede/disco.

Fora isso, a instalação de um Bacula File Daemon permite uma grande escolha de recursos, inclusive verificação de trabalhos, restauração de arquivos individuais, compressão de nível de arquivo, verificação do checksum, e mais.

Como o segundo método de criação de backups Proxmox com a ajuda do módulo Proxmox do Bacula é o mais poderoso, mergulharemos apenas nos detalhes e configurações desse módulo específico.

Apoio Proxmox com a Bacula Enterprise

Três passos principais estão incluídos no processo de criação de um Proxmox VM backup com o Bacula Enterprise:

• Salvamento da configuração da VM convidada.
• Criação de um instantâneo do VM convidado.
• Descarga de dados com a ajuda de vzdump command.

Como o senhor pode ver, o principal modo de backup que a Bacula Enterprise utiliza é o modo Snapshot, permitindo backups consistentes e pouco ou nenhum tempo parado. Os backups de VMs convidados do LXC são armazenados em dois tipos de arquivo – .tar e .conf, enquanto os VMs convidados da QEMU estão usando o tipo de arquivo .vma.

Isso se aplica a apenas uma VM convidada, portanto há necessidade de criar vários trabalhos de backup se for necessário fazer backup de várias VMs Proxmox. O processo em si é amplamente automatizado, criando instantâneos e removendo-os depois de descarregar os dados, portanto é relativamente simples do ponto de vista de um usuário regular.

Proxmox restaurar com Bacula Enterprise

Dois tipos de restauração estão disponíveis quando se trata de Proxmox com Bacula Enterprise. O senhor pode restaurar os dados como um completo Proxmox VM convidado (será restaurado ou com o original vmid com o qual foi feito backup, ou com o novo se o anterior já tiver sido tomado). Tudo que o senhor tem que fazer é usar o parâmetro where= durante o processo de recuperação dos dados do Bacula.

Outra nuança é sobre a vmid do VM convidado restaurado. Se houver necessidade de um VM restaurado ter um novo vmid, ele é escolhido aleatoriamente como um número do mais alto vmid disponível +1…11 acrescentado a esse número. O senhor também pode rever esse processo aleatório com o comando sequencialvmid – dessa maneira seu VM convidado obteria o primeiro número disponível dentro do sistema.

Outra opção de recuperação é restaurar todos os dados em um diretório local. Isso também pode ser feito com um comando semelhante: where=/some/path. Caminhos inexistentes seriam criados automaticamente pelo módulo Proxmox.

Conclusão

O Bacula Enterprise oferece uma gama especialmente ampla de diferentes opções quando se trata de operações de backup e restauração, e seu Proxmox de backup e recuperação não é diferente. O alto nível de personalização resulta em backup especialmente rápido e (mais importante) rápida recuperação dos dados de uma organização. Utilizando sua avançada tecnologia de snapshot e alavancando a flexibilidade do software no processo, o Bacula Enterprise é uma escolha forte para suas necessidades de backup e restauração do Proxmox.