Tar/Tapes: Can somebody explain this to me......

TheDirtyPenguin · 03-08-2004, 09:32 AM

Hey Folks,

Can somebody please explain what the crack is with this problem.

I have a backup folder in /var which contains 4 rsync'd server folders:

server08
server15
server16
server18

They all contain the etc folder from the server, and other important data I need to backup.

To send them to tape I have been using: (cd'ing to /var first)

tar -cv -b 16384 -f /dev/nst0 backup/ > /var/log/backup/tapebackup/BACKUP_`date +%Y%m%d`.log 2> /var/log/backup/tapebackup/BACKUP_`date +%Y%m%d`.log

Now, according to my logs, the backup went fine and everything went to plan.

However, If I do a

tar -t -b 16384 -f /dev/nst0

To list the contents of the tape, it firstly says

tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers

And then it goes on to list the contents of the tape. However, it does NOT list the server15 folder and all its contents, and misses out some of server16

Now according to my backup logs, they backed up in the following order:

server15
server16
server18
server08

And when I list the contents I get:

Half of server16
server18
server08

And no server15. How come? Its driving me nuts! Does anybody know what I am doing wrong? Why are they backing up in that order? And whats happened to my server15!?!?

Thanks for any help!

P.S. This has been driving me nuts for weeks now. If I cant get it working I will have to give up on using tar and try using cpio. However cpio scares the hell out of me, and if anyone could give me a quick run down on how I would put together a cpio command for the above I would be forever grateful

ac1980 · 03-08-2004, 04:03 PM

Don't want to be rude, but are you sure the tape does not have a non-writable pre-gap?
Or maybe the block device expects some command bytes after being opened for writing. Remember with such a blocksize, a single lost byte at the beginning will result in 8Mb unreadable data.

What I'd do is make /dev/tape a symlink to /dev/nst0, and then run tar without -f option. After all, tar was designed to run with tapes.

As a (ugly) workaround, you can decrease block size to, e.g., 2048, and tell tar to backup a placeholder 1MB file before the backup directory:

Code:

dd bs=1024 bc=1024 if=/dev/zero of=/tmp/vanumspatium
tar -cv -b 2048 /tmp/vanumspatium /var/backup/
rm /tmp/vanumspatium

TheDirtyPenguin · 03-09-2004, 03:47 AM

Thanks for the help!

I'm erasing the tapes now and I'll try reducing my blocksize (I have no idea how I came to that number anyway!)

I'll also try creating a symlink as you said.

Could you explain what creating a 1mb placeholder will do? It looks pretty cool but I'm not sure what it will do!

I'll let you know how I got on

Thanks again.

ac1980 · 03-09-2004, 04:37 AM

Quote:

Could you explain what creating a 1mb placeholder will do? It looks pretty cool but I'm not sure what it will do!

That's not cool, it might be a patch if nothing else works.
I assume for some reason I don't know, a few bytes at the beginning of the stream get lost, so the first block is practically unreadable due to missing headers. If you can't fix this, at least you should ensure what you lose is not valuable data. The actual block size is (what you specify with -b)*512 bytes

It's been a while since I worked with tapes, however I think if you let tar know it's writing to a tape (by removing the -f option) it should work. Refer to tar manpage.