Boa estratégia de backup para dados heterogêneos consistindo de imagens / bancos de dados / arquivos do office / repositórios svn /

Question

Estou procurando uma solução de backup simples no local (ou seja, não on-line) para nossa pequena empresa. Neste momento, temos aproximadamente 4 TB de dados no total, talvez adicionando ~ 500 GB por ano. A quantidade de dados trocados por dia é muito menos difícil - acho que muito menos do que 1GB em média.

Todos os dados são acessados somente a partir da intranet e a maioria das máquinas está executando o Windows e algumas estão sendo executadas no MacOS, se isso for importante.

Os dados em detalhes:

(a) Grandes partes dos dados são imagens / vídeos / documentação (pdf) e similares, eu acho que 2,5 TB.

(b) Frequentemente acessados são nossos arquivos de dados CAD, mas eles ocupam apenas 10 a 20 GB. Estes são controlados / acessados por um vcs CAD centralizado chamado GAIN (acho que ele mantém seus dados em um banco de dados binário). Atualmente isso é despejado na noite e, em seguida, feito o backup.

(c) Alguns dados principalmente de código-fonte já estão sob controle de versão (SVN, GIT) ocupando menos de 2 GB.

(d) Alguns programas só possuem códigos fonte binários e são "arquivados" como arquivos zip. Novas versões são adicionadas e algumas versões antigas são restauradas algumas vezes, mas as versões antigas nunca são alteradas. Esses programas ocupam cerca de 80 GB.

(e) Alguns backups pessoais (e-mails, etc.) e outras coisas levam aproximadamente 1 TB, eu acho.

(f) Também temos uma pequena quantidade de dados em um único servidor Microsoft SQL. Isso deve perfazer menos de 1 GB.

Neste momento, fazemos um backup completo todas as segundas à sextas-feiras à noite, dos discos de rede ao disco do servidor local à unidade de fita no servidor. Nós alternamos a fita de sexta-feira, ou seja, temos fitas rotuladas mo, ter, qua, qui, fri1, fri2. Isto implica que não podemos voltar no tempo mais de 2 semanas no pior dos casos.

O que é uma boa solução para este sistema heterogêneo que consiste em

(a) grandes raramente acessados, raramente alterados, raramente adicionados dados,

(b) acesso freqüente em vez de dados pequenos entregues por um programa internamente usando um banco de dados,

(c) acesso freqüente de dados bastante pequenos sob controle de versão "comum",

(d) arquivos binários grandes (~ 100MB) que são adicionados principalmente, raramente lidos, nunca alterados (devem opcionalmente ser descartáveis) e

(e) dados diversos, como arquivos de escritório, registros de dados, pastas de e-mail que raramente são adicionados / alterados

(f) dados no servidor Microsoft SQL

Estou firme com programação, controle de versão e computadores em geral, mas novos em estratégias de backup. Por isso, seria bom se a solução fosse simples de manter.

Se possível, uma versão como a oferecida pelo SVN / Git seria legal, então o último backup bem-sucedido permite a restauração de todos os arquivos já armazenados (e não removidos manualmente).

Problemas com a estratégia até agora:

• o backup leva muito tempo (15 horas)

  = > Não há tempo suficiente para testar o backup

  = > Difícil dizer se o backup está realmente funcionando

  = > O que fazer se o tempo de backup atingir 24 horas?

• restaurar um backup é muito penoso
• restaurar algo que eu excluí / modificado / sobrescreveu há um mês não é possível

Uma solução deve resolver todos esses problemas.

Uso do tempo em detalhes:

• Coleta de dados de outros servidores pela rede para o servidor de backup: 02:15

• Copie os dados no servidor de backup (que atua como um servidor "normal" também) para outra unidade no servidor de backup: 09:00

• Copie todos os dados da unidade interna no servidor de backup para a fita conectada ao servidor de backup: 03:45

Answer 1

1. backing up takes a long time (17 hours) - Execute um backup completo no final de semana e faça backups incrementais durante a semana. Isso reduzirá a janela de backup durante a semana e também reduzirá a quantidade de armazenamento necessária para seus conjuntos de backup.

2. There's not enough time to test the backup - O que você está testando exatamente? Você deve executar uma restauração de teste de pequenos conjuntos de dados de seus conjuntos de backup toda semana ou todo mês. Você não precisa testar a restauração de todo o conjunto de backup. Restaure um punhado de arquivos e um banco de dados ou dois.

3. Hard to tell if the backup is really working - Veja o número 2. Você precisa testar os dados de restauração dos backups para saber se eles estão funcionando. Você deve fazer isso com bastante frequência para ter certeza de que os backups e o processo de backup são confiáveis de semana a semana.

4. What to do if the backup time reaches 24 hours? - veja o número 1.

5. restoring a backup is quite a pain - Como assim? É o processo? O software de backup? Etc., etc.

6. restoring something I deleted/modified/overwrote a month ago is not possible - Adquira mídia de backup suficiente para atender às suas necessidades de recuperação. Determine a quantidade de mídia de backup necessária por semana e quantas semanas você precisa recuperar e recuperar. Então multiplique os dois. Isso lhe dará uma ideia aproximada da quantidade de mídia de backup necessária e ajudará a determinar a programação de rotação de mídia de backup.

EDITAR

Para resolver seu comentário:

No que diz respeito à restauração de dados, isso depende do software de backup e do tipo de mídia de backup que você usa. O BackupExec usa uma fita e um catálogo de backups em disco. Encontrar dados que precisam ser restaurados não requer "leitura" das fitas até que você encontre os dados. Apenas requer encontrar os dados na janela Restaurar seleções no BackupExec. Depois de encontrar a mídia na qual os dados residem, basta enviar essa mídia para o BackupExec. Para avançar nesse ponto, o BackupExec recomenda a realização de backups em disco e a duplicação (cópia) desses backups em fita. Se você fornecer espaço em disco suficiente para executar uma semana inteira de backups, todos os dados que você possivelmente precisará restaurar durante a semana inteira estarão no disco e não exigirão que você faça a troca de fitas. Você simplesmente selecionará os dados a serem restaurados e o BackupExec irá encontrá-los na mídia do disco.

Quanto ao tipo de backup a ser realizado, isso é com você. Recomendo um Incremental Completo semanal e um Incremental diário, porque os backups incrementais diários serão executados mais rapidamente e serão menores do que um backup Diferencial diário, economizando tempo e dinheiro (em termos de janela de backup e mídia de backup). O caso em que um backup diferencial seria necessário para restaurar os dados está longe e poucos entre e eu nunca encontrei esse cenário em 13 anos na profissão de TI.

    

Answer 2

Isso cheira mal, desculpe.

Right now we have approximately 4TB of data in total, maybe adding ~500GB per year

4000gb não é um backup grande por qualquer meio e não deve demorar 17 horas. Como você faz isso - rede de 1gbit? Talvez seja hora de colocar em uma infra-estrutura decente. 10g backbone para o servr de backup, algo como o MIcrosoft DPM com agentes de mudança local e a funcionalidade para permitir restaurações de arquivo único para usuários, 10-12tb de espaço em disco no servidor de backup para manter backups em disco (para restauração rápida pelos usuários) .

Tudo isto é bem conhecido e documentado - parece-me que esta é basicamente a sua definição de como fazer backups que são ruins. de hardware insuficiente para software insuficiente. Você deve reavaliar sua configuração.

    

Answer 3

Estou tentando resumir quais conselhos foram dados:

• obtenha um servidor de backup dedicado para que os servidores de produção não estejam livres para serem alterados quando todos os dados estiverem no servidor de backup
• se o tempo de backup for muito grande, mude de backup completo todos os dias para backup completo na sexta-feira e backups incrementais / diferenciais de segunda a quinta
• Testes de backup serão suficientes quando feitos no backup de sexta-feira - ou quando tivermos um servidor de backup dedicado, talvez todos os dias (contanto que seja automatizado e, portanto, não leve meu tempo)
• Obtenha fitas suficientes para que possamos restaurar dados há muito tempo
• Para acelerar a recuperação, pode-se até considerar fazer um backup em disco, além de backups em fita
• Backups incrementais durante a semana devem ser preferidos, pois são mais rápidos e a vantagem dos backups diferenciais raramente é usada

Não há tratamento separado de repositórios / bancos de dados e dados "simples" em relação ao backup (além do banco de dados não deve ser usado no backup).