Recentemente trabalhei em um projeto de milhões de dados, tanto no ambiente de desenvolvimento ou de produção.

O resultado foi que em algumas semanas o servidor de desenvolvimento “estourou”, metaforicamente falando claro. Identificamos que as bases de dados estavam com 30GB cada uma, resultado de uma má estratégia de modelo de recuperação (backup).

Procurando na internet encontrei um artigo interessante sobre o assunto, pode ser lido em: www.devmedia.com.br/articles/viewcomp.asp?comp=6458

O resumo seria o seguinte…

SIMPLE (Ideial para Desenvolvimento!)

O log de transações (Transaction Log) é usado muito pouco neste modelo de recuperação. De fato, quase nada é registrado no log. Isto significa dizer que a escolha em usar este modelo para seus banco de dados só será possível recuperar o último backup.

BULK-LOGGED

Este modelo registra muito mais informação no log de transações do que o modelo SIMPLE. A única informação não registrada são operações de volume como: SELECT INTO, BCP, BULK INSERT,CREATE INDEX e operações com os tipos de dados texto e ntext. Isto significa que você pode recuperar a maior parte dos dados no caso de algum problema, porém só as operações citadas serão perdidas.

FULL (Sempre em produção!)

Este modelo de recuperação informa ao SQL Server que você quer realizar também o backup de log de transações. Para tornar isso possível, o SQL Server mantém todas as transações em um log de transações até que um backup do log de transações ocorra. Quando o backup do log de transações acontece, o SQL Server trunca o log de transações depois que o backup é gravado no dispositivo de backup.

Fonte:
www.devmedia.com.br/articles/viewcomp.asp?comp=6458