
Attachment uploads are currently disabled. This is a temporary situation and will resume as normal in the coming days.
UNSOLVED
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
Responses (0)
Solutions (0)
