Respondendo sua pergunta: o teste de restauração é justamente o que quase todo mundo pula, então parabéns por já fazer em ID novo. Algumas ideias que complementam bem a sua rotina, já que ela está muito bem desenhada:

1. Cifrar antes de mandar pra nuvem. Com um remote crypt do rclone por cima do OneDrive, os arquivos (e até os nomes) sobem cifrados, e o provedor só vê bytes aleatórios. Detalhe importante, e que conversa direto com a sua história: guarde a senha do crypt fora do servidor (gerenciador de senhas, papel na gaveta). Se ela só existir no host, você perde servidor e chave juntos, e a cópia na nuvem vira inútil.
2. rclone copy em vez de sync para a cópia externa. O sync replica deleções. Se algo apagar ou corromper os backups locais (erro de script, ransomware), o sync propaga isso pra nuvem na próxima execução. Com copy mais uma retenção feita à parte, a cópia externa fica mais protegida. Vale também conferir quanto tempo a lixeira e o histórico de versões do OneDrive guardam no seu plano.
3. Verificar a cópia remota, não só a local. rclone check (ou rclone cryptcheck, se usar crypt) compara o que está na nuvem com o local. Dá pra colocar no mesmo e-mail de auditoria das 23:00.
4. SMART do HD USB na auditoria. Como a primeira perda foi de disco, incluir um smartctl -H (e talvez os contadores de setores realocados) no e-mail te dá um aviso antes da falha, não depois.
5. Automatizar o teste de restauração. Uma vez por mês, um script restaura o backup mais recente num ID temporário, sobe o container, confere se o serviço responde (um curl na porta já serve) e destrói tudo. O resultado vai junto no e-mail. Assim "backup só vale se restaura" vira algo verificado toda semana ou todo mês, não só quando você lembra.

Obrigado por compartilhar o post-mortem. Esse tipo de relato ensina mais que muito tutorial.