Janela de manutenção e recuperação para um banco de dados grande

Question

Uma de nossas equipes está desenvolvendo um banco de dados um tanto grande (~ 500GB) e crescer a partir daí (eu sei que 500 Gigs podem parecer pequenos para muitos de vocês, mas será um dos maiores bancos de dados em nossa loja) . Um dos problemas com os quais eles estão lidando é o backup e a restauração do banco de dados. Basicamente, o banco de dados terá várias tabelas de "dados" e uma tabela usada para armazenar imagens / documentos. Precisamos realizar o seguinte:

• Ser capaz de fazer backup e restaurar rapidamente apenas as tabelas de dados (sem imagens) para o nosso servidor de teste para fins de depuração e teste.
• No caso de uma falha catastrófica do banco de dados, restaure as tabelas de dados apenas para colocar a maior parte do aplicativo em funcionamento o mais rápido possível. Em seguida, restaure a tabela de imagens quando possível.
• Faça backup do banco de dados na janela de horário noturno distribuída (algumas horas). Minhas perguntas são:

É possível realizar os dois primeiros objetivos enquanto ainda mantém as imagens armazenadas no mesmo banco de dados? Em caso afirmativo, usaríamos grupos de arquivos, filestream ou outra coisa? Como outras lojas fazem backup de seus bancos de dados em uma janela de tempo razoável, mantendo alta disponibilidade? Você se replica para um segundo servidor e faz backup de lá?

    

Answer 1

Muito simples: NÃO PLANE PARA RESTAURAR.

In the event of a catastrophic database failure, restore the data tables only to get most of the application up and running ASAP.

Realmente? Sua definição de catástrofe não é minha e do resto dos mundos.

No caso de uma datatrofia que você deseja recuperar o mais rápido possível, o mais rápido possível pode exigir a reconstrução do data center devido a um incêndio. Isso é uma catástrofe.

Para falhas do servidor, etc. - não planeje usar backups. Use replicação, remessa de arquivo de log para manter um segundo servidor (em uma SAN separada) quente e lido para assumir dentro de um tmieframe curto definido. Conheço empresas que enviam arquivos de log a cada 10 minutos.

Praticamente sua única chance. Mova a catástrofe para algo que é um desaster REAL, não uma falha raid / san. Algo em que sua missão não é "o quão rápido eu posso restaurar", mas "quão rápido eu ganho um novo hardware".

As restaurações para o dev etc. são menos críticas em termos de tempo.