dump/dd/tar + gpg > tape = file write error

[User1001]

Thanks for the suggestion. Your "pipeline assumption" was correct.

I have an Exabyte SCSI-3 tape drive which is faster than most DAT
drives, so it is worth it to see if I can get "encrypted backups" to
work easily enough. Next - I will be experimenting with encrypting
backups via ISO (CD images), and will probably need a similar pipeline.


Bob Dunlop wrote:
> Hi,
> 
> On Fri, Sep 08 at 09:54, User1001 wrote:
>> When attempting to back up a filesystem with GPG to encrypt the stream,
>> the result (so far) has always been:
>>
>> gpg: /dev/sa0: write error: Invalid argument
>> gpg: iobuf_flush failed on close: file write error
>>
>> no matter what method (dump, dd, tar, etc.) was used to create the "dump
>> stream". It appears to occur only at the end of the "dump stream".
>> Different options for dd (conv=notrunc conv=osync) don't make any
>> difference. Using the "--batch" option for GPG doesn't make any difference.
>>
>> Is there a way to correct this (without creating any new files)?
> 
> It's difficult to know what you're actually doing without some example
> of the command pipeline you're using.
> 
> I'm guessing it's something like this:
> 
>   dd,tar,etc to create archive | gpg -e -r ID > /dev/sa0
> 
> If so the problem is that many tape device drivers are not the friendliest
> for standard applications to write to.  Drivers tend to be fussy about
> block sizes, have very primative seek capability if any and do strange
> things at EOF.
> 
> The trick I'd suggest is to use dd on the output side of gpg as a buffer
> for the tape mechanism.  You should need to do no conversion other than
> possibly pad the final block.  I'd also make sure the tape is rewound
> before you start.  Hence:
> 
>   mt -f /dev/sa0 rewind
>   dd,tar,etc to create archive | gpg -e -r ID | dd bs=4096 of=/dev/sa0 conv=sync
> 
> 
> ps. This is from memory.  The last tape drive I possess has been sitting
> in the recycle/spares pile for several years now.