copy whole backup file from SCSI tape

I have a SCSI tape setup on my Linux 2.4.29 system. I do daily backup like: tar -czvf /dev/tape /

I can save and restore, no problem. What I want to do is copy the tar file from the tape to the disk drive without restoring it. I've tried:

cp /dev/tape bu.tgz
cat /dev/tape >bu.tgz
cat </dev/tape >bu.tgz
cp -b /dev/tape bu.tgz

none of these work. I get: cp: reading `/dev/tape': Input/output error

What is the correct syntax?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

dd should do the trick.  Something like

 dd if=/dev/tape of=bu.tgz bs=10k

 bs specifies the BlockSize.  I'm not sure about Linux, but traditionally the default blocking in tar was 20 512-byte blocks, or 10 KB.  FWIW, a larger block size might improve dd's performance, but I'd stick with the same blocking that tar used when writing to the tape.

 I've never played with the compression option on tar.  I thought (assumed) it compressed the files in the tar archive, as opposed to the archive itself.  FWIW, if the archive itself isn't compressed, I'd use .tar for the archive file name, instead of .tgz .


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
tar -tzf /dev/tape

should list the files in your archive.

tar -xzf /dev/tape /new/location/

will copy the files from the tape to /new/location

If you want just the tgz file, then I would

tar -f /dev/tape /new/location/


tar -xf /dev/tape /new/location/

for the tar.

Duncan RoeSoftware DeveloperCommented:
Yes, bs is the catch with tape. It has to be the same as specified or defaulted on the tar command line. Since you don't give tar a -b arg, the block size will be the default that your tar was built with - most likely 10k as James0628 says but you can verify this with "tar --help" - check the 3rd-last line. Mine looks like:
   *This* `tar' defaults to `--format=gnu -f- -b20'.
i.e. 20 512-byte blocks = 10k
BTW I always use -b126 when doing tar to SCSI tape - seems to go faster than anything less or more. I got that hint from a *very* old Solaris post - it seems to hold good under Linux though.
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

Duncan RoeSoftware DeveloperCommented:
SCSI tape drives tend to use their own compression, so I wonder if you should be using tar's z option - I never do to SCSI tape myself. That way, tar has some chance to recover after a tape error.
You will indeed get a .tgz from your dd copy - tar's z option pipes the output from tar through gzip so the whole archive is compressed.

 Thanks for the clarification on tar's compression option.  Like I said, I haven't used it, so I wasn't sure.

 I agree that if the tape drive does compression, it might be better (faster, "safer", etc.) to leave the z option off of tar and just let the tape drive do the compressing.  I hadn't thought of that.  Good point.

jmarkfoleyAuthor Commented:
I've been doing SCSI tape backup on Linux for many years (I've just never tried to dump the raw tar file before). FYI, even though the drive does compress, the z option compresses more. I've left off the z option in the past and have had backups not fit on the tape. So, the z option helps. duncan_roe is correct in that not compressing a tape does let tar recover from tape errors by bypassing the bad files. With compression, tar can recover up to the point where the tape is bad, then you're hosed. For this reason I always verify the tape by doing a tar -tzvf out to a table-of-contents file after the backup.

James0628's dd suggestion worked just fine. I did change it to:

dd if=/dev/tape ibs=10k >bu.tgz

for no particular reason except that it was taking a really long time with the suggested syntax with no file being created on the drive. I thought something was wrong. The behavior was still the same with my syntax, so I guess dd doesn't create a viewable output file until it's done. I did use duncan_roe's tar --help suggestion to determine the block size. Since I'm not trying to uncompress I was hoping the dd dump would go faster than a restore (since I mainly want to transfer this file to another machine, not restore), but it really doesn't:

tar -cvzf save time: 2hr 43m
dd dump time: 2hr 20m

So skipping tar's extraction, decompression only saved 23 minutes.

Thanks all!
> FYI, even though the drive does compress, the z option compresses more.

 That makes sense.  If the z option compresses the whole archive at once, or even if it's just individual files, it should generally compress much better than a tape drive, which, I believe, usually compress smaller packets of data (at least the ones I'm familiar with).

 I don't know why you couldn't see the output file as dd was creating it.  Sounds odd, but whatever.  As long as you got the file in the end, I guess.  Glad I could help.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.