multi tape option in tar cmd

Dear experts,

I have to take back up of 1.8TB data in single cmd. I have tape which has the capasity of 600 GB. Hence i want to use multiple tapes to take the backup using tar cmd.

Kindly help.

-Anand

Hi,
Unfortunately tar does not support splitting of archive.
You have to do this by hand, using split (man 1 split)

split -b600GB in out.

This produces volumes of 600GB.
Notice that with "GB" we mean decimal GB (10^9), while -b600G would mean binary GB (GiB, 2^30).

Alternatively:

split -n3 in out.

Chops file to three pieces.

Then, at restore, join them with:

cat out.*>restored

ps: Never used a tape. I assume that with backup software you can put the out.aa out.ab etc each of them to one tape. Don't try to untar them while chopped!!

If your version of tar can read from stdin, you can do something like this to avoid storing hundreds upon hundreds of gigabytes of temporary files:

# create tapes
mkfifo tarfifo
tar -vcf tarfifo /path/to/files &
PID=$!
N=0
while [ -d /proc/${PID} ]
do
        printf "Insert tape and hit enter " >&2
        read < /dev/tty # Read from terminal, not tarfifo
        dd of=/dev/tape bs=<tape_blocksize> count=<tape_blocks>
        eject_tape
        N=`expr $N + 1`
done <tarfifo

# extract tapes
mkfifo tarfifo
N=0
while [ -z "$INPUT" ]
do
        dd if=/dev/tape bs=<tape_blocksize> count=<tape_blocks>

        eject_tape

        # Print to stderr, so we don't feed this message into tar!
        printf "Insert tape and hit enter " >&2
        read INPUT
        N=`expr $N + 1`
done | tar -C /path/to/dest/ -xvf -

You could test this with local files instead of tapes by replacing /dev/tape with /path/to/file$N and using a small blocksize and blockcount.

Haven't thought of using dd to tell the truth.
But that's really tough to understand.

Can I propose

dd if=bigfile of=/dev/tape bs=600GB count=1 skip=0

and increase skip by one each iteration...

While restore:

dd if=/dev/tape of=restore bs=600GB count=1 seek=0

and increase seek by one

Of course instead of bs=600GB you can simply bs=1MB but then seek or skip will be by n*600000

You only get to do bs=...G if you have GNU dd.

Advertised tape sizes are very often inflated. We don't know his tapes actually are 600GB, i.e. whether that means real gigabytes or drivemaker's gigabytes, uncompressed or with theoretical max compression, etc. The only way to be sure of that is to use the capacity in blocks as defined by the manufacturer.

Blocks versus bytes is grade-school math, 1024 bytes is two 512-byte blocks...

You are correct. I googled it and it's SDLT II 300GB real (2:1).
And of course it's drivemakers GB Only RAM chips is "real"

Hard drives, cdroms, dvd's, and other media still come in units of powers of two -- they have to talk to computers, they could scarcely be anything else! They have sector sizes of 512, 2048, or 4096 bytes, not 500, 2000, and 4000. They're just advertised in powers of ten to make the number bigger.

I dread the days when they figure out how to make arbitrary sizes of RAM. They've already done it for flash media, somehow. Then RAM'll start shrinking too, no doubt.

Yes, of course sector sizes are 2048 for cdroms, but that can be also said for hard drives, which are 512 bytes.

What I wanted to say is that 4.7GB dvds are 4.37GiB and 25GB Blu Rays are 23.3GiB.

But what made my laugh is that:

Taken from Western Digital's web site.
MB of hard disk = 1,000,000B
MB of cache = 1,048,576B
Go figure!

Anyway, I just recalled that the user @nithyanandan wanted to store a tar file (uncompressed) to the tape, thus he will utilize the tape drives compression features, so my code is useless since I can't predict the chuck size that will be compressed to fit perfectly on the tape.

Speaking tape drives: Most say compression is 2:1. I've heard a 2.4:1. But today I saw a 3:1 IBM Magstar MP 3570 - Wikipedia, the free encyclopedia !!
I mean why don't they test zero filled files so they can achieve a 1million:1.

Unless you're dumping raw text, the compression you get will be marginal; nothing really impressive can be done with hardware-on-chip compression. Of course you know this, I'm making it clearer for the OP... Best to underguess and not hit the end.

If you want compression, use tar -zcf. This will make it difficult to recover from tape errors, however.

I'm unclear on whether you lose data when you hit the end of a tape or not -- i.e. when you hit EOF have you already written a sector or three that won't get read back? So it's safest to underguess in any case.