gerenciando backups de vm - role seus próprios ou compre as ferramentas?

4

Somos uma pequena loja que opera mais de uma dúzia de instâncias de VMware em três máquinas host. À medida que adicionamos mais VMs à nossa implantação para nossos clientes, a maneira fragmentada como fizemos backups de nossas VMs tem mostrado suas falhas. Isso ficou especialmente claro quando adicionamos mais máquinas host ao nosso "farm", por assim dizer.

É hora de considerarmos soluções mais robustas para gerenciar nossos backups de VMs. Eu encontrei alguns scripts bacanas no google code para fazer todos os tipos de backup e cópia de VMs para um servidor central ... mas será que isso apenas atrasará o futuro?

Atualmente, estamos usando o vmware server 2.0 e não temos problemas para alternar para o ESX. Como as pessoas fizeram a transição para o ESX e alguns dos pacotes do vSphere para gerenciar suas máquinas virtuais? Suas soluções de backup são muito melhores do que as que um ninja de scripts poderia reunir?

    
por dmyung 15.07.2009 / 17:35

3 respostas

3

Minha versão de "roll it yourself" é algo assim: O script é ótimo, mas o backup também é algo que você quer ter certeza de que é feito corretamente. Se você pode gastar um pouco de dinheiro e conseguir algo que funciona bem, provavelmente é melhor do que gastar muito tempo escrevendo scripts. Também é muito menos provável que você acabe em uma situação em que uma oferta comercial deixe você desatento e perca seus dados. (Você ainda deve testar, testar, testar seus backups mesmo se estiver usando ofertas comerciais.)

Eu fiz minha parte de soluções de cola e fita para fazer backup com rsync, scp, etc, mas um produto comercial vai ser mais limpo para o "próximo cara" a administrar e isso é uma "vitória" para o seu negócios, mesmo que não seja para o seu ego.

Então, tendo dito tudo isso, aqui está o que eu consideraria fazer. Eu daria uma olhada no Veeam Backup antes de você escrever / modificar scripts.

    
por 15.07.2009 / 17:37
3

Qualquer solução que você decida implementar, seja uma solução comprada, o script de outra pessoa ou o seu próprio script ... certifique-se de que funciona!

Teste, teste e teste novamente ... então ... teste-o regularmente (semanalmente, mensalmente, você decide).

O maior problema com backups de VMs (e backups em geral) é que ele funciona primeiro ... então todo mundo se esquece deles até o céu começar a cair.

Se você optar por uma abordagem do tipo "faça você mesmo", faça o DOCUMENTAmento corretamente junto com o PROCEDIMENTO DE RESTAURAÇÃO para que daqui a 6 meses você não esteja sob estresse porque algo está quebrado e batendo com a cabeça contra a parede porque você não consegue lembrar como restaurar essa "bagunça".

O software comercial certamente pode aliviar o fardo de muito isso, mas dependendo da sua situação, você pode precisar de mais configuração. Mas faça o que fizer ... TESTE. ; -)

    
por 15.07.2009 / 18:20
2

Tenha em mente que, para as VMs, existem realmente dois tipos de backups que importam.

O primeiro seria seus backups padrão que são executados na máquina sejam virtuais ou não. Normalmente, eles incluem arquivos de configuração e dados além da instalação básica do sistema operacional.

O segundo é um backup da própria VM. Esse é o complicado. Ele é executado na máquina host VMWare (não na própria VM), copia todo o disco rígido e não requer um cliente na VM. Para garantir a consistência, o backup deve ser feito enquanto a VM está inativa ou, mais comumente, uma captura instantânea é feita, o backup da captura instantânea é excluído e, em seguida, excluído.

O segundo tipo de backup é ideal para situações de recuperação de desastres, já que ele pode colocá-lo em funcionamento muito rapidamente - no entanto, os backups são necessariamente maiores e mais lentos e mais difíceis de configurar. E eles não são bons se você precisar restaurar um único arquivo ou pasta.

Qualquer solução de backup que você consiga realmente precisa considerar esses dois tipos de backups.

    
por 15.07.2009 / 17:48