|
Re: [Networker] NetWorker Retention Policy Qs?
2008-12-02 00:54:12
Hi Jonathan,
On 02/12/2008, at 12:50 , JGillTech wrote:
Preston,
Did you run these test backups from the command line or within the
GUI? I am not that good with NetWorker yet to come up with such a
quick test. Likely take me an hour to conclude the same thing...
setup a group, create new media pool, label tapes, etc.
Command line. I work much, much faster on the command line in
NetWorker :-)
Anyways... I noticed the same phenomenon with your first backup.
You had a save-set retention of 12:30:07pm and a clone retention of
11:50:00am. The save-set took the retention of the clone pool, 50
mins. I would expect these figures to be reversed... well I did
until I understood clone-id. What this example says to me is the
clone-id (this particular instance) will expire at 11:50am and the
save-set will expire at 12:30 pm. Because the second instance (the
clone) has an expiration of 50 minutes.
Revisiting, the output was as follows:
[root@nox ~]# mminfo -q "client=earlgrey" -r
"pool,volume,savetime(25),ssretent(25),clretent(25)"
pool volume date time retention
time clone retention time
idata idata.001 12/02/2008 11:40:00 AM 12/02/2008
12:30:07 PM 12/02/2008 11:50:00 AM
idata idata.001.RO 12/02/2008 11:40:00 AM 12/02/2008
12:30:07 PM 12/02/2008 11:50:00 AM
idata clone idata_clone_01 12/02/2008 11:40:00 AM 12/02/2008
12:30:07 PM 12/02/2008 12:30:07 PM
idata clone idata_clone_01.RO 12/02/2008 11:40:00 AM 12/02/2008
12:30:07 PM 12/02/2008 12:30:07 PM
What this indicated was that the _original_ instance of the saveset
was due to expire at 11:50am, whereas the _clone_ would expire at
12:30:07.
"Retention time" in this case referred to the longest retention time
of any instance of the saveset, however, the overriding factor was/is
the clone retention time; in this case the individual instance of the
original copy of the saveset was due to expire at 11:50, and the
retention time referred instead to the _final_ - i.e., last retention
time of the "longest lasting" instance of the saveset.
The retention values on the clones make sense... just as in my
example. Did you look at the volume expiration after you conducted
your test? I suspect the volume would expire at 12:30... (if that
was the only save-set on the volume).
Volume expiration isn't to be confused with saveset expiration.
The expected expiration date/time of a volume is just that - it's only
what NetWorker expects is going to be the date/time of the volume
expiring based on the longest-lasting saveset on the volume.
NetWorker says the expiration for my full backup volume will be
11/02/09 rather than 1/2/09. Like your example.. I have a ssretent
of 11/02/09 for my cloned save sets... Is this a flaw in the
program or do I still not understand whats going on here?
While the "original" saveset in your example has a cited expiration
date of 11/2/2009, that instance of the saveset has an expiration date
of 1/1/2009; therefore I'd assume that while it may initially "blow
out" the ETA of the expiration date for the volume, when that instance
on the volume expires, it's not going to continue to hold the volume
in an unrecyclable state.
That is, the recyclability of a volume is _not_ based on the expected
expiration date of the volume, but on whether all the savesets on that
volume have entered a recyclable state.
Hope this helps.
Cheers,
Preston.
--
Preston de Guise
"Enterprise Systems Backup and Recovery: A Corporate Insurance Policy":
http://www.amazon.com/Enterprise-Systems-Backup-Recovery-Corporate/dp/1420076396
http://www.enterprisesystemsbackup.com
NetWorker blog:
http://web.me.com/prestondeguise/nsrblog/Welcome.html
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
|
|
