vdump to two tapes

[Alexey Borchev]

I am making backups with vdump and thinking of hving two copies at one go onto 2 streamers in parallel.

The purpoce of the exercise:
1) Tape & streamer failures does happen.
2) 1-st copy send offsite (Disaster) 2-nd copy store local in my hands.

I am thinking of:
#vdump -f - /usr | tee /dev/ntape/tape0_d1
> /dev/ntape/tape1_d1

If anybody tried such dirty tricks?

[Michael Schulte zur Sur]

Hi,

interesting idea. Read once, write twice. I am going to test it. For good performance the two tapes should be connected to different controllers.

greetings,

Michael

[Orrin · Accepted solution]

Hi Alexey,

Tried it.

Had problems got an I/O error on the second run.

Tried the same with an advfs clone, works a charm.

ie.
clonefset usr_dmn usr_fset clone_usr_fset

then

mount -t advfs usr_dmn#clone_usr_fset /clone_usr

vdump -f - /clone_usr | tee /dev/ntape/tape0_d1 >/dev/ntape/tape2_d1

Restore works fine!!

Regards,
Orrin.

[Erich Wimmer]

Don't trust these backups.
vdump normally reads/writes with 64k blocksize on tape. I don't know what blocksize tee is using, the stdout part of tee (tee ... >/dev/tape) uses 8 k block size, I know. This may also be the reason why once get i/o error on tape.
Why not simply starting 2 times vdump ?

[Michael Schulte zur Sur]

Hi,

Why not simply starting 2 times vdump ?
Because they won't be identical and would use twice the resources in regard to cpu and disk I/O.

Michael

[Alexey Borchev]

Mihael, if You will do testings - please post results!
I do not have two stareamers on hands currently to test it. But streamers are cheap.
Unfortunately, I cannot afford two separate SCSI controllers ;-(( - No PCI slots left.
However, system reads from disk @ 20 MB\sec,
and SDLT320 device has 40 MB\s bus.
I hope it will be OK.

Orrin, Thank You very much for Your opinion!
I do not have advfs utilities licence, but probably HP will sell me one.

Erich Wimmer, thank You for 8-kb block size standard output limitation!
Maybe,
| tee , > /dev/null
will do the trick? According to man, tee can do up to 20 output files - looks enough :-)!

[Abdul Rahiman]

Hello,

I am still planning to test your command as soon as I have couple of drives available.

Btw, another idea to make a clone tape, may be use 'tcopy' to make a clone copy of the tape created by a regular vdump..

regds,
Abdul.

[Erich Wimmer]

Alexey,
looking deeper into tee it looks like the following:
The maximum buffer size within tee is 8k/bytes, writes are using the same record size as read() returns. So you will never get more than 8k records, also if using instead of stdout. If using stdout, you can pipe it to "dd" to reach a greater recordsize, f. e.
"tee /dev/ntape/tape1 |dd of=/dev/ntape/tape2 obs=256k", but tape1 gets only 8k at maximum. 8k tape blocks are wasting space on tape and increases the backuptime exponential. Therefore "tee" is not applicable for tape backups.
You will see this behavior if tracing the read() write() systemcalls.
Greetings, Erich.

[Alexey Borchev]

OK, I see the problem with 8k buffer size in tee ;-((
Let's hope HP will increase the buffer in future releases - this looks like not very difficult task.

I expect to have streamer soon and have a look at this.

One more question:
if one of two streamers will fail during backup, will vdump|tee continue or stop?

[Erich Wimmer]

Alexey,
I believe vdump|tee continues but:
the tape driver makes x retries if the block cannot be written, then tee will be notified about a write error, tee writes the next block in sequence (so the defective block has been lost) and so on. If from this position on the tape is defective to the end, you have no chance to change the tape media, except killing the whole backup.
Greetings, Erich