Como você faz backup de um servidor de armazenamento?

Question

Estou pensando em implementar um servidor de armazenamento muito grande para ser usado como NAS ativo para vários outros servidores (todos baseados em Linux).

Por muito grande, quero dizer entre o espaço utilizável de 4TB e 20TB (embora seja improvável que realmente fiquemos 20TB).

O servidor de armazenamento será o RAID 10 para segurança e desempenho de dados, mas ainda precisaremos de uma solução de backup, incluindo backup fora do local.

Minha pergunta é: Como você faz o backup de tantos dados?

Não é como se eu pudesse simplesmente conectar um disco rígido portátil e transferir os arquivos. Atualmente, não temos outros dispositivos com muito espaço de armazenamento.

Preciso fazer orçamento para um segundo servidor de armazenamento externo ou há uma solução melhor?

    

Answer 1

Existem várias maneiras de manipular dados desse tamanho. Muito disso depende do seu ambiente e quanto dinheiro você está disposto a gastar. Em geral, existem algumas estratégias gerais de 'tire os dados do servidor':

• Over the Ethernet Como diz na caixa, os dados são transmitidos para o Some Where Else para manipulação. 20 TB levará muito tempo para copiar mais de 1 GbE, mas isso pode ser feito. O hardware pode ajudar (como links 10GbE ou, em alguns casos, ligação NIC).
• Sobre o subsistema de armazenamento Se você estiver no Fibre Channel, envie-o para outro dispositivo na rede FC. Se você tiver o SAS, envie-o para um dispositivo conectado ao SAS. Geralmente mais rápido que a Ethernet.
• Envie para outra matriz de disco Envie para outro bloco de armazenamento anexado ao mesmo servidor.

Essa é a visualização de 100 km. Depois de começar a ampliar, as coisas ficam muito mais fragmentadas. Como já mencionado, o LTO5 é uma tecnologia de fita específica projetada para esses tipos de cargas de alta densidade. Outro storage array idêntico é um bom alvo, especialmente se você puder usar algo como o GlusterFS ou o DRBD para obter os dados por lá. Além disso, se você precisar de um backup rotação ou apenas a capacidade de continuar em execução no caso da matriz falhar afetará o que você colocar no lugar.

Depois de estabelecer um método de exibição de 100 km, entrar no software será a próxima grande tarefa. Fatores que influenciam isso são o que você pode instalar no seu servidor de armazenamento (se é um NetApp, uma coisa, um servidor Linux com um monte de armazenamento é outra coisa, assim como um servidor Windows com um monte de armazenamento) , qual hardware você escolhe (nem todos os pacotes de backup FOSS tratam bem as bibliotecas de fitas, por exemplo) e que tipo de retenção de backup você precisa.

Você realmente precisa descobrir que tipo de recuperação de desastre você deseja. A replicação ao vivo simples é mais fácil, mas não permite que você restaure a partir da última semana apenas agora. Se a capacidade de restaurar a partir da semana passada é importante para você, então você precisa projetar para esse tipo de coisa. Por lei (nos EUA e em outros países), alguns dados precisam ser preservados por mais de sete anos.

A replicação simples é a mais fácil de fazer. Isso é o que o DRBD foi projetado para fazer. Depois que a cópia inicial é feita, apenas envia alterações. Os fatores complicadores aqui são a localidade da rede, se a sua segunda matriz não estiver próxima do DRBD principal pode não ser viável. Você precisará de um segundo servidor de armazenamento com pelo menos o mesmo espaço de armazenamento que o primeiro.

Sobre backup em fita ...

O LTO5 pode conter 1,5 TB de dados sem compressão. Alimentar esses monstros requer uma rede muito rápida, que é Fibre Channel ou 6Gb SAS. Uma vez que você precisa fazer backup de mais de 1,5 TB em uma pancada, você precisa procurar em autoloaders (aqui está um exemplo: link , um autoloader de 1 unidade com 24 slots da HP). Com o software que os suporta, eles lidam com a alteração de fitas no meio de backup para você. Êles são ótimos. Você ainda terá que retirar as fitas para enviá-las para fora do local, mas isso é uma visão muito melhor do que ficar por aí a noite toda para carregar as fitas quando o backup ligar para elas.

Se a fita lhe der os heebiegeebies ' legado, ew ', uma Virtual Tape Library pode ser mais sua velocidade (como essa da Quantum: link ). Estes fingem ser bibliotecas de fita para software de backup enquanto na verdade armazenam coisas em disco com robustas (você espera) técnicas de desduplicação. Os mais sofisticados até copiarão fitas virtuais para fitas reais para você, se você gosta desse tipo de coisa, o que pode ser muito útil para rotações fora do local.

Se você não quiser mexer nas fitas virtuais, mas ainda quiser fazer backups diretos em disco, você precisará de um storage array grande o suficiente para lidar com esses 20TB, além da quantidade de net-change. dados que você deseja manter. Diferentes pacotes de backup lidam com isso de maneira diferente. Algumas tecnologias de desduplicação são realmente boas, outras são hack kludges. Eu pessoalmente não conheço o estado dos pacotes de software de backup FOSS nesta área (já ouvi falar do Bacula), mas eles podem ser suficientes. Muitos dos pacotes de backup comerciais têm agentes locais que você instala em servidores para fazer backup, a fim de aumentar o rendimento, o que tem muitos méritos.

    

Answer 2

jukebox LTO-5? você precisaria de algo entre três e 15 fitas para fazer o backup, que não é um número loucamente grande. A jukebox cuidará de alterar as fitas para você, e um bom software de backup (por exemplo, bacula) manterá o controle de quais arquivos estão em qual fita.

Você também vai querer considerar o tempo necessário para fazer o backup de um sistema de arquivos tão grande, pois é muito provável que o FS mude durante esse período. Para obter melhores resultados, um sistema de arquivos que suporte snapshots seria muito útil, para que você possa fazer um instantâneo instantâneo e executar backups completos ou incrementais, em vez de usar o sistema de arquivos ao vivo.

    

Answer 3

Provavelmente você deveria estar pesquisando o backup para o disco , já que a fita demorará muito tempo e, com acesso sequencial, as restaurações levarão uma eternidade.

Use os backups differential ou incremental apenas para fazer backup de alterações, em qualquer frequência que faça sentido para você.

Provavelmente, a solução ideal teria um segundo servidor de tamanho similar em outro local , onde backups incrementais são enviados regularmente e que poderiam ser trocados rapidamente se o servidor principal morresse. No entanto, outra opção seria usar unidades removíveis no local, que são então levadas para fora do local para armazenamento.

Quando você está lidando com muitos dados, também faz sentido dividir seus backups em tarefas de backup menores, e se eles não puderem ser salvos em backup todos os dias, escalonem seus backups assim, o conjunto A recebe um backup em um dia e define B no seguinte.

Sempre pense no procedimento de restauração . Ficamos magoados quando tivemos que restaurar um arquivo de um trabalho de backup de várias centenas de gigabytes, o que demandou muita memória e muito tempo para reconstruir o índice de backup e a restauração. No final, não conseguimos concluí-lo em um dia e tivemos que criar um servidor de restauração dedicado para permitir que nosso servidor de backup principal continuasse seus trabalhos noturnos!

- adicionado -

Você também quer pensar em tecnologias de desduplicação , que podem economizar grandes quantidades de espaço ao não fazer o backup das mesmas informações várias vezes, para vários usuários. Muitas soluções de backup ou sistemas de arquivos oferecem deduplicação como parte de sua funcionalidade.

    

Answer 4

Primeiro, enumere os riscos contra os quais você está protegendo. Alguns riscos comuns:

• Desastre: algo muito lamentável acontece em todo o seu site.
• Erros humanos (este é o que acontece _toda_a_hora_):
  • Alguém decide exercer a capacidade de "hot-swap" do seu servidor de armazenamento de uma forma não planejada pelo fabricante.
  • Alguém executa um processo que corrompe silenciosamente os dados, cujo backup é feito com segurança por alguns meses antes que o problema seja percebido.
  • Alguém exclui o relatório importante que deve ser entregue em uma hora e vale milhares de dólares.

Em seguida, avalie o custo das várias soluções para evitar riscos, por exemplo:

• Backup off-site on-line (espelho remoto): Seguro de desastre, algum (mas não todo) erro humano (ainda está on-line).
• Armazenamento off-line off-line (fitas): Seguro contra desastres, difícil de recuperar dados rapidamente.
• Backup on-line on-line (espelho): Seguro contra algum erro humano, alguma falha de hardware, vulnerável a desastres.
• Backup off-line no local (fitas no trocador de fita): Seguro contra a maioria dos erros humanos, a maioria das falhas de hardware.

Em seguida, avalie as estratégias de rotação (quanto tempo você deseja recuperar, quantos dados você pode perder).

Em seguida, escolha o valor dos seus dados.

    

Answer 5

Tenho um cliente com dois sistemas semelhantes de 12 TB em dois prédios diferentes, conectados a 1 GB. Um é o sistema de produção; é feito um backup incremental (com snapshots diários) para o outro com o grande utilitário rdiff-backup . O rdiff-backup deve estar disponível em seu repositório de distribuição padrão.

    

Answer 6

Backup off-site e on-line (espelho remoto)

use o rsync embora ssh (apenas alterações) - o primeiro backup deve ser feito localmente, mas após esse backup será uma brisa dependendo das alterações

se você precisa manter as versões com alterações-rdiff-backup

link

O sistema de arquivos btrfs no Linux parece promissor, mas ainda em desenvolvimento pesado

    

Answer 7

Veja seu "conteúdo" real e com que frequência ele muda antes de planejar sua estratégia. Muitas vezes as pessoas apenas agitam os mesmos dados para gravar semanalmente repetidas vezes sem um bom motivo.

As tecnologias de deduplicação de alguns fornecedores podem permitir que o instantâneo o salve de restaurações de arquivos individuais, mas você sempre precisará de proteção externa fora do local.