Procedimentos padrão de backup de banco de dados

Question

Eu estive analisando a configuração que implementamos para um cliente hospedado, que tem um banco de dados com backup várias vezes por dia (e a última semana de backups sempre disponível). Digamos que os backups exijam 20gb e a unidade em que eles estão hospedados (partição, na verdade) seja 30gb. Há mais de 10GB de outras 'coisas' na unidade, através de uma instalação do SQL 2000, sistema operacional e várias outras coisas, o que significa que há uma luta constante para manter a unidade em algum lugar completamente cheio.

Eu vejo como desnecessário ter uma semana de backups armazenados em uma unidade SCSI, mas não sou especialista nessa área e estou realmente apenas procurando conselhos de outros DBAs sobre como eles gerenciam esse tipo de esquema de backup ?

Vale a pena notar que estamos usando 3 unidades no momento, uma configuração espelhada do raid e uma reserva para trocar a qualquer momento. Assim, a recuperação de desastres está no centro do problema, minimizando o custo.

Qualquer entrada é bem-vinda ...

Obrigado antecipadamente pessoal.

    

Answer 1

o que implementei anteriormente como nossos procedimentos padrão de instalação / backup do SQL Server (SQL 2000-2008) é o seguinte

Particionamento de dados Divida os binários do OS / SQL, arquivos de dados e arquivos de log em 3 volumes físicos separados, OS / SQL no RAID 1, dados no RAID 1 (Esta atualização após comentário de Paul Randall ( link ), faz o login no RAID 1. Também recomendamos 1-2 hot spares. Eu recomendaria pelo menos algum nível de RAID para todos eles, sempre que possível, mas se espaço / custo é um problema, RAID 1 e colocá-los todos em um conjunto de unidades, você ainda terá o mesmo nível de redundância (máximo de 1 drive falhar) como RAID 5 (assumindo 2 e 3 unidades respectivamente)

Configuração do banco de dados Implemente 3 arquivos de dados para cada um dos seus bancos de dados, o MDF e LDF padrão para dados e logs e também um NDF, defina o NDF como seu arquivo de dados padrão nas propriedades do banco de dados, MDF sozinho. Eu configurei todos os meus bancos de dados para o Modelo de Recuperação Completa, pois faço o espelhamento e preciso ser capaz de fazer restaurações point-in-time. Eu recomendaria fazer isso de qualquer maneira, mas vem com um aviso (abaixo)

BACKUPS A parte mais importante da configuração do seu banco de dados é corrigir os backups (e as restaurações associadas). Minha configuração padronizada é um backup completo às 2h quando temos uma janela estreita de pessoas que não usam bancos de dados (operação global com funcionários em vários fusos horários de Cingapura a Nova York) e um backup do log de transações a cada 5 horas começando às 8h (08h00, 13h00) 1600, 2100). Disclaimer Certifique-se que se você tiver seus bancos de dados configurados como Full Recovery Model que você está fazendo Backups de logs de transações , caso contrário, você pode acabar com monstruosos arquivos de log e, em seguida, você pode ter que truncar e, em seguida, reduzi-los, que de acordo com Paul Randall (Hi Paul!), que eu confiaria implicitamente em SQL, é um VeryBadThing (tm). Os backups diários (incluindo os logs de transações relacionados a eles) são mantidos localmente na máquina e depois coletados todas as noites pelo nosso serviço de backup e retirados do local pelo administrador de plantão. Dessa forma, se a máquina for perdida, perderemos apenas os dados do último backup completo e, no caso de alguém estragar os dados, apenas a entrada de informações entre o último backup do T-Log e esse ponto no tempo (podemos entrar no registro atual e reprodução de quaisquer outras transações, mas geralmente não fazemos como nossos SLAs são criados para acomodar isso) É claro que você pode enviar os backups de log de transações fora da máquina ou mesmo fora do local no momento da criação, mas essa é uma decisão para você fazer .

Arquivo de dados encolhendo NÃO FAÇA (a não ser que você entre em uma situação em que não possa evitá-lo) Certamente não agende isso!

Indexação e fragmentação Esta deve ser uma operação manual (mas com script) que é executada somente quando necessário, você deve fazer manutenção regular e a fragmentação do índice deve estar nessa lista. No meu plano mensal eu verifico os tamanhos dos arquivos de dados, a fragmentação do índice e o número de bancos de dados (algumas vezes os desenvolvedores adicionam bancos de dados e não nos dizem, os planos de manutenção cuidam dos backups mas às vezes estragam os layouts dos arquivos de dados e convenções de nomenclatura), se detectarmos quaisquer novos bancos de dados, eles serão auditados em relação ao seu tamanho, layout do arquivo de dados e backups (nunca é demais verificar e checar os backups)

Por favor, sinta-se livre para qualquer um, para escolher os buracos acima ou, pelo menos, para me dizer que estou falando bobagem.

    

Answer 2

Não faça isso do ponto de vista do "backup", da perspectiva "restaurar". Sente-se e defina o que você precisa para poder recuperar as coisas, testar algumas recuperações para ter certeza de que a lista está correta e completa e só então começar a considerar sua estratégia de backup.

Em geral, com um aplicativo de servidor, o backup do sistema operacional, os arquivos de programa, a configuração e todos os outros doo-dahs é algo que eu consideraria essencial. A recuperação dos dados brutos é fácil, mas a recuperação da configuração não é. Além disso, você tem os níveis de patch atuais para recuperar, o sistema operacional, a configuração do aplicativo, qualquer conta de usuário local que possa ter criado para que os serviços sejam usados e assim por diante.

Então, faça backup de tudo e tenha certeza de que você não perdeu nada é o meu mantra.

Agora, você está mantendo vários backups por dia durante uma semana no mesmo armazenamento que o sistema operacional. Isso é bom se você acidentalmente perder alguns dados; Se você perder o sistema operacional ou tiver uma falha de hardware, você é EFF-YOU-SEE-KAY'ed e não há erro.

Uma abordagem que usei antes é fazer dados regulares (apenas) em disco para o disco durante o dia, mas um backup completo de tudo para fita à noite. Isso reduz os requisitos de armazenamento para os lixões diurnos, o que pode, por sua vez, fornecer uma janela de recuperação mais longa para dados perdidos acidentalmente (mantendo o valor de mais de uma semana). Manter o máximo em fita significa que posso fazer uma recuperação completa de tudo, mesmo em um servidor alternativo, se necessário. Eu poderia ir mais longe, mas agora meus requisitos de negócios não precisam de mim - seu poder.

    

Answer 3

Seu plano de backup atual, como descrito, não abrange muitos cenários em que a recuperação de desastre seria necessária.

Você deve, no mínimo, ter backups daquela máquina caso algo drástico, como um defeito na fonte de alimentação, mate todas as unidades de uma só vez, de preferência em outro local, caso algo aconteça ao prédio em que o servidor está instalado.

Não há nada de errado em manter uma cópia local dos backups no próprio servidor, além de facilitar o acesso, como em uma nova unidade maior, como você sugere, mas esses não devem ser seus únicos backups.

De sua atual posição restrita ao espaço, eu recomendaria manter apenas os últimos backups locais na máquina e manter o restante em uma unidade maior em outra máquina, de preferência fora do local, se possível (protocolos como rsync podem reduzir a largura de banda necessária para backups off-site consideravelmente). Se a máquina tiver acesso físico a ela, você poderá (ou também) manter backups off-line, copiando-os para uma unidade externa e mantendo-a longe da máquina em outros momentos (ou melhor ainda, ter duas ou mais externas drives e ciclo-los - grandes drives em gaiolas USB são muito baratos nos dias de hoje). No caso de você ter acesso físico, uma unidade de fita com várias fitas no ciclo pode ser uma opção melhor.

    

Answer 4

Então, enquanto você tem três unidades, você está usando apenas 1 unidade de espaço, certo? Duas unidades no espelho + a terceira como sobressalente ...

Você pode ganhar algum espaço através de uma migração para o RAID 5

Dito isto, você pode simplesmente adicionar outra unidade grande para armazenar os backups, como sugerido na sua pergunta.