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:
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.
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).
bingo.1
2.4K Posts
0
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.
barry_beckers
393 Posts
0
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).
bingo.1
2.4K Posts
0
October 4th, 2022 13:00
The destination pool can in fact be any pool.