Requisito de espaço: não tenho experiência prática para comentar, mas a documentação diz que "os backups tendem a ficar bastante grandes"... Ou seja, usar essa estratégia entre um checkpoint e outro pode ser viável, mas esses checkpoints têm de existir de qualquer maneira. Aí, cai no problema mencionado no item acima.
Periodicidade do backup: o backup incremental é feito continuamente, de modo que para períodos curtos (o que é "curto" vai depender da frequência de escritas na sua aplicação específica) pode-se restaurar o banco para qualquer momento arbitrário no passado. O backup de checkpoints, por outro lado, sofre de restrições semelhantes ao item acima.
Quanto ao backup em si, a estratégia é diferente conforme a escala: bancos pequenos podem ser arquivados por uma simples operação de dump, enquanto bancos maiores exigem o backup dos próprios arquivos de dados (já que a operação de dump é proibitivamente demorada). De novo, não tenho conhecimento suficiente para estimar o tempo de restauração em função do volume de dados, mas cabe observar que é sempre possível ter uma réplica pronta no "último estado válido" que poderia assumir rapidamente o estado de master no caso de uma situação "catastrófica".
Nesse caso o uso de um controle de versões seria o mais apropriado, como já apontado por @J. Bruni. Nesse caso, as alterações em si seriam feitas num ambiente distinto, e somente os resultados finais promovidos para o ambiente de produção. Ou seja, o backup não é feito no servidor de aplicação, mas em outro lugar.
A estratégia que otimizaria uso de espaço nesse caso seria ter as pastas de backup refletindo a mesma estrutura da pasta do servidor [no momento do backup], e cada arquivo fazendo um link (de preferência hardlink) para o arquivo verdadeiro. Opcionalmente, isso pode ser precedido de uma de-deduplicação, de modo a conservar espaço. Dessa forma, apagar um backup antigo é uma simples questão de apagar sua pasta e tudo o que tem dentro - uma vez que o hardlink garante que um arquivo só será excluído de fato quando nenhuma outra pasta de backup fizer referência a ele.
(Nota: no caso do servidor sem armazenamento confiável, pode ser interessante fazer uma cópia "real" de cada arquivo, e só a partir daí realizar os links. O projeto boar por exemplo usa essa estratégia, inclusive de de-duplicação. Além disso, ele pode ser mais viável na hora de mover arquivos para armazenamento externo - caso em que a solução por hardlinks apresenta problemas)
Nesse caso, fica difícil dar uma solução genérica, exceto talvez operar no modo copy-on-write ("copiar quando escrever") - de modo a permitir criar um snapshot do seu servidor sem ter que parar a aplicação. Isso é suportado no Windows por meio da funcionalidade Shadow Copy, e no Linux por meio do sistema de arquivos Btrfs. Uma vez feito o snapshot, o backup prosseguiria conforme os itens 1 ou 2 acima, dependendo do formato dos dados.