Michael,
I am assuming that others made the same assumption that I did when you said you
were doing these things by script - that you were running a script that kicked
off the cloning (nsrclone) and staging (nsrstage) and then deleting the save
sets.
Both the nsrclone and the nsrstage commands have -y and -w arguments that allow
you to define the retention and browse times (respectively) for the save set
that is being created.
There is also ( I think, this is new in NW 8 ) the ability to create actual
clone jobs via NMC that will pick up save sets that do not have clones and
create them. I haven't gotten to that yet. I'm surprised that you are able to
use the clone check box on your group definitions. I had to give that up back
in the 7.3 days when it just got to the point that NW's self cloning was
causing too much tape drive contention and was actually causing more save
groups to fail than to succeed.
-Frank
On Jul 1, 2013, at 9:55 AM, Michael Leone <Michael.Leone AT PHA.PHILA DOT GOV>
wrote:
>> Ok, here's a short instruction on how to do it, but this is from
>> memory since I don't have GUI access to any NW servers right now :
>>
>> 1. Choose a client which saves to an AFTD pool, and set it's
>> retention to 21 days.
>> 2. Create a clone job that runs 2 times a week and looks back 7 days
>> (for overlapping, in case a clone job fails). In the number of
>> saveset copies on the destination pool, choose 1.
>
> I quite honestly have no idea what you're talking about here. :-) I will
> admit to having a simple setup: my clone jobs are accomplished by making a
> group; putting a client in it; and checking off "CLONES" in the "Clones"
> section, and choosing a "Clone Pool". And that's all I do ... I let NW
> automatically run the cloning to tape when the job is done. And the script
> I mentioned earlier runs and cleans up the mm db and the disk space.
>
> I don't see anywhere in the group definition to "look back 7 days", nor
> "number of saveset copies on destination pool". I don't see those options
> on the client definition in NMC, either ...
>
> I will own up to being more stupid than usual this morning, so maybe I am
> just missing something obvious ...
>
>> Choose the tape pool that you would normally use for this kind of
>> backup and retention.
>> Set the retention times to the retention you _really_ want, say 3
> months.
>
> Where in the job definition do you do this? I see retentions on client
> definitions, but not groups ...
>
>> In the selection tab, choose savesets from the pool on the AFTD
>> that you saved to.
>> 3. Check that everything looks fine, and try to run the cloning.
>> 4. When you check your retention on savesets using mminfo, remember
>> to use clretent -since this is the only one that reports the
>> retention for each clone instance of a saveset.
>> -so: mminfo -avot -q ssid=12345678 -r ssretent would report the
>> retention of the saveset still on the AFTD and you'll be nervous.
>> And: mminfo -avot -q ssid=12345678 -r ssretent,clretent would
>> report 2 savesets, one on the AFTD and the other on the tape, with
>> the right retention.
>> 5. This means that the clients' savesets on the AFTD will be deleted
>> when they expire, after 21 days. And the savesets on tape will
>> expire when their clretent has been reached just like if they were
>> normal tape savesets.
>>
>> And as a side note, remember that a clone is exactly that, a clone.
>> This means that NW doesn't care the least whether you point it to a
>> clone to do the recover from or the original saveset.
>>
>> /tony
>>
>>
>>
>>
>> -----Oprindelig meddelelse-----
>> Fra: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
>> På vegne af Michael Leone
>> Sendt: 28. juni 2013 16:37
>> Til: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>> Emne: Re: [Networker] AFTD device/nsrstage command with 8.0.1.5
>>
>>> Michael,
>>>
>>> i do not know how old your installation is but i think before NW 7.
>>> 3?
>>
>> Feb 2007. I believe it was 7.2, yes. (I wasn't here then)
>>
>>> there was only one retention policy/date possible per client.
>>> So you might have carried this schema over all these years.
>>>
>>> Since it changed, you may even set separate dates for each individual
>>> save set instance (cloneid).
>>
>> But not via GUI, right?
>>
>>> I am talking about dates, not about policies. So you must either
>>> specify them at the time of the backup (save/savegrp) or later with
>>> "nsrmm [-w time ] [-e time ] - S ssid/cloneid".
>>> And as i said you can also set these parameters for nsrclone/nsrstage.
>>
>> So I'd still need a script to do it, right? To set the short
>> retention times using "nsrmm"?
>>
>> So I'm still not seeing where I would be gaining much, by changing
>> my current setup.
|
