restore continues to fail 2

[Sonk]

We have been attempting a restore with little success. Two replacement rmt2 drives later...we still get the same results. The restore begins, appears to be doing well. until repeating lines fill the screen with an error. Processes slow to a near halt until we stop the restore. Our command line:
restore -xv -f /dev/rmt2 ./munis/munis.dbs/*

We have used this line successfully many times. Yesterday, when the second rmt2 was installed the microcode was updated. Could this be part of our problem?

 

[aixqueen]

what error message are you getting and how was the tape made...mksysb? tar?
What kind of tape drive...4mm 8mm ? This would help us ....

Microcode in my opinion should not cause the restore to fail....bad tape, blocksize changes, density changes yes......

 

[Sonk]

Tape was created with the backup command...not tar, nor cpio.
We have been attempting a restore from backup tapes for one week. We have had our rmt2 replaced, and then microcode updated by IBM. Still this morning our restore bombed out again, shooting off 180 dctrl processing in the process.

I have many questions and would appreciate some expert advice. Our goal: to use a 4mm tape from our backup rs6000 to restore a set of database files to one of the subdirectories on our primary rs6000. We have done this successfully in the past without any problems. This time we have tried the exact process with 2 different backup tapes (made on different days). Both tapes were brand new early in May and have been used only 3 times. They are Imation by brand...not IBM. I can see all the files clearly when I do a
restore -T -v -f /dev/rmt2
I am wondering if this is a microcode thing, or if for some reason our 4mm tape drive on the backup rs6000 is just not compatible with it's identical twin rs6000 primary server.

 

[PSD]

Sonk,

I would say looking at your commands as you can list the contents of the tape, in your restore command you use the ./pathname option are you sure that it is relative and not absolute. Also rather than use a wildcard i.e. * can you restore a single file? I would also add not use the * , instead use:

restore -xvqdf /dev/rmt2 ./munis/munis.dbs

N.B. the -d flag will create the sub-directories e.t.c.

Make a note of the block size via : lsattr -El rmt0
Change to variable i.e. 0 : chdev -l rmt2 block_size=0

I also believe that the microcode update should have no bearing on the restore.

Hope that helps


PSD
IBM Certified Specialist - AIX V4.3 Systems Support
IBM Certified Specialist - AIX V4 HACMP

 

[Sonk]

Correction:
When I let the restore -T -v -f /dev/rmt2 command run until it stops...it starts failing with the rolling error messages that indicate "damaged media"...just as it did when we attempted the restore for real.

Yes, when that command starts to run the files all have the ./pathname showing. We have been able to restore single files with no problem. (Luck, I guess)

I ran the lsattr -El rmt2 on both Primary and Backup servers and found them to match exactly with one exeption. The backup server was missing this entry:
ret_error no RETURN error on tape change or reset True

 

[aixqueen]

I have never had much luck with some brands of tape cartridges......
.It is possible that the IBM tape drives are not happy with the cartridges themselves.
or they really are damaged media.... If I had the luxury of doing the
backups again, I would try different IBM tapes to see if it makes a difference?

You say that you make the backup on one machine and try to restore on another..?
If the data on the tape is critical....and you cannot get IBM tapes and redo the backup. I would try to read in the machine that made it.....and see if you get the
same errors. If you don't and If the machines were network joined and
if the tape was ok in the machine it was created in....you could try to mount the
tape drive from the other machine and restore remotely.... until you could get
different data tapes...preferrably IBM tapes.........

 

[gileb]

It is important to use block size 0 like written in the first answers... because of variable length.
Also be sure to use the right rmt (i mean /dev/rmt0.1 , or /dev/rmt0.2 ...).