Re: [Dump-devel] rmt restore does not work

[Phillip S. <ph...@th...>]

So the problem seems to be not specific to rmt, but to compressed tape
backups.  Even if you are using a normal file via rmt, dump treats it
like a tape and calls readtape_comprtape instead of readtape_comprfile.
 The latter reads the first 4 byte header of the block first to decide
how long the block actually is on disk, then reads that many bytes.  The
latter reads a fixed length of the uncompressed block size + the 4 byte
header, which causes it to consume far more than a single block and so
when it goes to read the header for the next block, it's actually
reading some random data from the wrong location in the file.

Has nobody ever tried using compression with a tape or rmt before?  I
can't believe nobody has found this bug long before now.

On 4/5/2019 9:30 AM, Phillip Susi wrote:
> psusi@devserv:~/dump/rmt$ restore -i -b 1024 -f devserv:/backup/dump.0
> Connection to devserv established.
> Dump tape is compressed.
> short compressed block: 1048580 expected: 198244065
> decompression error, block 2049: length mismatch
> Tape decompression error while restoring <directory file - name unknown>
> continue? [yn] n
> 
> It appears that in Ubuntu rmt is provided by both the tar and dump
> packages, but the tar version appears to be a straight copy from the
> dump package, and switching to the version from the dump package gets
> the same result.  tar is able to use rmt just fine.
> 
> Neither of the numbers listed appear to be correct.  The block size
> should be 1048576 bytes, not 1048580... not sure why there are 4 extra
> bytes there, and I have no idea why it thinks it is expecting the insane
> 198244065 bytes.