You don't say which version of NW you run (as retention policies changed in NW9), but we regardless I will assume here NW9 methodology as soon or later you will hit it even if you are running NW8 now. Given that b/r can't be difference there, you would not clone the record, but rather stage it (which is also handled by nsrclone if using script). Or you will have to define staging policy which takes records from DD after 29 days and moves them to tape pool.
We do it in a similar way. However, we clone right after the save sets have been backed up to the DD.
As the disk save sets will expire separately, they will do that independently, earlier.
However, this method gives you more time to react in case of a failure.
Think about it:
If you do clone/migrate at the end of a cycle and you run into whatever problem, it might be that NW would have removed the backup from disk until you finally manged to continue.
I thought about you said, your solution is Logical and more safe,
but I want to know is there any way to store backups on separate volumes ? in this case, backups store for 30 days on DD and when it neared to expiration on DD, write on Tape with about 1 year retention.
also
dear Hrvoje Crvelin
I`m thinking about your solution, "Staging" .
I should test it and if was my wish, I`ll tell you about this.
but, if where is any other solution, please tell me ...
Difference between cloning and staging is that one copies the data and second one moves the data. I do not have NW9 to check exact steps there now, but in theory since you wish to extend existing backup at the end of expiration period to me it sounds as you wish to extend retention once data is moved to different media.
according to emc documents (duco61081) , (in my pilot environment) I create a Staging Device. and I refered it to one of my Devices (a AFTD device) and I set that he oldest save sets move to a new media pool (that is DD) .
and then, I configured a policy (and workflow) to get backup on a media pool that refers to AFTD device.
how staging works?
did it moves last save sets automatically to new destination pool (that I defined it DD) ?
I mean that when we define a Clone action, we define a new dedicate definition on workflow.
Staging was necessary in the legacy times (when disk capacities were much smaller) - today it is almost history.
Especially staging from an AFTD to a DD does not really make sense as you will loose a lot of features like 'client direct' (to a DDboost device) which will really speed up you backup throughput.
In general staging is controlled by the 2 watermarks:
- high watermark is where the staging should start
- low watermark is where it should end
The most important issue: the % values refer to the whole file system.
Other parameters are of 'minor' importance like timing, sequence etc.
ble1
6 Operator
•
14354 Posts
•
56186 Points
4064
0
Posted December 11th, 2016 08:00
You don't say which version of NW you run (as retention policies changed in NW9), but we regardless I will assume here NW9 methodology as soon or later you will hit it even if you are running NW8 now. Given that b/r can't be difference there, you would not clone the record, but rather stage it (which is also handled by nsrclone if using script). Or you will have to define staging policy which takes records from DD after 29 days and moves them to tape pool.