Last week we discovered that our weekly backup had failed. The only clue we had was the return code 0x1f. There were no log files, or messages in any of the event logs.
It was already the second time this had happened, but the first time the return code was 0.
After some googling I discovered that the return code can sometimes be 0, even if there was an error. So that might explain why I got that the first time. Then I also discovered that 0x1f seems to be a very generic error.
I read a lot of articles, but finally found the reason buried deep in this Microsoft KB article:
If you use the /um option, it is recommended that you not use the /n option to label the media. Instead, permit Ntbackup to use the default date/time as the label name and description. This eliminates the problem of multiple tapes' having the same label name, which can cause RSM to ask for a manual tape mount and prevent Ntbackup from continuing to completion unattended.
The tape names and description were all unique, but the tape label was simlpy 'Weekly DCS Backup'.
The reason we didn't notice this earlier is that I remove the tapes in time. Only last week I was importing some older tapes to retrieve old data, and the tapes were still in the loader, thus causing a label name conflict.