|
Re: [Networker] NetWorker Retention Policy Qs?
2008-12-01 15:18:28
Hi Jonathan,
On 02/12/2008, at 06:00 , JGillTech wrote:
In regard to your extended explanation of clone-id: NetWorker
assumes there is going to be more than 1 instance on a save set?
Even save sets without clones are assigned a clone-id?
Yes - to use Davina's excellent analogy, it's basically the same
situation as a library; they may not know how many copies of an
individual book they'll end up with, so while each copy will have the
same ISBN, the first copy will get tagged as copy #1, then if they get
another copy they can immediately identify that as copy #2, etc.
In regard to the clone-id -1 on disk backup units: NetWorker
selects the save set instance with the lowest clone-id? In a disk
backup situation the RO device resource has a clone-id 1 less than
that of the RW device? Is this correct? In reality this is only 1
save-set with two media db records that have the save SSID, just
different clone-id's.... right? Just want to make sure we are on
the same page.
No, any time you clone a saveset you'll end up in a situation with
duplicate SSIDs and different clone-ids.
That is:
Backup saveset "A" to tape 800841. It might get ssid 3962821979 and
cloneid 1228134901.
Clone tape 800841 to tape 900144. The copy of saveset "A" will still
have ssid 3962821979, but will get a new cloneid - say, 1228135709.
In review (make sure I understand) each save-set has a ssid and
clone-id. On the clone volume, the same SSID is used with a
different clone-id. Bottom line... clone-id uniquely identifies a
save-set (clone or not).
Not quite - the saveset ID identifies a saveset. However, the
combination of saveset ID/clone ID identifies a _single_ instance of a
saveset.
What doesn't make sense is the -1 thing. Consider the following
situation:
Full Backup Volume
Client: cpback
Name: NMCASA:/gst_on_cpback/lgto_gst
SSID: 2987199012
Clone-ID: 1225591332
Copies: 2
Clone Backup Volume
Client: cpback
Name: NMCASA:/gst_on_cpback/lgto_gst
SSID: 2987199012
Clone-ID: 1225606684
Copies: 2
There is more than a -1 difference between the clone-ids... can you
explain.
For disk backup units only I get a "1 difference" between clone IDs
for the same saveset. E.g.:
[root@nox ~]# mminfo -q "savetime>=18 hours
ago,pool=Staging,client=archon,name=/Volumes/TARDIS" -r
volume,ssid,cloneid,nsavetime
volume ssid clone id save time
Staging-01 3962821973 1228135765 1228135764
Staging-01.RO 3962821973 1228135764 1228135764
When you refer to "Clone Backup Volume" above, I'm assuming that
you're referring to tape based clones - in which case, the clone-ids
aren't going to be 1 different from one another, since they're closely
aligned to what you might call the nsavetime of the _instance_ of the
saveset.
This gets back to the situation that started this post. Let me
summary my setup... perhaps you can find out whats wrong (EMC can't
so far).
Groups:
1. Server Bi-Weekly Group (runs bi-weekly) w/ automatic clone
2. Server Monthly Group (runs 1st of every mon) w/ automatic clone
3. Server Weekly Group (runs every day) no clone
Clients:
Browse: 2 months
Retention: 2 months
Media Pools:
Server Full Pool: Data Source: all 3 groups from above, Retention:
not specified
Weekly Clone Pool: Pool type: Backup Clone, Retention: 2 Months
Monthly Clone Pool: Poot type: Backup Clone, Retention: Year
Results from Full Volume (1 record from 10/31, 11/1, 11/2)
Order: client,name, ssid, clone-id, copies, date-time, retention-
time, clone-retent
cpback bootstrap 3188440518 1225506246 1 10/31/2008 12/31/2008
12/31/2008
cpback NMCASA:/gst_on_cpback/lgto_gst 2987199012 1225591332 2
11/1/2008 11/2/2009 1/1/2009
elistencl.yyyy.xxxxx.edu C:\Program Files\eListen 1930324381
1225681326 1 11/2/2008 1/2/2009 1/2/2009
Comments: The retention and clone retention are reversed on 11/1
Results from Clone Volume (1 record from 11/1)
cpback NMCASA:/gst_on_cpback/lgto_gst 2987199012 1225606684 2
11/1/2008 11/2/2009 11/2/2009
Comments: This record from the clone volume indicates a different
clone retention ... not corresponding to the media database entries
for the full volume.
What do you think? Did I miss something once again? I am sorry for
the 50-questions... you are more knowledgeable than most I have
spoken with @ EMC.
Looking at the output above - specifically, the clone retention being
11/2/2009 and the original backup date being 11/1/2008, I would assume
that you have had the saveset cpback:NMCASA:/gst_on_cpback/lgto_gst
backed up to the Server Full Pool, but cloned to the Monthly Clone
Pool, since the Monthly Clone Pool has a retention period of a year,
it will have pushed out the retention period of the saveset instance
that is stored on the clone volume - i.e., to me, the above reads as
"OK" on the _assumption_ that you have cloned from the Server Full
Pool to the _Monthly Clone Pool_.
(FYI, I'm not from EMC.)
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
|
|
|
