system error occurred(130)

[heavenice]

Hi there!

Recently, I have the need to restore a couple of files to the Filer via NDMP, and upon the restart process I get these errors:

4/20/2009 2:10:53 PM - begin Restore
4/20/2009 2:10:54 PM - end Restore; elapsed time: 00:00:01
system error occurred(130)

It seemed that the restore fails the very moment it has been started.

This is what is going on. 

I'm using Netbackup 6.5.3 on a Windows 2000 SP4 Master Server, and I've a SUN NAS 5320 with OS 4.22 M1 (Build 65)

I've a SUN 8-slot LTO3 tape drive.  I loaded this set of 8 tapes (containing 2 weeks worthed of backups) into the tapes, do an inventory and got them shown up nicely.

Next, I imported the images from the tapes to the EMM database, import the catalogs and the retore points are shown up nicely.

Upon selecting the required restore and activate, the above-mentioned error is all I see almost instantaneously.  Note that I am restoring to a different path.

Restoration is not new to me and I've done it countless times before hitting this snag.  NDMP is definitely working fine and the logs shows nothing. Even now when I do a flat backup and restore test, it still works.  However, it just seemed that nothing in this set of tapes is recoverable.

Does anyone has a clue?

[Pravs]

is there any thing interesting in bptm, ndmpagent logs, Filer logs.

[scorpy_582 · Accepted solution]

Check this out. I guess its exactly what you are trying to do..

http://seer.entsupport.symantec.com/docs/317401.htm

[heavenice]

Thanks Pravs and scorpy_582, you guys are pretty fast there! :)  There was nothing too exciting inside those logs but I think you almost hit it there scorpy_582! That is a very exciting find!

I've these lines in bprd:

17:10:29.273 [1772.3012] <2> setup_query: begin db communication
17:10:29.273 [1772.3012] <2> setup_query: criteria sent to db mgr
17:10:29.289 [1772.3012] <2> add_to_restore_list: backup date of 1238792279 for /Vol21/NCSFSSG01/ not found in image list
17:10:29.289 [1772.3012] <2> set_job_details: Sending jobData jobid (2852)
17:10:29.289 [1772.3012] <2> send_structure_data: Index 9 Field m_nStatus Value <130>
17:10:29.289 [1772.3012] <2> send_structure_data: Index 21 Field m_nState Value <3>
17:10:29.289 [1772.3012] <2> set_job_details: Done

Now, these are similar to to errors presented in seer.entsupport.symantec.com/docs/317401.htm.  However, when it comes to the part to locate the header in the appropriate tmp folder, the policy name that I should see is not there! DuH!

Does this means I have an incomplete image and I should try to re-load again?

[scorpy_582]

Importing the images again will not be a bad idea

[Pravs]

Technote talks about workaround as well. you may wish to try that. I can see that you are at 6.5.3. There is no Emergency binary for 6.5.3 as of now but 6.5.1.  you can try to import the image again.  If problem still persist, you can ask support to get you EEB for 6.5.3. This issue is planned to be fixed in NBU 6.5.4. As usual it follows the normal disclaimer stating that it can be altered at any time.
Cheers!

[heavenice]

Hi guys,

A little update.

It seems that NB6.5.3 does not work too well with Win2kSP4.  I've to re-build the master server from scratch with Win2k3SP2 and NB6.5 to load the images back properly.  Note that I've also managed to load the images successfully with the previous setup, with no error messages whatsoever. But I got stuck trying to locate the header file of the right policy.  The current setup solves this problem.

Some information that differs from the bug report:

1) I'm using these settings in my policy: SET HIST=n, SET TYPE=dump, SET SNAPSURE=y, SET OPTIONS=NT, set UPDATE=y.

2) My imported NDMP images were NB6.5.3, not NB5.1.

The rest are pretty much the same.  Changing NUM_FILES 0 to NUM FILES 1 solved the issue. so I guess the bug applies to more than one instance of situation, and probably applies to NDMP images imported from NB5.1 to NB6.5.3, especially when the "SET HIST=n" switch is used.

Guys, thank you so much for pointing me to the right direction, especially scorpy_582!  Even Tech Support was confounded by this problem.


Cheers! :D