Eu sou novo no backup de banco de dados. Acabei de aprender sobre os tipos de backup com esta pergunta (Link) . Depois de ler the differential backup is cumulative since the last full, fiquei curioso se vários backups completos e diferenciais não são obrigatórios.
Por exemplo, eu tenho backups assim:
full_backup_2018_05_09_000000.bak
tran_backup_2018_05_09_000500.trn
tran_backup_2018_05_09_001000.trn
diff_backup_2018_05_09_001500.bak
tran_backup_2018_05_09_002000.trn
tran_backup_2018_05_09_002500.trn
diff_backup_2018_05_09_003000.bak
tran_backup_2018_05_09_003500.trn
tran_backup_2018_05_09_004000.trn
diff_backup_2018_05_09_004500.bak
tran_backup_2018_05_09_005000.trn
tran_backup_2018_05_09_005500.trn
full_backup_2018_05_09_010000.bak
...
Qual é a diferença entre isso e usar um backup completo e backups de log de transações como este?
full_backup_2018_05_09_000000.bak
tran_backup_2018_05_09_000500.trn
tran_backup_2018_05_09_001000.trn
tran_backup_2018_05_09_001500.trn
tran_backup_2018_05_09_002000.trn
tran_backup_2018_05_09_002500.trn
tran_backup_2018_05_09_003000.trn
tran_backup_2018_05_09_003500.trn
tran_backup_2018_05_09_004000.trn
tran_backup_2018_05_09_004500.trn
tran_backup_2018_05_09_005000.trn
tran_backup_2018_05_09_005500.trn
tran_backup_2018_05_09_010000.trn
...
A diferença na funcionalidade é mínima - a diferença no que acontece quando você realmente faz uma restauração é enorme.
Os backups de log são sequenciais, portanto, no cenário acima, para restaurar para 00:55, você precisaria restaurar
VS
A utilização de DIFFs e FULLS significa que você não precisa reproduzir todos esses arquivos de log, o que pode consumir muito tempo e potencialmente prejudicar seu RTO (Recovery Time Objective)
Você deve se perguntar no caso de um desastre, ou em qualquer cenário de recuperação, quanto tempo você está disposto a esperar para que o banco de dados fique disponível novamente - isso normalmente determina quais métodos você pode usar.
Resposta alternativa: se você é masoquista, use apenas backups de log.
Objetivo de tempo de recuperação
O RTO descreve o tempo necessário para realizar uma restauração completa do banco de dados em um determinado momento.
Restaurar um grande número de arquivos de log de transações normalmente será consideravelmente mais lento do que restaurar apenas o diferencial mais recente seguido por seus logs de transação. Portanto, seu RTO seria mais longo.
Tolerância ao erro
Se você perder um único backup de log de transações (ou esse backup for corrompido ou comprometido de alguma forma), seu segundo exemplo não toleraria que esse único arquivo fosse inadequado/indisponível para restauração, se você estivesse tentando restaurar para o ponto mais recente.
O primeiro exemplo que você forneceu exige que você restaure apenas o backup diferencial mais recente e, em seguida, todos os backups de log de transações subsequentes, se você estiver tentando restaurar para o ponto no tempo mais recente.
Estratégia de DR
Muitas vezes, um banco de dados pode ser tão grande que a execução de mais de 1 backup completo por semana é difícil de gerenciar, pois o backup pode não ser concluído durante um período de baixa atividade, portanto, o toque relativamente leve dos backups diferenciais pode ajudar. A escolha de como/quando fazer backups no SQL Server é baseada inteiramente no RTO/RPO.
O principal objetivo do backup diferencial é reduzir seu Recovery Time Object (RTO) . Em termos mais simples, em caso de desastre, você pode recuperar rapidamente o banco de dados usando o backup diferencial.
Supondo que você não tenha um script embutido para restaurar backups, restaurar backups completos e muitos de log de transações depois disso é demorado em comparação com a restauração de backup completo e backup diferencial mais recente (já que é cumulativo) e poucos backups de log depois disso.
Em dois cenários que você mostrou acima em caso de desastre, você teria que restaurar
enquanto se você não tiver backup de diferenças, você teria que restaurar como
Além disso, eu sugiro que você leia Backup Myth por Paul Randal.