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

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

Uma de nossas equipes está desenvolvendo um banco de dados que será um pouco grande (~500 GB) e crescerá a partir daí (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 que eles enfrentam é fazer backup e restaurar o banco de dados. Basicamente, o banco de dados terá diversas tabelas de “dados” e uma tabela utilizada para armazenamento de imagens/documentos. Precisamos realizar o seguinte:

  • Ser capaz de fazer backup e restaurar rapidamente apenas as tabelas de dados (sem imagens) em 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 dentro do período noturno alocado (algumas horas). Minhas perguntas são:

É possível atingir os dois primeiros objetivos mantendo as imagens armazenadas no mesmo banco de dados? Se sim, usaríamos grupos de arquivos, fluxo de arquivos ou algo mais? Como outras lojas fazem backup de seus bancos de dados em um período de tempo razoável e, ao mesmo tempo, mantêm alta disponibilidade? Você replica para um segundo servidor e faz backup de lá?

Responder1

Muito simples: NÃO PLANEJE RESTAURAR.

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.

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

No caso de uma destruição de dados, você deseja fazer backup o mais rápido possível, mas 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 de servidor, etc. - não planeje usar backups. Use replicação, envio de arquivo de log para manter um segundo servidor (em uma SAN separada) ativo e lido para assumir o controle dentro de um tmieframe curto definido. Conheço empresas que enviam arquivos de log a cada 10 minutos.

Praticamente sua única chance. Transforme a catástrofe em algo que seja um desastre REAL, não uma falha de raid/san. Algo em que sua pergunta não é "com que rapidez posso restaurar", mas "com que rapidez consigo um novo hardware".

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

informação relacionada