Start a Conversation

Unsolved

1 Message

238

October 3rd, 2022 01:00

Save Set Migration on Networker

Hi...

We are using Networker 19.1.1 and it's integrated with DD6800. Currently DD 6800 is running out of capacity. So we have to free some space on the DD 6800. In there we plaining to deploy a new DDVE and then it integrate with our NW and perform the network save set migration using "nsrstage". Just want to clarify,

  • when we using the "nsrstage" command to migrate the save set to new volume on DDVE with -S parameter, is  save sets will be automatically removed from the original source volumes once the migration complete ?
  • After that are we to perform cleaning task using  "nsrstage – C -V "  or just need to run the DD file system cleaning to get free space on DD6800 ?

Please advise. 

2.4K Posts

October 4th, 2022 04:00

First of all you should verify your retention periods - maybe you could shrink some of them.

 

"nsrstage -S ssid(s)" as well as "nsrclone -m -S ssid(s)" will migrate the save sets to the new media pool. There is no need to run another NW command although I recommend to use mminfo before and after the process to check the situation/verify the result. So the general procedure would be like this:

mminfo -q "your_selection_criteria" -r "ssid" > file

nsrclone -m -b destination_pool -f file

mminfo -q "your_selection_criteria" -r "ssid,volume"

 

It is clever to run such a script in regular intervals (weekly or monthly) to avoid such situations.

 

There is no extra work to be done on the DD - it will cleanup itself at the scheduled time. However, you might of course start the cleanup process manually if you need to run it earlier.

 

 

 

October 4th, 2022 10:00

does the nsrclone -m option not require the target pool to be of type "clone"? Compared to regular cloen command, the nsrstage command allows data to be migrated to any pool, regardless if it is of type clone or type backup.

Can't recall if nsrclone -m still requires a clone pool as target however...

Some things to take into account is also making sure NW CCR (clone controlled replication) can do its work between the DD's involved to have optimized cloning (or staging for that matter) so that data is being deduplicated between the DD's involved.

For this we for example make sure that the FQDN name of the involved DD's as stated within NW is also stated in the DD's for each other, so to control also which interface is used between which the CCR cloning is being performed (we have had issues way in the beginning when we implemented DD's where replication was performed over the 1Gb management interface instead of the intended 10Gb interfaces, but at the time barely no information was stated of how to even control that CCR behavior).

2.4K Posts

October 4th, 2022 13:00

The destination pool can in fact be any pool.

 

No Events found!

Top