Networker

Re: [Networker] NetWorker Retention Policy Qs?

2008-11-26 19:07:34
Subject: Re: [Networker] NetWorker Retention Policy Qs?
From: Preston de Guise <enterprise.backup AT GMAIL DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Thu, 27 Nov 2008 11:05:47 +1100
Hi Jonathan,

On 27/11/2008, at 10:22 , JGillTech wrote:

Thanks again for the clarification. However, I am not solid on the concept.

I looked through the NetWorker documentation for an explanation of ssid vs. clone id. I didn't find anything that could help me discern the difference.

I was under the impression the ssid was the unique identifier of the save set. Can a ssid be reused? I was under the idea that each save set specified in a client resource is assigned a unique ssid when backing up. Correct me if I am wrong. If that is true, why is a clone id needed?

The clone-id is used to differentiate _instances_ of a saveset.

If you have your "original" saveset on say, tape 800841, and a clone on tape 800917, and you only want to affect _one_ instance of the saveset, you have to be able to uniquely identify that instance. Thus, that's where the clone-id is used.

Why would NetWorker pick a save set with the lowest clone id? It makes sense to increment the clone id of the most recent rather than decrement. To clarify my understanding, the most recent instance of a save-set has a clone-id 1 less of the previous.

No, I may have confused you by using an example from disk backup units.

The clone-ids assigned to individual instances of a saveset will vary considerably, based on the time that the saveset instance is generated - this is where I was saying that the clone-id is closely related to the nsavetime. The reason NetWorker assigns (on disk backup units) a clone-id for the media database instance of the saveset on the read- only portion that is 1 less than that on the RW portion is explicitly to ensure that a recovery request will target the RO device, not the RW device.

The reason NetWorker picks the saveset _instance_ with the lowest clone id is a historical one - in a situation where you backed up to tape, then cloned to another tape and sent that other tape off-site, it needed a mechanism for determining which saveset it would request in the event of a recovery. For whatever reason, the design choice was made that it would request the lowest clone-id (or at least, over time, this became the design).

For pure tape environments, this usually works.

I currently make my volumes as full and record the location when taking a clone tape offsite. Should I use the offsite flag rather than making the volume as full? How do you apply the offsite flag? I don't know of any place to do this within the GUI. I wish this kind of stuff was documented. I have all the recent documentation, I wasn't able to find any of this information.

Marking the volume as offsite has nothing to do with marking the volume as full.

There is currently limited access to the media database flag associated with offsite; it can't be (to my knowledge - I haven't looked lately) controlled via the GUI. From the command line, you can do:

nsrmm -o offsite volumeName

or

nsrmm -o notoffsite volumeName

However, you can't _query_ this flag.

Do you have anything more to say about clone-ids to help me understand... specially the difference between clone-id and ssid.

Perhaps all I can add is that if you're not currently cloning your data, the concept of clone-id fields may not seem all that logical. However, when you're at a point where you have multiple instances of a particular saveset, you do need a way of differentiating those instances.

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