Confiabilidade do instantâneo da VM?

Question

Pergunta rápida sobre backups de captura instantânea. Eu tenho um projeto de hobby em casa onde eu tenho um webapp conectado a um postgresdb em uma VM. Eu quero uma maneira simples de fazer backups, então eu escrevi um script que interrompe o serviço postgres, captura instantaneamente a VM e, em seguida, inicia o serviço novamente. Eu sei que o webapp não funciona durante este período que é esperado, mas ainda tem as seguintes perguntas:

1) Além de instalar algum tipo de agente para gerenciar o banco de dados para backups, essa é uma maneira razoável de fazer backup do sistema de maneira confiável?

2) Há algum problema que eu deva conhecer ao usar um método como esse?

Editar: Eu tenho um software que, em seguida, tira o instantâneo e armazena-lo fora dos dispositivos, armazena os últimos vários, e eu verifiquei o instantâneo volta em um ambiente diferente vCenter.

    

Answer 1

Como ChrisInEdmonton apontou, o que você está fazendo é fazer snapshots, não fazer o backup.

Um backup implica algum tipo de armazenamento secundário. Isso pode ser tudo, desde disquetes ou pendrives USB, até um segundo disco rígido (geralmente externo), fita magnética, a qualquer outra coisa. Um backup é frequentemente armazenado em um local fisicamente distinto dos dados que estão sendo armazenados em backup, para proteger contra falhas de "modo comum" (falhas em que uma causa raiz afeta vários dispositivos, como um pico de energia tirando tanto o original quanto o backup).

Além disso, seu esquema tem um problema potencialmente sério.

Você está capturando instantaneamente uma VM em execução. Dependendo do sistema operacional e do software do utilitário (dentro da VM) envolvidos, isso não é garantido de forma alguma a produzir uma imagem internamente consistente.

Basicamente, o que você está fazendo é o mesmo que se você parasse o servidor de banco de dados em um host físico, desligasse à força o host, removesse o disco rígido e chamasse um backup. Acho que podemos concordar que este não é um ótimo esquema de backup.

Parar o software do servidor de banco de dados é um bom primeiro passo, mas não garante de modo algum que todos os caches no nível do sistema operacional tenham sido liberados para armazenamento persistente (do ponto de vista do sistema operacional dentro da VM) .

O PostgreSQL vem com um utilitário pg_dump , que despeja o banco de dados em um SQL script que pode ser enviado de volta ao PostgreSQL para reconstruir o banco de dados. (Certifique-se de verificar a página man para que você obtenha todas as opções relevantes corretas, e como com todos os backups, teste-a!) Isso é conveniente, mas não necessariamente 100% consistente . Dependendo das suas necessidades, isso pode ser bom o suficiente.

Alternativamente, você pode parar o servidor PostgreSQL (isso garante que não há transações em andamento) e copiar seus arquivos de dados para um local separado que é servido por uma instância diferente do PostgreSQL. Inicie ambos e execute o pg_dump na segunda instância. Depois que o dump for concluído, pare a segunda instância. Isso é mais complexo, mas praticamente garante que você obtenha um despejo internamente consistente sem depender do formato de arquivo de dados do PostgreSQL que permanece inalterado. Se o banco de dados for grande, deve ser possível copiar a maioria dos arquivos enquanto o PostgreSQL ainda está em execução e executar algo como o rsync após parar o PostgreSQL para transferir o delta, para reduzir o tempo de inatividade.

O restante da VM pode sofrer backup usando meios normais, desconsiderando o fato de ser uma VM. Se você estiver mantendo todos os dados voláteis em um disco virtual separado, pode até ser possível configurar a maior parte do sistema para a montagem do sistema de arquivos somente leitura, o que significa que uma cópia simples do arquivo de imagem de disco virtual de fora da VM pode ser executada com resultados razoáveis, mesmo enquanto a VM estiver em execução.