Francis Swasey wrote:
> It is not a "no issue" ...
I know Frank, I know and agree wit hyou. I was just quoting EMC. I submitted
a ticket with teh request to change "mminfo" behaviour in terms of
volretent,clretent and ssretent, but it's like hitting a brick wall with a
forehead. They are insisting that everything "works as designed", here's their
detailed explanation why your, my and others' problem is not a problem at all
and why we all should be happy:
>
> This is NOT a bug. In 7.3 NW and beyond, the Individual Clone Retention
> Policy feature introduced the concept of "saveset-clone-instances" for a
> saveset, each residing on a seperate volume. a) Each
> saveset-clone-instance(unique "cloneid") has its own "retention
> period"(configurable) - and that is represented via "clretent" field in
> "mminfo". b) So, "ssretent" is the "saveset retention period" - and that is
> the MAX of the "clretent" value among all the "saveset-clone-instances". You
> need to check what the "clretent" values are for each of the
> saveset-clone-instances(have same "ssid" but different "cloneid") - the
> "ssretent" for ALL the instances will be the SAME and it will be the MAX
> value of the "clretent". Logically, a "saveset" does not "expire" until ALL
> its instances "expire". So, there will be one "recoverable"
> saveset-clone-instance until the period noted in "ssretent" is passed. The
> "clflags" will reflect the state of the "saveset clone instance"(browsable,
> expired!
) and the "ssflags" will report the status of the "saveset" in general - the
"ssflags" will show "E" only when ALL of the clone instances(note, each
instance is on a different volume) of that saveset have "expired" and the
"clflags" of ALL show "E". Hope this explanation is clear enough. The "mminfo"
query to run, to compare "ssid", "cloneid", "ssretent" and "clretent" would be
something like: mminfo -q "name=" -r "ssid, cloneid, ssretent, clretent,
ssflags, clflags, volume"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ c) WRT
"volretent"(volume retention period), the logic is: A volume "expires" when ALL
the saveset-clone-instances on it "expire"
======================================================================== So,
when the "saveset-clone-instances" pass the individual "retention period"(noted
by "clretent"), they "expire". And, when ALL of them existing on the volume
pass their Individual Clone Retention period, the volume is marked as "exp!
ired"(eligible for recycling). d) That means that "volume retention pe
riod" is the MAX of ALL the "clretent" values of ALL the
saveset-clone-instances on that volume. So, you need to check all the
"saveset-clone-instances" on that volume for the "clretent" values, and the
"volretent" will be the MAX of the "clretent". noted. You could run "mminfo" to
check this: mminfo -q "volume=" -r "ssid, cloneid, ssflags, clflags, ssretent,
clretent"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The
volume will not "expire" until ALL the saveset-clone-instances on it "expire" -
thats is, they pass their "clretent" and "clflags" show "E"). That is,
"volretent" is based on "clretent" values of the saveset-clone-instances on
that volume. NOTE: the "ssflags" may or may not show "E" - and "ssretent" may
or may not be greater than the "volretent". As "ssflags" and "ssretent" take
into consideration ALL the saveset-clone-instances for a saveset(each clone of
a saveset resides in a seperate volume) before marking the saveset as "expired!
" or "eligible for recycling". Hope the above explanation is clear. The 7.3
and above Manpages and Admin Guide can be referred for additional info.
>
+----------------------------------------------------------------------
|This was sent by dmitri_ryjikh AT ml DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT 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
|
