|
Re: [Networker] NetWorker Retention Policy Qs?
2008-12-01 20:02:51
Hi Jonathan,
On 02/12/2008, at 10:43 , JGillTech wrote:
Now back to the example and perhaps I can apply the logic from
above. The save-set on the full backup volume has a retention of
11/02/09, and a clone-id retention of 1/1/2009. This clone-id
retention is for a single instance, the instance created during the
normal full backup (2 months as specified by the client resource).
The clone operation ran after the full backup completed, extending
the save-time retention on the original volume to 11/02/09. This
happened because the second instance (2nd clone-id) had a retention
of 11/02/09... thus the save-set as a whole now has a retention of
11/02/09.
If I remember correctly from your example, it is more the case that
the clone instance has a retention of 11/02/09; the original instance
of the saveset had a retention period of only the 2 months that you'd
referred to.
Hopefully this is correct. Now the problem:
How can I have a volume expiration based on a 2-month retention
policy for my full backup volume, and a volume retention for 1-year
on my clone volumes. If I understand correctly... the save-set
retention is going to be the longest of any of the clone
retentions. I hoped to automatically expire media, and recycle to
other pools when needed. If the clone retention for the 2nd
instance of the save-set is 1 year... the whole save-set won't
expire...thus the volume won't expire until the clone expires.
If you've (for instance) come from a NetBackup background, you may
find it confusing that NetWorker allows different retention times to
be stored on the same volumes.
However, if you're referring to the clone saveset "forcing" the
original saveset to hang around past its retention date, then...
...out of paranoia I just ran some test backups, with the original
backup having a 10 minute retention time, and the clone pool forcing a
50 minute retention time.
mminfo output was:
[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
After 11:50am, I ran nsrim -X, which forces an immediate cleanup and
processing of expired savesets, then re-running mminfo:
[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 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
So in short, no, your longer retention time on the clone volume should
_not_ affect the shorter retention on the backup volume.
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
|
|
|
