[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 487
  • Last Modified:

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?
0
jmarkfoley
Asked:
jmarkfoley
1 Solution
 
James0628Commented:
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 .

 James
0
 
pjedmondCommented:
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/

or

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

for the tar.

HTH:)
0
 
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.
0
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
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.
0
 
James0628Commented:
duncan_roe,

 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.

 James
0
 
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!
0
 
James0628Commented:
> 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.

 James
0

Featured Post

The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now