Unsolved
This post is more than 5 years old
116 Posts
0
1715
nw9 clone action
Hi,
Do you know any way to achieve 'savegroup cloning' functionality in NW9.1?
According to the NW 9.1 Differences Techinical Note I need to chain a clone action to a backup action.
Unfortunatelly it seems to me that the saveset list is not handed over to the clone process but generated by some logic.. so if we run any other backups at a given time window these additional savesets will be also included in the clone list..
(eg.: FS backup starts at 00:00 AM, finishes at 04:00 AM (multiple clients). A DB backup workflow starts at 02:00 AM and finishes at 05:00 AM*. DB backups were cloned by both policies). *the specific client finishes eg. at 03:00 AM)
So having 2 overlapping policies we got 3 copies of some savesets at the end...
Do you have any idea how to handle this? (I know that I should avoid overlapping the backup windows, but it might happen sometimes).
bingo.1
2.4K Posts
0
February 20th, 2018 07:00
It is obvious that for the clone action you must define the specific query criteria for the save sets to be cloned more properly to narrow the filter a bit.
If you have multiple media db queries with overlapping criteria then of course this will result in the fact that the save save sets could be members of more than one (internal) list.
oldhercules
116 Posts
0
February 20th, 2018 09:00
Hi bingo,
It’s not so obvious to me.. in nw8 the savegroup cloning cloned the
savesets which were created by the actual run of the group.
With nw9 in backup-clone actions there are very few ss filtering
possibilities, so probably any backup created when the workflow is running
will be cloned.. regardless in which pool they were stored etc..
The NMC view of the backup process is also misleading, because it also
suggests that the actually backed up data will be cloned.
bingo (időpont: 2018. febr. 20., K, 16:19)
ezt írta:
bingo.1
2.4K Posts
0
February 20th, 2018 09:00
The limited filter capabilities is actually the reason why we exclusively use scripted cloning ;-)
As we have multiple devices and tape drives we can have separate, concurrent clone processes - on for each ddboost device.
And you can check for the numper of copies (validcopies<2) to avoid multple clones.
In general, the command line offers (much) more options/parameters than a GUI - otherwise the GUI would lose the easy layout/structure.
oldhercules
116 Posts
0
February 20th, 2018 10:00
We are also heavily using nsrclone for data cloning (manual backups) and for tape out.. so we are familiar with it.
The beauty of savegroup cloning is that it is automatic, immediate and the load is spreaded...
We have 2 sites and we promised a low RPO to our ‘customers’ for site dr too :)
I think emc wanted to provide the same savegroup cloning functionality in nw9, but the designers/developers created a method which is not working well in real-life scenarios :)
ble1
2 Intern
2 Intern
•
14.3K Posts
0
February 20th, 2018 13:00
One of the issues I have seen is that if your workflow allows clients to override schedule for example, it may happen that you have skip or something fails and then nsrlone action goes crazy. I also noticed that with some older versions on client things will go hairy. One can easily see that via copies it had of save sets (eg. mminfo -avot -q copies=>3 -r ). I was able to address this by changing schedule ownership, but I still have couple of instances where things will go its own way. nsrclone action doesn't have filter for 1 copy by default if you use group with client subtype (which is exactly what you use when attaching nsrclone action to backup in workflow) - if you create query tape then that is possible, but that is then no longer what and how most of people are using it.
luke_m_edwards
14 Posts
0
February 20th, 2018 16:00
I decided not to run cloning as an additional action within the same workflow as the backup action because that method has limitations in my opinion. I prefer backup workflows and clone workflows to be completely separate to ensure that the cloning never impacts the backups. The method I use is to create a separate query type group for each backup group and within that query group select the backup group as a filter (plus the pool). The query group controls the number of copies allowed in the target pool. I then create a dedicated clone workflow and associate it with the query group. This can be done for all backup groups and avoids any overlap because each clone group only looks as one associated backup group. This method also creates lots of clone groups/workflows (same number as your backup groups) which results in multiple concurrent clone streams. Not sure if this is the best config but it works and it can all be configured via the GUI rather than doing it via scripts.
oldhercules
116 Posts
0
February 20th, 2018 23:00
I have 2 problems with clone groups:
1: in case of nw8 'savegroup cloning' the cloning is immediate. Eg. oracle archlogs can be cloned to the remote site right after the backup completes..It helps to keep a low RPO value.
2: The retention must be set for cloning (keep the original expiration is not an option in the gui). So if we have different retention values for a specific client then we have to use separate scheduled cloning.
I'll check the 'concurrent' option, but I'm not sure that it will help + it can really cause high dd streams usage..
luke_m_edwards
14 Posts
0
February 21st, 2018 00:00
1 - For me this is acceptable (from an RPO perspective) because the clone workflows can be run on their own schedule so for groups that require it (eg oracle logs) the clone workflow can be scheduled to run every hour or whatever the requirement is.
2 - This is definitely a limitation with the clone group option. In my opinion there should be an option to ‘match’ the retention of the saveset. In my environment all Workflows are set to ‘cannot override’ so all clients adhere to the backup workflow retention anyway. As you’ve pointed out the clone retention dates get set by the clone workflow so they are slightly offset from the original backups which is annoying but it’s not a show stopper for me as the clones just expire one day later. Obviously scripting the cloning provides the most control. This setup is the closest I’ve come to having a stable cloning solution configured via the GUI.
The two main reasons the chained clone actions hasn’t worked for me are:
1 - You can’t limit the target copies which leads to problems
2 - If you have failures there’s no way to mop up or catch up as a secondary process so you end up needing query groups to look back and mop up any missed savesets which then introduces the risk of overlap.
I’m always looking for an improved way of doing the cloning via the GUI so please post if you find an alternate solution that works and scales well.
bingo.1
2.4K Posts
0
February 21st, 2018 01:00
Besides the facts I already mentioned we decided to use scripted cloning because ...
- it was already implemented
- you can use your specific mminfo query
- you can set another retention time along with the nsrclone command
- it works independently from the group.
Such is beneficial if you have to restart a group (to retry a failed backup) but NW will not allow you to do that
simply because the group is still active with cloning the successful save sets.
luke_m_edwards
14 Posts
0
February 21st, 2018 02:00
That's another very good point regarding workflows that include both backup and clone actions - if there's a problem with the cloning or the clones are long running I pretty sure they hold up the workflow from either re-running failed clients or running on the next backup cycle - that's a big problem. I prefer to keep the clone process completely separate from the backup process so there's no chance of it affecting the backups or re-running failed clients. I know that goes against how NW9 has been redesigned to allow for multiple actions in a workflow so maybe I'm missing something. In my experience cloning has always required special treatment (typically scripted) to get it running smoothly. The method I described previously using query groups also works fine. If it worked I'd much rather use workflows with multiple actions and then not to have to create lots of additional groups!