Estou querendo criar um plano de manutenção que faça um backup completo que é feito todo domingo de manhã. Após o expediente de segunda a sexta-feira, desejo realizar um backup diferencial com base neste backup completo. No entanto, em vez de sobrescrever o backup completo da semana anterior, quero reter esse backup completo para registros históricos/fora do local, ao mesmo tempo em que me livro dos diferenciais associados a esse backup completo. O tipo de plano que estou planejando criar é o seguinte:
- Se necessário, uma reconstrução dos índices do banco de dados é feita no início da manhã de domingo.
- Uma advertência adicional a isso seria reorganizar + atualizar as estatísticas com base na quantidade de fragmentação presente.
- Após a manutenção do índice, um backup completo é criado na mesma manhã.
- De segunda a sexta à noite, um backup diferencial é feito com base no backup completo.
- Após o diferencial, uma verificação de integridade do banco de dados é executada.
- No próximo domingo chega, um backup completo é estabelecido, os diferenciais da semana anterior removidos e o backup completo anterior é trazido aqui localmente para um Drobo após o expediente.
O motivo desse tipo de plano se deve às restrições de tamanho do HDD no ambiente do Azure com o qual estou trabalhando. Diante disso, essa é uma estratégia sólida ou onde devo buscar melhorias? Em segundo lugar, como retenho os backups completos do banco de dados da semana anterior, mas NÃO os diferenciais? Os artigos que li até agora parecem indicar que um backup rotativo dessa natureza terá os backups completos e diferenciais removidos.
Esta é uma instância do SQL Server 2012 em uma VM do Windows Server 2012 no ambiente Azure. Existem 5 bancos de dados, variando de 6 GB a 10 GB cada, que serão afetados por esse tipo de plano.
Obrigado pela sua assistência.
Como você afirmou, sua estratégia de backup pode ser vista como abaixo:
Duas coisas importantes que você pode fazer
WITH COMPRESSION
A partir da figura acima, há um claro espaço para melhorias. Você deve fazer um backup diferencial no Sat (apenas para o caso de ocorrer um desastre) . Além disso, é importante ler Backups que deram errado: o perigo dos diferenciais . Certifique-se de fazer um backup completo no meio de sua estratégia de backup, use o backup COPY_ONLY .
Não use planos de manutenção, pois eles têm desvantagens perceptíveis . Eu recomendo usar a solução de backup da Ola (e também a solução de manutenção do Index ).
Editar: Conforme seu comentário:
Se ocorrer um backup completo no meio, seus diferenciais seriam inúteis, pois a base mudou e você não sabe quem fez o último backup completo. O diferencial depende do último backup completo. Se você sabe que as pessoas farão backups completos ad hoc que atrapalharão seus diferenciais, negue a eles direitos de backup e crie um procedimento armazenado que fará backup completo com a opção COPY_ONLY e concederá a essas pessoas direitos de execução para esse SP. Além disso, concentre-se no modelo de recuperação dos bancos de dados - o modelo de recuperação completo deve ter um backup de log.
Você pode até consultar
msdb.dbo.backupset
where is_copy_only = 0
para descobriruser_name
usuários que estão fazendoCOPY_ONLY
backupsApenas adicionando isso para completar - Restringir os usuários a COPIAR APENAS backups de LOG