Como você faz backup de um servidor de armazenamento?

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 4TB e 20TB de espaço útil (embora seja improvável que a gente consiga 20TB).

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

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

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

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

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

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

Essa é a visão de 100 km. Quando você começa a aumentar o zoom, 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. Outra matriz de armazenamento idêntica é um bom alvo, especialmente se você pode usar algo como GlusterFS ou DRBD para obter os dados por lá. Além disso, se você precisar de uma rotação de backup ou apenas a capacidade de continuar executando, caso a matriz falhe, isso afetará o que você implementou.

Depois de escolher um método de visualização de 100 km, entrar no software será a próxima grande tarefa. Fatores que influenciam isso são o que você pode instalar em seu servidor de armazenamento em primeiro lugar (se é um NetApp, uma coisa, um servidor Linux com um monte de armazenamento é outra coisa completamente diferente, assim como um servidor Windows com um monte de armazenamento) , qual hardware você escolhe (nem todos os pacotes de backup do FOSS lidam bem com 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 deseja. A replicação ao vivo simples é mais fácil, mas não permite que você restaure da semana passada apenas agora. Se a capacidade de restaurar a partir da semana passada é importante para você, é necessário projetar para esse tipo de coisa. Por lei (nos EUA e em outros lugares) alguns dados precisam ser preservados por mais de 7 anos.

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

Sobre o backup em fita ...

O LTO5 pode conter 1,5 TB de dados sem compactação. A alimentação desses monstros requer uma rede muito rápida, que é Fibre Channel ou SAS de 6 GB. Como você precisa fazer backup de mais de 1,5 TB em um whack, é necessário pesquisar em carregadores automáticos (eis um exemplo: link , um carregador automático de 1 slot de 24 slots da HP). Com o software que os suporta, eles cuidam da troca de fitas no meio do backup para você. Êles são ótimos. Você ainda terá que retirar as fitas para enviá-las para fora do local, mas é uma visão muito melhor do que ficar andando a noite toda para carregar as fitas quando o backup pedir por elas.

Se a fita fornecer os itens ' legados, ew ', uma Biblioteca de fitas virtuais poderá ter mais velocidade (como a Quantum: link ). Eles fingem ser bibliotecas de fita para fazer backup de software e, na verdade, armazenam coisas em disco com técnicas robustas de desduplicação (você espera). Os mais extravagantes até copiarão fitas virtuais para fitas reais para você, se você gosta desse tipo de coisa, que pode ser muito útil para rotações fora do local.

Se você não quiser mexer nem com fitas virtuais, mas ainda quiser fazer backups diretos em disco, precisará de uma matriz de armazenamento grande o suficiente para lidar com esses 20 TB, além de quantos dados de alteração de rede desejar para manter um porão. Pacotes de backup diferentes lidam com isso de maneira diferente. Algumas tecnologias de desduplicação são realmente legais, outras são cláusulas hacky. Pessoalmente, não conheço o estado dos pacotes de software de backup FOSS nessa área (ouvi falar do Bacula), mas eles podem ser suficientes. Muitos pacotes de backup comercial têm agentes locais que você instala em servidores para backup, a fim de aumentar a taxa de transferência, que tem muitos méritos.

Jukebox LTO-5? você precisaria de três a 15 fitas para fazer backup dessa matriz, o que não é um número loucamente grande. A jukebox cuidará da troca das fitas para você, e um bom software de backup (por exemplo, bacula) acompanhará quais arquivos estão em cada fita.

Você também deve considerar o tempo necessário para fazer 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 instantâneos seria muito útil, portanto, você pode tirar um instantâneo instantâneo e executar backups completos ou incrementais contra isso, em vez de contra o sistema de arquivos ativo.

Provavelmente, você deve fazer backup no disco , pois a fita levará muito tempo e, sendo o acesso seqüencial, as restaurações levarão uma eternidade.

Definitivamente, aproveite os backups diferenciais ou incrementais - apenas faça o backup das alterações, em qualquer frequência que faça sentido para você.

Provavelmente, a solução ideal teria um segundo servidor de tamanho semelhante em outro local , onde os 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 retiradas do local para armazenamento.

Quando você lida com tantos dados, também faz sentido dividir seus backups em tarefas de backup menores e, se não puderem fazer backup todos os dias, escalonar seus backups para que o conjunto A faça backup um dia e defina B no próximo.

Sempre esteja pensando no procedimento de restauração . Fomos atingidos uma vez quando tivemos que restaurar um arquivo a partir de um trabalho de backup de várias centenas de gig, o que levou muita memória e muito tempo para recriar o índice de backup e restaurar. No final, não foi possível concluí-lo em um dia e tivemos que criar um servidor de restauração dedicado para permitir que nosso servidor de backup principal continuasse com seus trabalhos noturnos!

--added--

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

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

• Desastre: algo muito infeliz acontece em todo o site.
• Erros humanos (este é o que acontece _all_the_time_):
  • Alguém decide exercer o recurso de "troca a quente" do seu servidor de armazenamento de uma maneira não pretendida pelo fabricante.
  • Alguém executa um processo que corrompe silenciosamente os dados, com backup confiável por alguns meses antes que o problema seja percebido.
  • Alguém exclui o relatório importante que deve chegar em uma hora e vale milhares de dólares.

Em seguida, avalie o custo das várias soluções de prevenção de riscos, por exemplo:

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

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

Em seguida, escolha o valor dos seus dados.

Eu tenho um cliente com dois sistemas similares de 12 TB em dois edifícios diferentes, conectados a 1 GB. Um é o sistema de produção; é feito backup incremental (com instantâneos diários) para o outro com o ótimo utilitário rdiff-backup . O rdiff-backup deve estar disponível em seu repositório de distribuição padrão.

Backup on-line externo (espelho remoto)

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

se você precisar manter versões com changes-ddiff-backup

http://www.nongnu.org/rdiff-backup/

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

Dê uma olhada no seu "conteúdo" real e com que frequência ele muda antes de planejar sua estratégia. Muitas vezes, as pessoas produzem os mesmos dados para gravar semanalmente repetidamente, sem uma boa razão.

As tecnologias de redução de redundância de alguns fornecedores podem permitir que o instantâneo o salve das restaurações de arquivos individuais, mas você sempre precisará de proteção externa.