Mail tapes, FTP indexes?

[UnixSkunk]

Hi, everyone...
Does anyone know a FAST way to be able to recover from a tape that has been moved from One Legato networker server to another one across the country?
We have a tape that was filled on the SOURCE machine. We shipped it to the DESTINATION server on the other coast. Does anyone know a way, other than scanner, to get the indexes for that tape on the DESTINATION server? Is there a way to FTP the client indexes? We have been scanning this LTO tape for over 30 hours, and its not done yet.
Included below is some of the output of the scanner -ivvv /dev/rmt1.1 command.
Many MANY thanks!

scanner: scanning fn 4(4) rn 8123(8123)
scanner: scanning fn 4(4) rn 8124(8124)
scanner: scanning fn 4(4) rn 8125(8125)
scanner: scanning fn 4(4) rn 8126(8126)
scanner: scanning fn 4(4) rn 8127(8127)
scanner: scanning fn 4(4) rn 8128(8128)
scanner: scanning fn 4(4) rn 8129(8129)
scanner: scanning fn 4(4) rn 8130(8130)
scanner: scanning fn 4(4) rn 8131(8131)
scanner: scanning fn 4(4) rn 8132(8132)
scanner: scanning fn 4(4) rn 8133(8133)
scanner: scanning fn 4(4) rn 8134(8134)
scanner: scanning fn 4(4) rn 8135(8135)
scanner: scanning fn 4(4) rn 8136(8136)
scanner: scanning fn 4(4) rn 8137(8137)
scanner: scanning fn 4(4) rn 8138(8138)
scanner: scanning fn 4(4) rn 8139(8139)
scanner: scanning fn 4(4) rn 8140(8140)
scanner: ssid 1295730946: 164 MB, 1078 file(s)
scanner: (ssid 1295730946) cds10114:/usr/orasys/clnt817/bin/wrapO off 165189192, size 3113808
scanner: (ssid 1295730946) cds10114:/usr/orasys/clnt817/bin/wrapO @ time 1062026413 not found in index
scanner: scanning fn 4(4) rn 8141(8141)
scanner: scanning fn 4(4) rn 8142(8142)
scanner: scanning fn 4(4) rn 8143(8143)
scanner: scanning fn 4(4) rn 8144(8144)
scanner: scanning fn 4(4) rn 8145(8145)
scanner: scanning fn 4(4) rn 8146(8146)
scanner: scanning fn 4(4) rn 8147(8147)
scanner: scanning fn 4(4) rn 8148(8148)
scanner: scanning fn 4(4) rn 8149(8149)
scanner: scanning fn 4(4) rn 8150(8150)
scanner: scanning fn 4(4) rn 8151(8151)
scanner: scanning fn 4(4) rn 8152(8152)
scanner: scanning fn 4(4) rn 8153(8153)
scanner: scanning fn 4(4) rn 8154(8154)
scanner: scanning fn 4(4) rn 8155(8155)
scanner: scanning fn 4(4) rn 8156(8156)
scanner: scanning fn 4(4) rn 8157(8157)
scanner: scanning fn 4(4) rn 8158(8158)
scanner: scanning fn 4(4) rn 8159(8159)
scanner: scanning fn 4(4) rn 8160(8160)
scanner: scanning fn 4(4) rn 8161(8161)
scanner: scanning fn 4(4) rn 8162(8162)
scanner: scanning fn 4(4) rn 8163(8163)
scanner: scanning fn 4(4) rn 8164(8164)
scanner: scanning fn 4(4) rn 8165(8165)
scanner: scanning fn 4(4) rn 8166(8166)
scanner: scanning fn 4(4) rn 8167(8167)


UnixSkunk - Tux's Evil Nemesis

 

[605]

As there is no reference in the DB at DESTINATION, you only
have one choice: scanner.

However, you must not use "scanner -i". Use "scanner -m"
and then recover the save set(s) to a temporary location.

 

[UnixSkunk]

Hi, 650, and everyone....
Thanks for the info. Nobody knows a way to move the indexes for a set of tapes/clients from SourceServer to DestinationServer? I'm willing to FTP it to the Destination server... I just want to be able to restore a client's data that was backed up on the SourceServer, using the DestinationServer.
Can you Backup a client to tape on SourceServer, then snailmail the tapes across the country to DestinationServer, and FTP the client's indexes from SourceServer to DestinationServer....Somehow install the client indexes for that specific client...and restore from the tapes you made on SourceServer, using DestinationServer(And the client's Indexes you FTP'd)?

Many thanks!!


UnixSkunk - Tux's Evil Nemesis

 

[605]

The client index in fact is not the problem - it is the
media index. You could in fact copy/ftp the index files for
that client, but how do you tell the media db about it? -
The only way to do this is right now is scanner.

But heads-up! Assuming you have configured the correct
block size for the device (be careful if you exchange media
between UNIX and Windows machines), it can be done using
scanner as long as you follow some guidelines:

1. You have to create the "source" client on the destination
server. To be able to do this NW has to resolve the name
to an IP. Worst case, fake your system with the hosts
file.

2. Make sure that the block size is the same.

3. Scan the media.

4. You now can recover to another client of the same OS.

 

[UnixSkunk]

605, you are my god and savior....
I'm curious. what happens if the block size on the device is NOT the same size? I've got another problem(As I mentioned in another post, I'm running scanner -i and its torturously slow) and I was wondering if this could be the cause of it. Its sort of what caused this post's question to be brought up. The block size on the source LTO drive is 64, and the block size on the LTO device I am using to scan is 128.

UnixSkunk - Tux's Evil Nemesis

 

[UnixSkunk]

Oh, also, then the tape from the 64K machine is moved to the Destination 128K block size machine, the device downshifts to 64K to match the tape...I figured this would keep the block sizes from being a problem.


UnixSkunk - Tux's Evil Nemesis

 

[605]

Thanks for your enthousiam but please calm down ;-)

As the block size is stored within the label, you can verify
it after you have read it.

If the block sizes for the devices do not match, then it
should adapt during a read process (old tape drive behaviour).

The major problem is when you move a tape with a block size
>64kB to a Windows machine. Reason for that is that most
Windows SCSI drivers cut the transfer after a 64kB block.
You need to patch the registry to support larger block sizes. Have a look in the "Performance Tuning Guide", it
tells you in detail how to do that.

The output from your first message looks fine - the only
thing i would not have done is using this verbosity - there
is a message with each block that also slows doen the
process. However, besides this, it is hard to tell why it
takes that long without actually being at the system.

 

[UnixSkunk]

Hello again, 605...
When you've been lacking someone to provide information about this for as long as I have been...ANyon willing to help is wonderful.

Each of these messages:
scanner: scanning fn 4(4) rn 8123(8123)
shows up, at 1 per second(no exageration). I moved one of these tapes back to the original, Source Server, and ran a scanner -i, and it worked fine. The tape scanned in under an hour.

The source machine is a Solaris Legato Server, and the Destination server is an AIX Legato server.

UnixSkunk - Tux's Evil Nemesis

 

[605]

The message just logs every file mark (fn) and record number
(rn), i think for the expected and the found values. That's
why it takes so long - extensive reporting may slow it down.

 

[UnixSkunk]

Thanks again, 605. I was wondering what each of those messages mean. In the end, my boss finally did what I originally suggested, and had a server built with an old DLT, and LTO drive we had laying around, to be used solely for these restores....It looks like we'll be doing the scan/restore thing pretty often.
Thanks again!


UnixSkunk - Tux's Evil Nemesis