Como fazer backup de mais de 20 TB de dados?

86

Temos um servidor NAS na empresa em que trabalho, que está sendo usado para armazenar sessões de fotografia. Cada sessão tem aproximadamente 100 gb. Nos últimos anos, esse servidor acumulou mais de 10 TB de dados e estamos aumentando a quantidade de sessões de fotos exponencialmente. Estimo que até o final do próximo ano teremos mais de 20 TB armazenados neste NAS. No momento, estamos fazendo backup desse servidor em fita usando fitas LTO-5 com o Symantec BackupExec. Como o tamanho desse servidor aumentou, os backups completos desse servidor não estão sendo concluídos da noite para o dia. Alguém tem alguma sugestão sobre como fazer backup dessa quantidade de dados? Devemos fazer backup em fita? Existem outras opções que podem ser melhores?

backup

— Jesus Fidalgo
fonte

36

Por que você está executando backups completos todas as noites? Por que não executar um backup completo uma vez por semana e executar backups incrementais nos 6 dias restantes por semana?

— joeqwerty

9

É isso que estamos fazendo, desculpe, não mencionei que ... a semana inteira é a que não está completa.

— Jesus Fidalgo

6

Uma semana completa precisa ser concluída da noite para o dia? Não é incomum que os semanários levem mais de 24 horas para um conjunto de dados suficientemente grande.

— Stefan Lasiewski

2

Que tipo de NAS você está usando?

— ewwhite

6

Tem certeza de que o aumento nas sessões de fotos é exponencial ?

— Gerrit 12/12/12

114

Você precisa dar um passo atrás e parar de pensar "Tenho 20 TB no meu NAS, preciso fazer backup!" e desenvolva uma estratégia de armazenamento que leve em consideração a natureza dos seus dados:

De onde eles vêm e quantos dados novos você está obtendo? (você tem isso na sua pergunta)
Como os dados são usados depois que você os possui? As pessoas estão editando as fotos? Você mantém os originais e gera versões editadas?
Quanto tempo você precisa para manter todos os dados? As pessoas ainda estão fazendo alterações nas fotos de dois anos atrás?

Dependendo das respostas para as duas últimas perguntas, você provavelmente precisará de mais de um sistema de arquivamento do que de um sistema de backup radicalmente diferente.

Dados estáticos (por exemplo, fotos de 2 anos que você retém "apenas por precaução") não precisam ser copiados todas as noites, ou mesmo toda semana, precisam ser arquivados. O que você realmente faz pode ser mais complexo, mas conceitualmente, todas as fotos antigas podem ser gravadas em fita (várias cópias!) E não podem mais ser copiadas.

Com base nos seus comentários, algumas idéias adicionais:

Como você mantém os originais de cada filmagem intocados e trabalha em uma cópia, e supondo que pelo menos algumas das fotos originais sejam imprecisas, você poderá reduzir pela metade a quantidade de dados que precisa ser copiada.
Se você ainda não conseguir concluir um backup completo dentro de qualquer janela de tempo disponível, uma maneira comum de acelerar as coisas é fazer um backup de disco em disco primeiro e depois copiar o backup em fita.

— Ala
fonte

11

A foto original é armazenada intocada e, em seguida, outra cópia da sessão de fotos é usada para edição. Os dados podem precisar ser mantidos por aproximadamente 2 anos.

— Jesus Fidalgo

20

+1 Bem dito. Estou surpreso como a diferença entre Backup e Archive é, em geral, pouco compreendida. Faço backups completos e incrementais do meu sistema e dados efêmeros, como email e documentos, mas arquivo minha fotografia (1,2 TB e crescendo :-). Gostaria de poder dar outro +1 para a sugestão de disco para disco também.

— Ex Umbris 12/12/12

8

+1 Aposto que 80% dos dados no NAS nunca são usados mais de uma vez.

— Stefan Lasiewski

+1 A melhor opção aqui é fazer transferências diárias e até horárias de disco para disco delta para capturar alterações e, em seguida, enviar os backups completos ou incrementais para um arquivo ou provedor / local externo, semanal ou semestralmente. Costumávamos fazer backups delta de nossos arquivos SQL a cada 15 minutos para reduzir a quantidade de perda de dados em um cenário de DR.

— Brent Pabst

12

Você tem duas opções:

Opção 1:

Compre outro NAS
Conceda aos usuários RO acesso ao novo_NAS
Mova todos os arquivos com mais de 2 anos para new_NAS
Continue fazendo o backup do old_NAS como de costume
A cada 6 meses, mova arquivos com mais de 2 anos para new_NAS

Opção 2:

Compre outro NAS
Executar a rsynccada hora: old_NAS -> new_NAS

ou, melhor, use algo como rdiff-backup, que faz o rsync + manter deltas com alterações de arquivo (você pode restaurar versões mais antigas dos arquivos)
```
rdiff-backup  user1@old_NAS::/source-dir    user2@new_NAS::/dest-dir
```
A cada 6 meses, limpe arquivos antigos executando algo como:
```
rdiff-backup --remove-older-than 2Y    old_NAS::/dest-dir
```

— jato
fonte

2

Por que seus backups precisam ser concluídos da noite para o dia? Desempenho do servidor de arquivos? Você pode restringir a largura de banda do seu software de backup para limitar o impacto durante o dia. Ou dedique uma interface no seu NAS para conversar com a unidade de fita para limitar o impacto em outro tráfego.

Você pode executar lixeiras completas nos finais de semana e apenas incrementais durante a semana? Se o problema for trocar as fitas no fim de semana quando não houver ninguém por perto, uma biblioteca de fitas / trocador automático barato custa muito menos do que pagar alguém para trocar as fitas.

Você pode segmentar seus dados em vários grupos pequenos o suficiente para serem concluídos na sua janela de backup?

Temos cerca de 50 TB de dados em nosso NAS e leva mais de uma semana para obter um despejo completo de tudo usando duas unidades de fita (um volume leva quase uma semana em si porque contém muitos arquivos minúsculos). O que fazemos é replicar nossos dados para um segundo NAS. Nosso NAS secundário está no local (mas em um datacenter diferente do primário), portanto ainda colocamos os dados em fita em fita para backup externo. Nós executamos backups desse NAS secundário para que os backups não atrasem ninguém.

Se você puder colocar o NAS secundário longe o suficiente, poderá ser seu backup, sem a necessidade de fitas.

— Johnny
fonte

1

Estou apenas em dúvida sobre o tamanho de cada sessão de tiro, é realmente 100gb / sessão? Quantas sessões sua empresa faz a cada mês?

Como você geralmente armazena sessões antigas que não serão usadas com frequência etc., e provavelmente não precisa recuperar essas informações com frequência, sugiro que você use os serviços de alguma empresa para cuidar dessa tarefa. .

Apenas por exemplo, armazenar esses 20 TB usando um serviço online como o Amazon Glacier custaria um pouco mais de US $ 200 / mês. Se você precisar recuperar esses arquivos com freqüência, ou mesmo recuperá-los na íntegra, isso afetaria alguma restrição de tempo / custo. Se você apenas armazenar essas coisas "para garantir que elas sejam armazenadas", talvez o uso de uma terceira parte possa facilitar sua vida (e até mais barato do que comprar outro NAS, fitas etc.)

— woliveirajr
fonte

11

100 GB por sessão me parece um pouco alto, mas não razoável. Geralmente, tínhamos uma sessão de mais de 32 GB onde eu trabalhava e nosso equipamento era de nível médio.

— Tom Marthenal

1

full backups of this server are not completing overnight
Então tente backups incrementais? Um backup completo a cada xx dias, incrementalmente o restante.

Os discos rígidos são baratos, mais rápidos que as fitas e podem ser usados para backup.

Também existem boas alternativas para backups na nuvem agora, portanto, não é necessário continuar adicionando fitas cada vez mais rápidas.
Por exemplo:

— Tedd Hansen
fonte

Veja os comentários - são os totais semanais que não estão sendo concluídos. Além disso, backups na nuvem para 20 TB de dados ... não é uma boa ideia. A opção "barata" do Amazon Glacier custará ~ 2500 / ano, e recuperar todos esses dados custará ~ $ 36.000.

— precisa

Isso não é realmente muito.

— Sirex

11

Eu acho que é uma questão de opinião se US $ 2400 / ano é muito por 20 TB de armazenamento relativamente seguro e totalmente livre de manutenção. Sem consumo de energia, sem refrigeração, sem hardware com falha, sem SLA, não ocupa espaço no rack. E, como na maioria dos sistemas, você deve esperar cerca de 0 operações de recuperação completa. E se você precisar de uma recuperação, o preço será mais de US $ 1800 do que US $ 36000 (não sei de onde você obteve esse número).

— Tedd Hansen

Para as geleiras, os US $ 36 mil estão bem próximos. Eu calculo aproximadamente US $ 42 mil para custos de recuperação em 20 TB. Ainda não é muito embora. A largura de banda é mais um problema.

— Sirex

1

Penso que a melhor solução para isso é o que fazemos com os dados da folha de pagamento, o que deve exigir um esforço mínimo para você implementar.

Inicialmente, ele é mantido com o restante dos dados do servidor que são copiados diariamente. Nosso período de retenção nesses backups é de 13 meses.
Quando não esperamos mais que os dados precisem ser modificados (dois períodos de pagamento depois, IIRC), os dados são salvos (via script) em um volume de arquivo excluído dos backups regulares.
O backup do volume do arquivo é arquivado anualmente em fita e as fitas são enviadas para o Cintas para armazenamento indefinido.

Isso nos permite ter acesso on-line fácil a esses dados imutáveis (para que não precisemos chamar uma fita a qualquer momento que um contador queira ver alguma coisa), enquanto mantemos arquivos indefinidos de dados externos que talvez precisemos manter para sempre e sem esmagar nosso sistema de backup. Parece que o mesmo tipo de configuração pode funcionar para você, embora você queira ajustar a quantidade de dados que mantém on-line, dependendo de suas necessidades de acessar esses dados em tempo hábil - 20 TB de armazenamento de nível corporativo é muito mais caro do que arquivá-lo em dois ou três conjuntos de fitas LTO5 que você armazena em cofres externos.

— HopelessN00b
fonte

0

Talvez você possa criar seu próprio Backblaze Pod : 135Tb por 7384 $
Clique aqui para obter mais informações: Backblaze Pod building info

Você pode comprar as peças necessárias e construí-lo sozinho.

Talvez você possa criar 3 deles e manter 2 no local e 1 externo. Em seguida, você pode usar um pod como "dados on-line", o segundo pod local como backup do primeiro pod e o terceiro pod externo como backup externo de emergência.

Com 135 TB de armazenamento para cada pod, você pode até pensar em manter um histórico da mudança ...
135 TB / 20 TB = 19 cópia de backup completa .
Como alternativa, você pode manter 10 backups completos, além de uma quantidade ridícula de backup diferencial.

Naturalmente, se você deseja um backup externo, precisará de algum tipo de grande largura de banda ... :-)

— Máx.
fonte

5

Se seus dados e seu trabalho são importantes para você, você não deve tentar criar seu próprio pod de backblaze do zero. Parece uma boa idéia, até você perceber que está colocando todos os seus ovos em uma cesta muito grande. Pior ainda, esse cesto não foi completamente testado como um todo integrado. O segredo do backblaze é a replicação de software em muitos pods, o que permite que pods inteiros falhem sem problemas. Em vez disso, eu recomendaria um servidor de armazenamento supermicro, centos, xfs e rdiff-backup.

— precisa

-1

Meu colega comprou um NAS Synology de 8 discos. Ele roda um RAID híbrido. Ele comprou oito Seagate Barracuda de 3 TB da NewEgg há algumas semanas por US $ 89 cada. Você pode sincronizar o espelho do NAS de produção para este novo NAS no GigaBit. Como você está transferindo apenas as diferenças, a transferência levará um tempo menor. Em seguida, você pode usar o NAS de backup para executar incrementais ou completos. O custo para você seria inferior a US $ 2.000 para um NAS de backup.

— Dom
fonte