Paul Randall has some insight and suggestions
sqlmag.com/blog/transaction-log-corruption-and-backups
"DBCC CHECKDB doesn’t analyze the log at all"
"Unless the corruption occurs in the active portion of the log (the portion that is required for some reason by SQL Server) then its likely that no-one will ever know it occurred!"
"The active portion of the log will also be used if a transaction rolls back, if crash recovery has to run, or when a transaction log backup occurs (plus a bunch of other uses like replication and mirroring – the aforementioned article has more information). If a damaged log record is encountered during one of these uses then an error will be thrown and the operation will fail."
"The only time a database will be marked SUSPECT because of a corruption in the transaction log is if the corruption is encountered during crash recovery or during a transaction rollback"
"If a corrupt log record is encountered during a transaction log backup, the backup will fail – but that’s all."
Work arounds:
"Switching the database to the Simple recovery model
Performing a checkpoint (which should clear the active log as long as nothing else requires the log to be kept active)
Switching back to the Full recovery model
Reestablishing the log backup chain by performing a full or differential backup"
"Of course, as in any corruption situation, make sure to do some root-cause analysis to figure out why the log became corrupt in the first place."