Excellent point, Darren. Yeah, I think we want the 6month policy, but we
really only want it on tapes in the ATL pool (incrementals and level
backups) as these tapes do not go off site. But we don't really want
this for the FUL pool since these do go off site. Again, it's not really
a major deal since we write-protect everything we take out of the
library and nothing goes back in unless recovering. Only catch would be
if a FUL pool tape got left in library too long.
We can't really just change the policy for certain clients and not
others because ALL clients use the same pools. It would be nice, though,
if NetWorker allowed you to adjust the retention period based on the
pool. So we could have a 6month policy for any savesets in the ATL pool
and a 1 year policy for any savesets in the FUL pool. Given that all of
our clients use all the pools, the only work around I can see would be
to have two instances of every client. Both instances would have
identical info except 1. they'd each be in different groups. One group
would use the schedule for the ATL pool and the other would use a
schedule for the FUL pool, so you'd double the number of schedules, too,
and 2. each would specify a different retention period based on the
group. Not sure if you can have different retention periods for same
client instances?
Anyway, this would be an insanely mess to manage, so I'm thinking we
just need to be careful not to leave the FUL tapes in there too long.
George
Darren Dunham wrote:
>
> > they're at least 6 months old. Anyway, I'm thinking to change the
> > retention policy to '6month' so it will match our real practiced policy.
> > It looks like I'll have to set this for every client, though, including
> > the server.
> >
> > 1. Can someone step me through the automated command line (nsradmin)
> > method to do this for all the clients? I'd like to avoid using the GUI
> > for each client -- too slow.
>
> Read the man page for nsradmin. Take a look at the man pages for the
> types you're interested in (like nsr_client in this case).
>
> Then you'd do something like this. Note that if you do this
> interactively, nsradmin will ask for confirmation before every change.
> If you do it non-interactively, it will just do it.
>
> # nsradmin
> nsradmin> . type: nsr client
> nsradmin> update retention policy: 6 months
>
> That's it. The first line selects all the objects you want (any nsr
> client, no other restrictions). The second line updates the attribute
> or attributes you want (the 'retention policy' attribute is mentioned in
> the nsr_client man page).
>
> This would do that non-interactively...
>
> printf ". type: nsr client\nupdate retention policy:6 months\n" |
> nsradmin -i -
>
> > 2. Should I reboot the server once completed?
>
> Not necessary.
>
> > 3. Will this change be retroactive, or will it only start from this
> > point forward? For example, assuming no dependencies, will a volume or
> > saveset from say October 2003 that was previously flagged as
> > 'recoverable' now be shown as 'recyclable' or does the countdown begin
> > now?
>
> I believe it is retroactive, but you would want to check it. 'nsrim'
> with some verbose flags would probably tell you.
>
> > 4. Guess I'll need to be more mindful NOT to leave tapes in the library
> > for more than 6 months; otherwise, NetWorker could load them and recycle
> > them if they're not write protected, assuming it ran out of available
> > tapes. This has never posed a serious risk prior since the policy was 1
> > year. There have been some tapes, though, that did sit for 5-6 months,
> > long after being full, and were not pulled out of library and
> > write-protected until after 6 months and times when we ran out of
> > available tapes over weekend and had to add more Monday morning. Would
> > not want to come in and discover NetWorker had recycled eligible tapes!
>
> Then maybe you don't want to do this for every client! Do you really
> want a 6 month policy or don't you? If you do, then recycling after 6
> months shouldn't matter, should it?
>
> --
> Darren Dunham ddunham AT taos DOT
> com
> Senior Technical Consultant TAOS http://www.taos.com/
> Got some Dr Pepper? San Francisco, CA bay area
> < This line left intentionally blank to confuse you. >
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listmail.temple DOT edu or visit the list's Web site at
> http://listmail.temple.edu/archives/networker.html where you can
> also view and post messages to the list.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
