recomendações para solução de backup remoto off-site eficiente de vm's

Question

Estou procurando recomendações para fazer backup dos meus 6 vms atuais (e em breve aumentar para até 20). Atualmente, estou executando um cluster proxmox de dois nós (que é uma base do Debian usando o kvm para virtualização com um front-end da web customizado para administração). Eu tenho duas caixas quase idênticas com placas-mãe amd phenom II x4 e asus. Cada um tem 4 discos rígidos sata2 de 500 GB, 1 para o sistema operacional e outros dados para a instalação do proxmox, e 3 usando mdadm + drbd + lvm para compartilhar os 1,5 TB de armazenamento entre as duas máquinas. Eu montei imagens lvm para kvm para todas as máquinas virtuais. Atualmente, tenho a capacidade de fazer transferência ao vivo de uma máquina para outra, normalmente em segundos (demora cerca de 2 minutos na maior vm executando o win2008 com o servidor m sql). Estou usando o utilitário vzdump integrado do proxmox para tirar instantâneos dos vm's e armazená-los em um disco rígido externo na rede. Eu, então, tenho o serviço jungledisk (usando rackspace) para sincronizar a pasta vzdump para backup externo remoto.

Tudo isso é bom e elegante, mas não é muito escalável. Por um lado, os próprios backups podem levar até algumas horas todas as noites. Com as transferências incrementais de nível de bloco do jungledisk, a sincronização transfere apenas uma pequena parte dos dados externos, mas isso ainda leva pelo menos meia hora.

A solução muito melhor seria, é claro, algo que me permite instantaneamente tirar a diferença de dois pontos de tempo (digamos o que foi escrito das 6h às 7h), zipar e enviar esse arquivo de diferença para o servidor de backup. transferir para o armazenamento remoto no rackspace. Eu olhei um pouco em zfs e é a capacidade de enviar / receber. Isso acoplado com um tubo de dados no bzip ou algo parecido perfeito. No entanto, parece que implementar um servidor nexenta com zfs exigiria essencialmente pelo menos um ou dois servidores de armazenamento dedicados para servir volumes de bloco iSCSI (via zvol ???) para os servidores proxmox. Eu preferiria manter a configuração o mínimo possível (ou seja, NÃO ter servidores de armazenamento separados), se possível.

Eu também li brevemente sobre zumastor. Parece que também pode fazer o que eu quero, mas parece ter parado o desenvolvimento em 2008.

Então, zfs, zumastor ou outro?

    

Answer 1

Acho que encontrei a resposta final para minha pergunta:

BUP link

Recursos:

• Ele usa um algoritmo de soma de verificação contínua (semelhante ao rsync) para dividir grandes arquivos em pedaços. O resultado mais útil disso é que você pode backup de imagens de disco, bancos de dados e XML de máquinas virtuais enormes (VM) arquivos de forma incremental, mesmo que eles geralmente sejam todos em um enorme arquivo, e não usar toneladas de espaço em disco para várias versões.

  Ele usa o formato packfile do git (o controle de versão de código aberto sistema), para que você possa acessar os dados armazenados mesmo que não goste interface do usuário da bup.

  Ao contrário do git, ele grava arquivos de pacote diretamente (em vez de ter um etapa separada de coleta / reembalagem de lixo), por isso é rápido mesmo quantidades imensamente gratuitas de dados. melhores formatos de índice do bup também permitem que você rastreie muito mais nomes de arquivos que git (milhões) e mantenha rastrear muito mais objetos (centenas ou milhares de gigabytes).

  Os dados são "automagicamente" compartilhados entre backups incrementais sem ter que saber qual backup é baseado em qual outro - mesmo se o backups são feitos de dois computadores diferentes que nem sequer sabem sobre nós. Você acabou de dizer ao bup para voltar as coisas, e isso economiza apenas a quantidade mínima de dados necessária.

  Você pode fazer o backup diretamente em um servidor bup remoto, sem precisar de toneladas de espaço em disco temporário no computador que está sendo copiado. E se o seu backup é interrompido no meio do caminho, a próxima corrida vai pegar de onde você parou. E é fácil configurar um servidor bup: apenas instale o bup em qualquer máquina onde você tenha acesso ssh.

  O Bup pode usar a redundância "par2" para recuperar backups corrompidos, mesmo se seu disco não detectou setores defeituosos.

  Mesmo quando um backup é incremental, você não precisa se preocupar restaurando o backup completo, depois cada um dos incrementais por sua vez; a backup incremental age como se fosse um backup completo, ele leva menos espaço em disco.

  Você pode montar seu repositório bup como um sistema de arquivos FUSE e acessar o conteúdo desse jeito, e até mesmo exportá-lo sobre o Samba.

Edit: (19 de agosto de 2015) E ainda outra ótima solução é ainda melhor: link

Ele permite snapshots ao vivo, essencialmente dando recursos como o COW a qualquer sistema de arquivos antigo regular no Linux.

Editar: (15 de julho de 2016) E até outra ótima solução que sopra fora da água: link

É particularmente melhor que o bup na poda. Parece ter grande suporte para compactação, criptografia e deduplicação eficiente. dattobd + borg ftw !!!

    

Answer 2

Isso pode não ser possível em sua situação, por isso espero não ser rejeitado nesse caso, mas talvez seja mais eficiente alterar sua estratégia de backup. Se você fizer backup de dados específicos em vez de instantâneos de VM, seus backups serão executados muito mais rapidamente e será mais fácil capturar alterações.

Dependendo de suas VMs e para as quais elas são usadas, basta fazer com que façam backup de dados no local onde você armazena os instantâneos diariamente (ou qualquer horário adequado) e, em seguida, o JungleDisk pode fazer backup apenas dos dados. Isso transfere de forma mais eficiente os arquivos alterados, e o espaço necessário para backups e o tempo necessário seriam reduzidos. Além disso, você ainda pode tirar snapshots para reter e fazer isso com menos frequência (semanalmente, por exemplo).

Nesse caso, você pode sempre abrir uma nova VM e restaurar dados ou usar uma captura instantânea mais antiga para restaurar a VM e usar o backup de dados para restaurar o ponto mais recente.

    

Answer 3

Se eu estivesse fazendo backups externos, escolheria as seguintes opções:

(a) script de shell que copia o SCP para o servidor remoto. Dessa forma, você pode adicionar um trabalho cron que executa automaticamente o script que cria o backup. Além disso, você pode fazer com que ele crie um arquivo morto temporário antes de realmente transferir os arquivos, economizando largura de banda ao não transferir enquanto estiver no gziping.

ou

(b) Instale uma ferramenta de gerenciamento de servidor como o Webmin e faça isso para fazer backups automatizados. Atualmente estou cantando isso em meus servidores de produção agora sem problemas. Ele simplesmente funciona perfeitamente. Eu também recomendaria o cloudmin (pago) para gerenciar muitos vms, pois fornece uma solução completa.

alguns links extras:

link

link

Espero que ajude, RayQuang

    

Answer 4

você pode querer dar uma olhada no backuppc.

o backuppc pode funcionar em cima do rsync, que faz cópias incrementais.

mais você pode facilmente escrever uma lista negra de pastas que não precisam ser copiadas. Por exemplo: temp / / tmp .garbages / ...

link

O backuppc tem uma interface web limpa que lhe permite baixar algumas partes de um backup diretamente como um arquivo zip. Ele pode ser monitorado por nagios usando check_backuppc.

    

Answer 5

Não tenho certeza, quanta mudança arquitetônica você estava planejando fazer para aumentar sua escalabilidade. No entanto, se você estivesse aberto para alternar as plataformas de VM, poderia examinar o VMWare.

Existem muitas boas soluções de backup VMWare, eu pessoalmente usei o VzionCore. Você pode então fazer algumas coisas com snapshots e recuperação point-in-time. Existe até uma capacidade de failover para um site remoto.

    

Answer 6

zfs faz muito bem, você já mencionou sabendo que, embora e a desvantagem de não funcionar muito bem na escala de 2 servidores. Ele também não fornecerá o failover de DRDB, ou seja, o Nexenta será um ponto único de falha.

Você pode considerar tentar obter o VirtualBox no OpenSolaris ou no NexentaCore, mas não tão simples quanto o ProxMox + DRDB, para que você possa reutilizar suas máquinas existentes.

Se você medir suas alterações e achá-las baixas o suficiente, você poderia tentar o DRDB com um terceiro local externo - isso só vai funcionar se o número de gravações for extremamente baixo em suas VMs.

Steve Radich - Hospedagem Windows & Desempenho do SQL desde 1995 - link

    

Answer 7

Eu executo um grande cluster proxmox e tenho que sugerir que você mude sua estratégia de backup dos backups embutidos no estilo vzdump, que levam tempo, estão sempre cheios, portanto, grandes em tamanho e fazem a restauração de arquivos individuais extremamente lenta.

Considere uma solução de backup de arquivos 'in guest', da qual há muitos. Backuppc, Urbackup, bacula, amanda etc ...

Será muito mais rápido, consumirá muito menos espaço e será muito mais fácil restaurar arquivos específicos.