Faz sentido usar full recovery se os dados e arquivos de log estiverem no mesmo HD?

Não posso falar com 1, mas com 2, não sei se sua posição deve levar a empresa a um RPO (objetivo de ponto de recuperação) específico. Eles podem não estar cientes de que teriam que reinserir todos os dados por um dia se as coisas derem errado. Fale com eles, descubra quanta perda de dados eles estão dispostos a tolerar. Se eles disserem que 24 horas é demais, ótimo, isso indica que a abordagem atual é insuficiente para suas necessidades. Se isso exigir a compra de hardware para atender ao RPO, eles precisarão fornecer financiamento ou aceitar sua perda máxima de dados atual. Por fim, documente o resultado em algum local público e, em seguida, teste suas restaurações de forma recorrente para garantir que você seja capaz de atender a esse RPO.

Dito isso, há muitos outros motivos para ter dados e log (e temperatura) em unidades separadas. Alguns deles documentados nesta questão https://serverfault.com/questions/38511/ms-sql-layout-for-best-performance

Primeiro, para responder diretamente às perguntas:

1. Em minha experiência pessoal, se eu estivesse mantendo a pontuação, as causas para restaurações de banco de dados seriam: exclusão acidental de dados = muitos, restauração para dev para teste = muitos, falha / corrupção do sistema IO = nenhum. (bate na madeira)

2. Você indica que "não há necessidade de recuperar em nenhum ponto no tempo anterior ao nosso último backup". Se for esse o caso, então sim, mude para a recuperação SIMPLES.

Alguns comentários, porém:

As causas de falha de todos serão diferentes: o talento do desenvolvedor pode ditar a frequência da exclusão acidental de dados, a arquitetura de armazenamento pode ditar se uma unidade com falha é fatal ou apenas um incômodo, etc.

Quanto ao modelo de recuperação SIMPLES vs COMPLETO, essa é uma decisão que deve ser tomada pelos empresários. Eles precisam pesar os danos causados ​​ao negócio pelo tempo de inatividade e/ou perda de dados em relação ao custo de administração e espaço.

Em relação aos arquivos de dados e log na mesma unidade, a sabedoria convencional separa os dois porque o acesso ao arquivo de dados é aleatório, enquanto o acesso ao arquivo de log é sequencial. Na minha experiência, isso funciona se você estiver falando sobre alguns bancos de dados em unidades que você pode separar, mas em uma SAN com 100 bancos de dados espalhados por 48 discos, todo o acesso aos dados torna-se aleatório de qualquer maneira.

Você definitivamente deseja mover os backups desse disco pelo motivo que apontou: ocorre uma falha no disco. Ter uma cópia local pode ser conveniente, então isso não é necessariamente ruim - por exemplo, se um usuário final executar acidentalmente uma consulta de exclusão sem uma cláusula WHERE, ter acesso rápido a um backup pode salvar seu bacon. Dito isso, eu ainda colocaria backups locais em uma unidade separada; você não quer ficar sem espaço em disco na unidade que hospeda seus arquivos de banco de dados. Além disso, deve haver absolutamente outra cópia fora do local. Seguir a regra 3-2-1 ajuda a mantê-lo protegido contra incidentes geradores de currículos.

Em relação ao modelo de recuperação, se você não precisar de recuperação pontual e fizer backups completos com frequência suficiente para satisfazer seu objetivo de ponto de recuperação , o modo Simples é adequado. Mas certifique-se disso primeiro - se o seu SLA garantir uma perda de 4 horas, provavelmente você deseja manter os backups do log de transações lá.

Fazemos backups diários completos do banco de dados e não precisamos recuperar nenhum ponto no tempo anterior ao nosso último backup.

Você respondeu a pergunta ali mesmo. Se você tem certeza de que não precisa se recuperar em nenhum ponto anterior ao nosso último backup, o que considerei como 'não precisamos de recuperação pontual ou a capacidade de recuperar entre nosso último backup completo', tendo então o log de transações no mesmo disco não importa em uma perspectiva de recuperação. Defina o DB para o modo simples.

Os logs de transação são isolados em seus próprios discos por 2 motivos:

• 1-Maximize a taxa de transferência de gravação. O log de transações deve ser absolutamente gravado (com exceção de um buffer de 60k) antes que qualquer dado seja confirmado. Ter uma taxa de transferência de gravação rápida é muito importante para que suas gravações não fiquem lentas.
• 2-Tail dos backups de log. Supondo que você faça um backup do log de transações a cada hora, e sua matriz de unidades trave 15 minutos antes do próximo backup, você acabou de perder 45 minutos de trabalho. No entanto, se você tiver seus logs de transações em um grupo de unidades diferente, poderá fazer um backup final do log de transações, restaurar seus bancos de dados e pronto! Se a unidade que contém o arquivo de log também travar, você perderá apenas o que não foi confirmado no disco por um processo lazywriter ou um ponto de verificação.