dump | restore fails: unknown tape header type 1853384566

[Hywel Mallett]

Quoting Dimitry Andric <dimitry at andric.com>:

> On 2009-03-24 07:30, Mikhail T. wrote:
>>     dump a0f  - /old | restore -rf -
>>     [...]
>>       DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>>       DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>>       DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
>>     unknown tape header type -621260722
>>     abort? [yn]
>>
>> Looks like a junk value somewhere... Unitialized variable or some such.

Looking at the restore code (tape.c, in findinode), restore is  
expecting a header type in the range 1-6, so the header type  
-621260722 is way out. Assuming that findinode is being passed the  
correct variable, it would indicate that dump is writing the header  
(or at least the header type incorrectly). I can't work out where this  
header is getting written though. It looks like plenty of data gets  
written into a header (such as inode, magic number, checksum). I  
wonder if one of these values is overflowing and overwriting the  
header type?

>
> Maybe the dump output gets corrupted in some way?  (E.g. faulty RAM, or
> disk?)  If you are dumping a live filesystem, could it possibly help to
> add the -L option?

It might be worth fscking the original volume (though I suspect the OP  
has done this already), and also passing the -D option to restore, as  
restore will then try and continue, rather than abort on getting the  
invalid header type. Fixing the root cause would be better, but that  
might be a workaround for now.