Lista de verificação de cópias de segurança de servidor doméstico Proxmox para VMs, LXC e configuração do anfitrião

Uma cópia de segurança bem-sucedida de um convidado Proxmox fica incompleta se os bind mounts, o estado das aplicações, a configuração do anfitrião, as chaves ou o repositório partilharem o mesmo domínio de falha.

Num servidor doméstico que executa VMs e contentores LXC, a recuperação abrange discos dos convidados, dados externos, bases de dados, rede, definições de armazenamento, estado da firewall, mapeamentos de passthrough, credenciais e o processo para reconstruir um anfitrião vazio. Faça o inventário dessas camadas antes de escolher os modos de cópia de segurança, mantenha uma cópia fora do anfitrião e comprove tanto a reposição de um convidado como um processo de recuperação ao nível do anfitrião. Pare de retirar pontos de recuperação antigos quando qualquer um dos testes revelar uma dependência não documentada.

Mapeie cada camada de recuperação e domínio de falha

Faça uma lista de cada VM e LXC, discos virtuais, instantâneos, bind mounts, dispositivos de passthrough, bases de dados das aplicações, partilhas NAS externas, chaves de encriptação e tarefas de cópia de segurança. Em seguida, faça o inventário da rede do anfitrião, das definições de armazenamento, do estado do cluster ou autónomo, das regras da firewall, das tarefas agendadas, das fontes de pacotes e das notas necessárias para recriar os mapeamentos de hardware.

O Proxmox VE pode gravar cópias de segurança de convidados em destinos locais, NFS ou CIFS, enquanto um servidor de cópias de segurança dedicado acrescenta funções de repositório. Um guia independente sobre as opções de destino das cópias de segurança de convidados explica essa separação, mas nenhum dos destinos inclui automaticamente os dados montados num convidado a partir de outro local, nem o registo de reconstrução do anfitrião.

Desenhe os domínios de falha antes de escolher a retenção. Um repositório no mesmo anfitrião, pool, UPS ou com as mesmas credenciais de administrador que a produção é um ponto de recuperação útil, mas não é a cópia independente necessária em caso de perda ou roubo do anfitrião, ransomware ou destruição acidental do pool.

Associe o modo de cópia de segurança a cada carga de trabalho

Classifique os convidados como sem estado, servidor de ficheiros, base de dados transacional ou aplicação mista. Registe se o modo de cópia de segurança produz um estado consistente com a aplicação ou apenas consistente após uma falha, que agente ou hook do convidado participa e que caminhos externos permanecem fora do arquivo.

Utilize o fluxo de trabalho da ZimaSpace para associar os modos de cópia de segurança às cargas de trabalho e escolher o comportamento de paragem, suspensão ou instantâneo de acordo com a carga de trabalho. Uma VM de ambiente de trabalho silenciosa e uma base de dados que aceita escritas não devem herdar a mesma suposição apenas porque ambas as tarefas terminam com êxito.

Para bind mounts de LXC e partilhas montadas no anfitrião, crie cópias de segurança explícitas dos ficheiros ou da aplicação com o mesmo carimbo de data/hora de recuperação quando a consistência o exigir. Se não for possível coordenar o estado necessário, documente a lacuna e utilize uma janela de manutenção, em vez de sugerir que o arquivo do convidado está completo.

Proteja a configuração do anfitrião e o repositório

Exporte um pacote legível de recuperação do anfitrião que contenha interfaces de rede, configuração de armazenamento, definições de VMs e contentores, regras da firewall, ficheiros relevantes do cluster, tarefas agendadas, endpoints do repositório e um inventário de pacotes/versões. Armazene segredos e chaves de encriptação num sistema de credenciais protegido, não numa nota pública de recuperação.

Uma discussão da comunidade Proxmox coloca a questão exata e a configuração do sistema? que fica por proteger depois de configurar os arquivos das VMs e dos contentores. Trate essa questão como um aviso de âmbito: a proteção da configuração do anfitrião é separada da cópia de segurança dos convidados e tem de ser testada como auxílio à reconstrução.

Execute a verificação do repositório, a pré-visualização da retenção e a cópia para fora do anfitrião segundo horários que não possam entrar em conflito com operações de manutenção destrutivas. Emita alertas para tarefas falhadas, falhas de verificação, pressão de capacidade e um repositório inalterado enquanto a produção continua ativa.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Reponha um convidado e ensaie uma reconstrução do anfitrião

Reponha uma VM e um LXC com IDs e redes isolados. Inicie as bases de dados antes das aplicações dependentes, associe os dados copiados dos bind mounts e verifique o início de sessão, o estado dos serviços, os registos recentes, as permissões dos ficheiros e um segundo reinício. Não ligue convidados de teste ao armazenamento de produção com acesso de escrita.

Em seguida, ensaie a recuperação de um anfitrião vazio em hardware sobresselente ou num anfitrião aninhado descartável: instale o hipervisor, restaure deliberadamente as definições de rede e armazenamento, associe o repositório e recupere um convidado crítico. Registe todas as dependências não documentadas e atualize o manual de procedimentos.

A lista de verificação é aprovada quando existem cópias independentes, a verificação está atualizada, as reposições dos convidados funcionam e o anfitrião pode ser reconstruído sem o disco de arranque avariado. Escale a falta de chaves, bases de dados inconsistentes, erros do repositório ou mapeamentos de passthrough que não possam ser reproduzidos antes de retirar qualquer ponto de recuperação antigo.