Hello,

Due to a hardware crash we are in the following situation:

The last valuable DUMP(s) are on tape, but the tape drive can not be mounted
on a new Linux server. The old server only boots a Linux live system and we
can read the tape, for example with dd(1) command to disk. We would like to
transfer this DUMP from the tape either directly to disk to RESTORE it on
the new server with the backup server, or to create there a new tape on
another tape drive (again with dd(1)) to be used for RESTORE.

What is the exact layout of a DUMP on a tape? Are there more than one TM,
for example for some header before the DUMP starts? Any idea or known
procedure? Thanks in advance

Matthias

On 18/5/10 13:20 , rebelde wrote:
I think it's safer just to install a backupserver on that machine with
the tapedrive.

species8472 wrote:

It seems that it is problematic to install enough Linux and ASE on the old
machine and the tape does not fit in the new server (no SCSI);

would it be an option to create on the new server a pipe device and do:

load database foo from '/home/foo/mypipe'

and punch the tape via SSH from the old server into the pipe with:

cat /dev/rmt/0cn | ssh newserver cat > /home/foo/mypipe

Thx

matthias

On May 18, 5:20*am, rebelde <g... (AT) unixarea (DOT) de> wrote:
The following set of instructions is quite old (I ran across it
sometime before 2002
and included it in a CR I filed at the time.).
I think they will still work though, but don't be shocked if they
don't - I can't recall the
last time I actually used it.

They were actually a workaround for the problem that arises when
multiple dumps are saved with the same name to one tape - when loading
a dump by name,
ASE will always load the first one on the tape - but is applicable to
your
issue as well

When you dump a DB on tape, you will have in fact 3 "files" on the
tape
for each dump, one for "header", one for "data" and one for "trailer/
end".

So if you have dumped 20 times a DB on your tape, you would have 20*3
files on the tape. If you want to reload the last (20th) one (and gave
the same name for each
dump), you would have to build a new tape.


1- get the first "header" (that is different than next header)
% dd if=/dev/rmt/0lbn of=/tmp/header01 bs=2048
where 'if=' is the name of his tape device without rewind on close
(letter 'n' in '0lbn') and where 'bs=' is the block size. I put 2048,
because I have used
this value duing my dump command.
2- skip the rest of the first dump
% mt -f /dev/rmt/0lbn fsf 2
where 'fsf' is to forward the tape and '2' is to do it 2 times.
3- skip dump #2 to dump #19 (exemple in csh)
% foreach i (2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
? mt -f /dev/rmt/0lbn fsf 3
? end
where 'fsf' is to forward the tape and '3' is to do it 3 times.
4- skip the "header" of the wanted dump.
% mt -f /dev/rmt/0lbn
5- get the "data" of the wanted dump
% dd if=/dev/rmt/0lbn of=/tmp/data20 bs=2048
6- get the "trailer" block of the wanted dump
% dd if=/dev/rmt/0lbn of=/tmp/trail20 bs=2048

now with theses files, build a new tape : (dont use the same tape, in
case of ...)

1- rewind the tape (to be sure)
% mt -f /dev/rmt/0lb rewind
2- copy the "header" onto the tape :
% dd if=/tmp/header01 of=/dev/rmt/0lbn bs=2048
where 'bs=' is the block size, customer may adjust this value.
3- copy the "data" onto the tape :
% dd if=/tmp/data20 of=/dev/rmt/0lbn bs=2048
4- copy the "trailer" block onto the tape :
% dd if=/tmp/trail20 of=/dev/rmt/0lbn bs=2048
5- rewind the tape
% mt -f /dev/rmt/0lb rewind


Adjust as needed for which dump you need from the tape. In summary,
you need the
*first* header off the tape, and the nth data and nth trailer for the
nth dump.

I hope it works.

Cheers,
-bret

Bret_Halford wrote:

Bret,

Thanks for all the information you gave us. It is more or less what I was
expecting (having more than one TM or 'file' on the tape for each DUMP).
One last question concerning the blocksize: what is the default if one does
not specify it while dumping? the ASE's page size?

Thanks again

matthias

On May 20, 1:36*am, rebelde <g... (AT) unixarea (DOT) de> wrote:
I think 2048 should work in general - the page sizes are all multiples
of 2048.

-bret