Quote:
Originally Posted by bakunin
First off, (depending on the type of your tape drive) you have a pretty good chance of not needing any compress at all because most of the IBM tape drives have a hardware compression built in. If you send a compressed stream down to the tape drive it will be compressed a second time which will usually make the file a little bigger (because of the second compression overhead adding), not smaller.
Second, even if it is justified using "compress" in your case, you probably have to add "if=-" to the "dd" command. AFAIK "dd" doesn't use stdin per default for incoming data. It also might be necessary to state the blocksize. Use "bs=<some number>" in this case to state the block size in bytes.
A third reason might be that you have to adress the tape drive with another device number, maybe "/dev/rmt0.1". Have a look in the manual for the meaning of the minor device numbers with tape drives.
I do not recognize your first statement "change tape block_size=512", usually this is accomplished using the "tctl" command, alternatively use the "chdev" command on "/dev/rmtn".
I hope this helps.
bakunin
|
I know the client's tape drive are using built in compression. But the problem is that is taking toooo looonnnggggg. Backing up a 10Gb folder's content takes 5 hours. The procedures we use to do the backups (10 database backups between averaging 8Gb spreaded amongst 5 servers with each only one tape drive) have us verify the tapes after we have done the TAR backups. Do do all of this takes 18 hours ! I want to reduce this time as much as possible with 2 ways where one way is using compression before putting on tapes. Using local compression on disk takes 2 hours per DB backups. That is why I was trying to compress to tape using piping.
I'll check the if=- and bs= options.
As for the "/dev/rmt0.1", its probably it. I have seen this in other backups types we do.
The blocksize change command was just a summary of what I did before doing the DD. It is actualy a chdev.
