Log Shipping Backup Successful Restore Errors
Tricky to answer without more info. 


There are many reasons why there may be a disk issue that doesn't actually cause the backup to fail. 


Have you got any errors in the log related to disk activity? Have you tested those log backups yourself? 
Can you try restoring them all manually to a test environment and checking database inegrity after if it succeeds? 
For that matter, do you dbcc checkdb regularly (apologies if this is obvious, just worth mentioning). 
It's tricky answering this part of the question without more info. -




Addendum:
Researching that error seems to only ever point to a version mis-match, but that seems implausible if it's only happening once and all the other backups usually work fine. Worth checking this and asking the question - are both primary and secondary on exact same versions? How often does this happen?
This sqlservercentral goes into this.

This earlier stackexchange post is similar, and suggests the same thing. Ruling out the version problem (which from what you've said I'm assuming it's not), then the other points are pointing to corruption.

Just to check again, how often has this happened and how long have you been using this configuration? 

If CheckDB is successful on your database, log shipping has been in place a while and this usually runs fine and this is the first such failure, I might be tempted to put it down to a fluke (I know, not ideal) unless you can find anything more out or someone else weighs in.




Short answer is yes. 


Take a differential backup and restore that to the secondary. Brent Ozar has described how to do this.


Even shorter answer - no. 


A log backup is a very specific thing, once the backup is complete, the log is different (and ever changing). There only way to do anything point-in-time is with log backups. If you need reading material, Paul Randal has a nice article on Technet that goes a bit into how different backups actually work (and it's fairly accessible/not too long).