Problem with ndmp restore

[140670]

Hello,

I try to restore a file from a filer save tape and i've got some errors message!! here is the command line i use and the error message :

C:\win32app\nsr\bin>recover -s i04mb167 -c nas1
/C/win32app/nsr/bin/ not in index
<return> will exit.
Enter directory to browse: /vol/vol0/services
recover: Current working directory is /vol/vol0/services/
recover> cd DSI
recover> cd &quot;HEAD OF IT&quot;
recover> cd Prestataires
recover> dir
total 256
01/06/03 10:28 AM 78848 IT_Staff_PARISmodif1.xls
recover> version

Versions of `/vol/vol0/services/DSI/HEAD OF IT/Prestataires/':

256 d--------- <unknown <unknown 8192 Jan 21 16:23 Prestataires/
save time: Wed Jan 22 04:54:16 2003
location: 00000612 at Exabyte, 00000615 at Exabyte

256 d--------- <unknown <unknown 8192 Dec 27 11:00 Prestataires/
save time: Tue Jan 21 04:42:56 2003
location: 00000610, 00000608

256 d--------- <unknown <unknown 8192 Dec 27 11:00 Prestataires/
save time: Fri Jan 17 02:02:49 2003
location: 00000604, 00000606

256 d--------- <unknown <unknown 8192 Dec 27 11:00 Prestataires/
save time: Tue Dec 31 15:30:55 2002
location: 00000650, 00000655, 00000653, 00000651

256 d--------- <unknown <unknown 8192 Nov 25 10:04 Prestataires/
save time: Fri Dec 20 18:00:41 2002
location: 00000636, 00000637, 00000640, 00000642 at Exabyte

Display more versions of `/vol/vol0/services/DSI/HEAD OF IT/Prestataires/' [y]? y

Versions of `/vol/vol0/services/DSI/HEAD OF IT/Prestataires/' earlier than Fri Dec 20 18:00:41 2002:


256 d--------- <unknown <unknown 8192 Nov 25 10:04 Prestataires/
save time: Thu Dec 19 18:00:40 2002
location: 00000631 at Exabyte, 00000632 at Exabyte, 00000633 at Exabyte, 00000634 at Exabyte

recover> changetime
current save time is Thu Jan 23 07:25:21 2003
<return> leaves save time unchanged
new save time: 12/20/02 18:00:40
time changed to Fri Dec 20 18:00:40 2002
recover> dir
total 1280
x&quot;ú
x&quot;ú
11/15/01 05:38 PM 78848 IT_Staff_PARISmodif.xls
07/09/02 04:38 PM 47616 Suivi_prestataires.xls
11/27/02 01:36 PM 55296 Suivi_prestataires_2002.xls
recover> add Suivi_prestataires_2002.xls
1 file(s) marked for recovery
recover> recover
Recovering 1 file into its original location
Volumes needed (all on-line):
00000631 at Exabyte
00000632 at Exabyte
00000633 at Exabyte
00000634 at Exabyte
Requesting 1 file(s), this may take a while...
Direct Retrieval.
Open the tape device : nrst0a
NDMP Service Log: RESTORE: Bad header block.

NDMP Service Log: RESTORE: Could not initialize media.

NDMP Service Log: RESTORE: RESTORE IS ABORTED

******************************************************************
------ E R R O R -------
Data server halted: Dump aborted
******************************************************************
******************************************************************
------ E R R O R -------
NDMP data server has an internal error.
******************************************************************
******************************************************************
------ E R R O R -------
Error during File NDMP Extraction.
******************************************************************
Close the tape device.
******************************************************************
------ E R R O R -------
NDMP recover failed.
Following files could not be retrieved
services/DSI/HEAD OF IT/Prestataires/Suivi_prestataires_2002.xls
******************************************************************
******************************************************************
------ E R R O R -------
Error during NDMP recover.
******************************************************************
ERROR
NDMP retrieval: child failed with status of 255
recover>

 

[ptwork]

I don't use ndmp, but I believe you must use the command nsrndmp_recover, not recover, to do these restores. Check Unix Admin guide in that regard. Not sure if there is a man page, but the switches should be similiar to the plain recover command.

Good luck
pt

 

[Pteryx]

This is long, but necessary to cover the problem.

This sounds very much like the problem I just had on our file server. Looks like you also are using Legato with an NDMP connection to a NetAppliance file server.

The first step is to check if this is the same problem as we had (have still). Look and see if one of the volumes BEFORE the one you are trying to recover was VERY LARGE!! We have one volume on our NetApp that exceeds 65GB. When we backup all of the volumes, this volume is the third one in the backup sequence, and recover will not read anything past that block! I can successfully recover the first three volumes from tape using the Legat &quot;recover&quot; command, but anything after that volume returns the same &quot;status 255&quot; message as you have seen.

If this matches your condition then you will have to go to manually reading the tape from the NetApp console.

Open a DOS window on the Legato server, cd to the /nsr/bin directory, and run the &quot;mminfo&quot; command.
use the following format for this command:
mminfo -avV -s [servername] [Tapeename]
The servername = the Legato server, not the NetApp's name
The Tapename is the label of the tape you are trying to read.

on my system this was something like:
mminfo -avV -s ServerOne TAPE.FULL.021

This will spit out a long list of block information entries for that tape. It appears as a repeated pattern of 19 fields of data. Look for the field that starts with a value of three (3) {fifteenth field?} and increments in each third line by three more ( i.e. 3,6,9,12,15,18...)

Now look for a number that is NOT an increment of three higher then the previouse line. This is where the problem started on our system. The file count suddenly jumped by SIX for that volume that was over 65GB!

If this matches what you find in your &quot;mminfo&quot; listing, then do the following.

1. Mount the tape into the drive on the NetApp. (if you use Legato networker to do this, be aware there is an &quot;idle device timout&quot; setting for the tape drive which may need to be increased to prevent an auto tape ejection, or you can mount the tape then stop the networked services)

2. Logon to the NetApp console as root and use the &quot;mt&quot;
command to &quot;file space forward&quot; to the block ONE LESS of the block number reported in the &quot;mminfo&quot; command for your target volume. i.e. if the block number in the &quot;mminfo&quot;
list was block 54, then issue the &quot;mt&quot; command as follows:
mt -f /dev/nrst0a fsf 53

3. At this point I SUGGEST that you test that you are at the correct location in the tape by using the following command:
restore tfb /dev/nrst0a 60 /vol/vol0/services
This will take quite awhile, but it eventually SHOULD list out the pathes of all files found in this part of the tape.
If not, you may need to adjust the value in the fsf command given to the tape drive. I had three tapes that all required the same offset value, so I think this is right for you as well.

4. Assuming the listing show the directories you are trying to recover, next backspace the tape one block, then fsf forward again to insure you are at the same starting point. to do this:
mt -f /dev/nrst0a bsf 1
mt -f /dev/nrst0a fsf 1
you can also check the tape status with:
mt -f /dev/nrst0a status
which has an entry that lists the file block number (which in this example would be 53)

5. If this all worked! Then you are ready to restore the data you need. use the following command to restore OVER the existing data (OVERWRITES!!!!):
restore xfb /dev/nrst0a 60 /services
or if it's a subfolder/file you wanted:
restore xfb /dev/nrst0a 60 /services/foldername/filename

If you want to restore to another directory on the NetApp:
restore xfbD /dev/nrst0a <continued next line>
60 /vol/vol0/services/restored /services

6. A couple of notes.
A. The &quot;60&quot; is required as legato uses a different
blocking size then NetApp's default.
B. The sequence of the fields in the restore command
MUST match the option values sequence! The &quot;b&quot;
relates to the &quot;60&quot; field, and the &quot;D&quot; relates to the
redirected directory name;
&quot;/vol/vol0/services/restored&quot;.
Swap those around and everything will fail, or worse
yet, corrupt your data!


Good luck and I hope this helps.
It took me two weeks with Legato Tech Support to
get to this point, and the original cause of the
problem has not been resolved by them yet.
They say the next release has this fixed!!!!