|
Re: [Networker] NetWorker Retention Policy Qs?
2008-11-25 15:57:44
On 26/11/2008, at 06:49 , JGillTech wrote:
Why would the volume expiration differ from the save set
expiration? If the volume is full, the expiration of the volume
should be equal to that off the save set with the longest
retention. Correct? The volume expiration for my latest full
backup volumes is 2 months, the monthly clone operation has not run
yet. When it does, I suspect the volume expiration will be 1 year
rather than 2 months. Are you saying the NetWorker's expiration is
not relevant?
I am aware that dependent backups (incremental) must expire before
save set expires. However, I am not sure what you mean by "giving
the effect that a full does not expire until the next oldest full
reaches it expiry date." Can you break this down a bit? My
understanding is such: I have a 2 week retention policy with
incremental monday-saturday, full on sunday. The first backup will
not expire until 3 weeks because the incrementals are dependent on
the full backup.
What this comes down to is that the volume expiration cited is
typically the expiration date of the "longest lasting saveset" on the
volume, not taking into account dependencies - something NetWorker
can't do when it's say, declaring a volume full, etc.
NetWorker is a product that forms dependency chains. If we take "A <-
B" to mean "B depends on A", then over the course of a week you would
get the following chain:
Full <- Incr <- Incr <- Incr <- Incr <- Incr <- Incr
If the full and first 3 incrementals are on one volume (say, "Alpha"),
but the other three incrementals are on another volume ("Beta"), then
the volume "Alpha" won't become recyclable until at least the 3
incrementals on "Beta" in that dependency chain are also recyclable.
However, further to this, the dependency chain must be broken for the
savesets to become eligible for recycling.
Thus you'd need to say have:
Full <- Incr <- Incr <- Incr <- Incr <- Incr <- Incr **** Full
I.e., the new full backup has to occur to break the dependency chain,
so that the next incremental, etc., relies on the new full:
Full <- Incr <- Incr <- Incr <- Incr <- Incr <- Incr **** Full <-
Incr
If for some reason that full failed to occur, you'd instead get:
Full <- Incr <- Incr <- Incr <- Incr <- Incr <- Incr <- Incr
So, when we talk of expiry dates, typically what does have to happen
is that next full that broke the dependency chain has to also become
eligible for recycling - or to be more precise, ALL savesets in a
dependency chain MUST become recyclable before the chain becomes
recyclable. (This results in "tree" style chains in long-running
combinations of fulls/incrementals/differentials, but the net result
is similar.)
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
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
|
|
|
