It is possible to detect such errors using backup checksums.
If you use the CHECKSUM option, then yes it should be found but only when using a
RESTORE ... WITH VERIFYONLY. If you don't check it, you'll never know.
But what do you do when an error is found?
That depends on what is wrong and where it happened. The action to be taken first is to make sure your entire restore sequence is still valid and can be actioned. The second is to figure out what caused the corruption and potentially move to different storage, drivers, etc. In this case, chances aren't that great that it will happen very often if at all.
If a log backup is corrupted the log backup chain is broken.
This may or may not be true depending on your restore strategy. If you have a differential to bridge the gap, that's perfectly valid and you can still use the other log backups that occur after it. If you're extremely worried about single bit flip in a log backup, mirror the log backups to another storage solution.
If it is a full backup depending differential backups are now
unusable. A new full backup is needed in order to restart the usual
You're correct on the first part and I don't know what you are considering the "usual" backup schedule. If you have the log backups, you can continue to roll forward through the bad full and covering differentials. You're definitely going to want more than a single recovery sequence.
What can be done to avoid losing backups randomly due to spurious data
Mirror your backups, for starters. Have more than a single recovery sequence. Check the backups and take action when something does go wrong so that you're not exposed to risk. Disks die, things go wrong. While it shouldn't be happening often, it will most likely happen to you at some point or another in your career. Having a good restore and backup strategy to take care of this is what will help.