Announcement Banner
UNSOLVED

hbremer

updated

16 years ago

H

hbremer

1 Rookie

•

28 Posts

0

4551

April 12th, 2010 00:00

nsrstage not working: server busy

Hello,

we are running NetWorker 7.5.1 and are in the process of setting up a new NetWorker environment. However, we want to bring some of the old backup data to the new environment using the following procedure:

- on the old environment (no tapedrives on this) we "nsrstage" the defined savesets to a specially defined adv_file device.

- then we connect this adv_file device to a Storage Node and configure this on the new NetWorker Server

- now we run scanner -i on this device having all the indexes in the new database

- we mount the basic and the .RO volumes on the adv_file devices

At this point all seems to be correct.

- run the nsrstage command as seen below to bring the old data to the new environment tapedrives and get the busy problem.....

========================================================================================

C:\>nsrstage -v -b "BinckBank 7jaar" -J unwrathene -y 3/31/17 -m -S -f c:\users\_hbremer\Alex_016_ss_1.txt

Obtaining media database information on server rnwrathene.binckbank.nv
Parsing save set id(s)
Migrating the following save sets (ids):
        1924854660
5874:nsrstage: Automatically copying save sets(s) to other volume(s)

Starting migration operation...
NSR server rnwrathene.binckbank.nv: busy
waiting 30 seconds then retrying
NSR server rnwrathene.binckbank.nv: busy
waiting 30 seconds then retrying
6358:nsrstage: nsrstage command has retried 2 times.

NSR server rnwrathene.binckbank.nv: busy
waiting 30 seconds then retrying

etc.....etc.....

=========================================================================================

A tape is mounted from the "BinckBank 7jaar" volume pool and if the .RO volumes is not mounted, we get a request to do so. Mounting  the .RO (and the basic) volume the busy problem appears.

What is causing this?

Is there something wrong in the procedure?

What can we do to resolve this problem?

Regards,

Harry Bremer