Como adequar os modos de cópia de segurança do Proxmox a bases de dados e servidores de ficheiros

Uma cópia de segurança de uma VM Proxmox pode ser consistente após uma falha sem ser consistente ao nível da aplicação. Um servidor de ficheiros pode recuperar corretamente a partir de um instantâneo do sistema de ficheiros, enquanto uma base de dados ocupada pode precisar de hooks de congelamento do guest agent, de um dump da aplicação ou de uma breve paragem para garantir o ponto de restauro esperado.

Escolha o modo com base no contrato de recuperação da carga de trabalho, não numa preferência universal por tempo de inatividade zero. Documente a interrupção aceitável, o método de consistência, o comportamento do armazenamento e o teste de restauro que comprova cada classe. Um registo de trabalho concluído com sucesso é uma evidência útil, mas um restauro isolado da aplicação é o verdadeiro teste de aceitação.

Classifique a carga de trabalho pelo requisito de consistência

Para cada VM, indique a aplicação, a intensidade de escrita, o tempo de inatividade máximo aceitável e o objetivo do ponto de recuperação. Um servidor de ficheiros maioritariamente estático e uma base de dados transacional não devem herdar o mesmo modo apenas por partilharem um nó.

Determine se a aplicação dispõe do seu próprio mecanismo de cópia de segurança ou dump. Uma imagem da VM pode restaurar a máquina, enquanto um dump nativo da base de dados ou uma cópia de segurança dos registos pode fornecer a recuperação ao nível das transações e a verificação de que o serviço necessita.

A documentação de cópias de segurança do Proxmox distingue o comportamento dos modos snapshot, suspend e stop. Utilize essa definição do modo em conjunto com as próprias garantias de consistência da aplicação convidada.

Utilize o modo snapshot para cargas de trabalho com pouco tempo de inatividade

O modo snapshot é normalmente o ponto de partida quando o tempo de inatividade tem de ser mínimo e a pilha de armazenamento o suporta. Instale e ative o QEMU guest agent, quando adequado, para que o processo de cópia de segurança possa coordenar o congelamento e o descongelamento do sistema de ficheiros.

Colocar o sistema de ficheiros num estado quiescente reduz o risco de escritas em curso, mas não cria automaticamente uma cópia de segurança da base de dados verificada transacionalmente. Utilize hooks da base de dados, um dump antes da cópia de segurança, replicação ou outro método com conhecimento da aplicação quando o contrato de recuperação o exigir.

Mantenha os dumps fora de caminhos descartáveis do guest e verifique a sua conclusão antes de iniciar a cópia de segurança da VM. O guia de cópia de segurança da configuração do Immich ilustra por que razão um dump de base de dados gerado só é útil quando a sua consistência e o seu processo de restauro são verificados.

Utilize o modo stop ou suspend quando o compromisso for aceitável

O modo stop proporciona o estado offline mais claro, desligando o guest antes da cópia de segurança e iniciando-o novamente depois. É adequado para serviços pequenos com uma janela de manutenção aceite ou para cargas de trabalho cuja consistência seja difícil de coordenar online.

O modo suspend interrompe a execução, mas pode criar uma interrupção visível mais longa e não substitui uma preparação com conhecimento da aplicação. Meça a pausa real no seu armazenamento e na sua carga de trabalho antes de a atribuir de forma generalizada.

Para um servidor de ficheiros doméstico, o modo snapshot com coordenação do guest agent é muitas vezes suficiente quando os clientes podem repetir os pedidos e o sistema de ficheiros está saudável. Escolha o modo stop quando o serviço for pequeno, a correção tiver prioridade sobre a disponibilidade ou um teste de restauro revelar problemas com a captura online.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Agende e comprove cada classe de cópia de segurança

Crie trabalhos separados ou definições explícitas por VM para as classes de bases de dados, servidores de ficheiros e serviços gerais. Distribua no tempo os guests mais exigentes para que o destino da cópia de segurança e o armazenamento de dados de produção não fiquem saturados ao mesmo tempo.

Depois de cada alteração de modo, restaure para uma rede isolada. Inicie a VM, verifique a integridade do sistema de ficheiros, inicie a aplicação, execute uma verificação de integridade da base de dados ou uma consulta de exemplo e abra ficheiros representativos através do protocolo de serviço normal.

Um trabalho de cópia de segurança concluído com sucesso não é a condição de aprovação. A classe de cópia de segurança só é aprovada quando a recuperação cumpre o requisito documentado de tempo de inatividade e consistência; caso contrário, transfira essa carga de trabalho para um método de preparação mais forte ou para uma janela de paragem.

Perguntas frequentes

O QEMU Guest Agent torna uma cópia de segurança da base de dados consistente ao nível da aplicação? Não por si só. Pode coordenar o congelamento e o descongelamento do sistema de ficheiros, mas a base de dados pode continuar a precisar do seu próprio dump, hook, checkpoint ou integração de snapshot documentada.

Que modo devo utilizar para um pequeno servidor de ficheiros doméstico? Comece pelo modo snapshot e por um guest agent funcional e, em seguida, comprove-o através de um restauro isolado. Utilize o modo stop se o serviço tolerar tempo de inatividade e precisar de um estado offline mais simples.

Posso utilizar modos diferentes no mesmo trabalho de cópia de segurança? Utilize definições explícitas por VM ou trabalhos separados para que cada carga de trabalho siga o seu contrato documentado de consistência e tempo de inatividade.