Caso o armazenamento não seja um problema: existem realmente boas razões para fazer backups incrementais em vez de apenas fazer backups completos?
Editar
Na verdade, isso pode se referir a qualquer banco de dados com backups completos e incrementais. Neste caso, usamos um RDBMS Progress OpenEdge com suporte para ambos os planos de backup, bem como arquivamento de log transacional em tempo real. Além disso, não acho que a questão deva estar relacionada a um único fornecedor. A escolha de backup completo/incremental pode ser aplicada a vários mecanismos de banco de dados diferentes.
O tempo para a execução do backup é um motivo para fazer o backup incremental no Progress. Meu backup está sendo executado rápido o suficiente para não precisar usar essa função e ainda estou fazendo apenas backups completos.
Também depende de suas necessidades. Por exemplo, se você tiver transações financeiras pesadas e quiser manter um backup a cada hora ou algo assim, precisará fazer incremental (ou tempo real).
Mas, a menos que você tenha algo forçando você a fazer incremental, eu faria backup completo, acho mais fácil restaurar.
Em termos de impacto no desempenho, se você tiver uma matriz de disco rápida, não vi muito impacto em fazer um backup, mesmo durante o uso moderadamente pesado. Obviamente, depende também do tamanho do seu sistema. Estou falando de um banco de dados de 37 Gb.
Se o espaço não é um problema, o tempo pode ser. Um backup incremental geralmente leva menos tempo do que um backup completo. Muitos DBAs não têm janelas de manutenção suficientes para fazer backups completos durante a semana (se o completo demorar algumas horas, por exemplo) e precisam recorrer ao backup incremental todas as noites.
Se você quiser saber mais sobre backups e operações de restauração (e como trabalhar com Sql Server), você pode fazer muito pior do que dar uma olhada no livro de Shawn McGehee, SQL Server Backup and Restore .
Se o tempo e o espaço forem pouco importantes para você, você pode prosseguir com o plano de manutenção mais fácil, que consiste apenas em backups completos (com ou sem backups de log de transações). Depende muito da quantidade de dados que você possui, da duração da sua janela de manutenção e do seu SLA ( acordo de nível de serviço ), se você tiver um.
A que RDBMS você se refere? O MS SQL Server não possui "backup incremental". Possui apenas backups completos, diferenciais e de log de transações.
Você pode equiparar (vagamente) os backups de log de transação como backup incremental, pois exigirá um backup COMPLETO e todos os incrementos (que nada mais são do que backups de transação) até a falha pontual.
O backup diferencial funciona de maneira diferente, pois você só precisa de um backup COMPLETO e o último backup diferencial e o banco de dados pode ser levado ao ponto em que o backup diferencial foi feito. Depois disso, você deve restaurar os backups do T-log, para que uma recuperação pontual possa ser executada.
Considerando os fatos acima, a maioria dos DBAs ou administradores de servidores prefere backups completos e subsequentes backups incrementais (backups T-log) a a. conservar espaço em disco b. O tempo necessário será menor em comparação com a restauração de um backup COMPLETO.
Observe que o modelo de recuperação (por exemplo, BULK LOGGED, SIMPLE, FULL) também desempenha um papel importante quando você faz backups T-log (obviamente, a recuperação SIMPLE está fora de questão quando se trata de fazer backups T-log).
O único problema com os backups incrementais (T-log) é que, se você perder algum deles, o banco de dados só poderá ser restaurado para a última cadeia de log ininterrupta. Imagine alguém excluindo arquivos, etc. Além disso, gerenciá-los também é uma sobrecarga extra.