Como backup de um sistema de arquivos distribuídos?

Question

Nota: Esta é uma questão "teórica", pois ainda não recebi esse tipo de dados.

Se você tiver um sistema de arquivos distribuídos abrangendo uma dúzia ou mais de servidores e TBs de dados, como realizar backups disso? Unidades de fita locais não são uma opção, pois estou alugando o servidor e não tenho acesso físico a elas. Do jeito que eu vejo, eu simplesmente preciso ter um cluster de backup que seja proporcional em tamanho ao cluster de origem. Enviar todos esses dados pela rede em paralelo provavelmente os saturaria, diminuindo o throughput. Mas todos os backups precisam ser feitos ao mesmo tempo, portanto, fazer backups round robin não parece fazer sentido. Uma maneira de contornar esse problema seria apenas reservar uma pequena parte das unidades grandes (no meu caso) e manter o restante para rotacionar instantâneos locais do LVM. Infelizmente, esse tipo de backup seria inútil se o servidor fosse comprometido. Existem outras opções para criar um backup point-in-time que não elimine a rede?

[EDIT] SOLUÇÃO:

1) Replique todo o conjunto de dados em (quase) tempo real para um grande servidor de backup local, para que o uso da largura de banda e IO seja distribuído ao longo do dia e a largura de banda local seja "grátis".

2) Crie o backup real dessa máquina e envie-a para fora do site. Se você tiver todos os dados juntos, será fácil fazer um backup diferencial, o que economiza largura de banda faturável.

    

Answer 1

Se você descobrir que tem mais dados que podem ser copiados na sua janela de backup, precisará analisar a replicação de todos os seus dados fora do site em tempo real ou o mais próximo possível, usando uma infraestrutura separada. (diferentes sub-redes, VLAN, pipe diferente para o trabalho externo etc)

Eu usaria o iSCSI, na verdade especificamente, eu usaria o openfiler para ter meus dados de backend replicados para o mundo externo, além das outras coisas que você pode obter com o openfiler.

Caso contrário, eu usaria localmente o DRDB (assumindo o linux) e o replicaria para alguns outros servidores, e depois executaria meus backups deles.

O melhor conselho que posso oferecer às pessoas é separar seus dados críticos e garantir que eles sejam copiados para um espaço em disco redundante, como uma SAN ou muito menos NAS. Dessa forma, você pode implantar praticamente todos os mecanismos de backup locais que quiser, sabendo que é seguro, porque seus dados críticos são replicados externamente de qualquer maneira. É uma dor, e a gerência pode não concordar a princípio, mas pedir que eles façam os números sobre o quanto a pessoa perderá no tempo de inatividade de uma semana, você verá que seu orçamento aumentará milagrosamente!

    

Answer 2

Então os servidores estão em uma localização conjunta, hmmm ...

1. Eu adicionaria um servidor ao farm na co-localização e ele receberia uma cópia de todos os dados do DFS. Largura de banda é um problema menor, já que é local. Esse servidor pode, então, manipular o processamento de compactação e replicação de dados fora do site.
2. Então eu usaria esse servidor com sua própria largura de banda para replicar para um site secundário. Existem soluções de "backup na nuvem" que apenas replicam as alterações no nível de bits. A largura de banda é conservada pela compactação dos dados enviados. Além de compactar, os dados geralmente são criptografados.

Esta solução está se tornando uma prática mais comum e há um número crescente de fornecedores fornecendo o software de backup e o armazenamento. Lidar com TB para a compra inicial de backup geralmente significa mais poder de barganha.

Esta ideia aplica-se tanto ao Linux como ao Windows. O software específico dependerá mais do seu orçamento e do sistema operacional que você usa.

Outras coisas a considerar. Seu total de dados pode ser de 10 TB. Sua alteração diária nos dados com backups tradicionais pode ser de 200 GB. Mas a alteração no nível de bits pode ser de apenas 30 GB. Se esses dados forem compactados, talvez você consiga chegar a 20 GB. Você precisará conhecer seus dados antes de planejar adequadamente.