ADSM-L

Re: Management Class Difficulties

1998-11-19 16:52:11
Subject: Re: Management Class Difficulties
From: Tom Tann{s <tom.tannas AT USIT.UIO DOT NO>
Date: Thu, 19 Nov 1998 22:52:11 +0100
This sounds strange..
If you are talking about directories, this is how the binding is
supposed to work, unless you use the dirmc-option.
Are you sure these files were files? (hmm..)
I've never seen problems whith the mgm-class-bindings (V2 or V3)
(All this for unix-clients. I can't say for sure for the rest..)

                     Tom

On Thu, 19 Nov 1998, Glass, Peter wrote:

> A client requested an extended retention for some files already backed up
> under our STANDARD Management Class.
> I created a new Management Class within the same Policy Set with this
> extended retention, and asked this client to specify this new Management
> Class in their next backup, with the idea that their files will then be
> rebound to this new Management Class. The default Management Class remained
> as STANDARD.
> A few weeks went by. The client decided that they didn't need to extend
> their files' retention after all, and so never used the new Management Class
> I set up for them. I then deleted this Management Class.
> We then began to receive error messages from various clients' backups that
> the Management Class that I had defined/deleted had no Copy Groups defined,
> and so the backup grace period would be assigned to these files.
> I found out subsequently that, even though Management Class STANDARD was the
> assigned default, ADSM will actually pick the Management Class with the
> longest retention as the default (which somewhat negates the idea of
> assigning a Management Class as a default, seems to me). Apparently, all the
> backups assigned to this policy domain rebound themselves to this new
> Management Class, simply because it had a longer retention than the default.
> My questions on this are:
> 1.      When I deleted this temporary Management Class, why didn't the
> clients' files rebind themselves back to the assigned default Management
> Class, as the Admin Guide says they would, instead of taking the grace
> period retention?
> 2.      What is the best way to resolve this situation? I redefined the
> missing Management Class, but with the same retention as the STANDARD
> Management Class. The error messages went away, but did this fix the
> problem? Did the files that were given the grace period retention get
> rebound back to the default management class, or would they still be subject
> to the grace period retention?
> 3.      How about ARCHIVE Management Classes: If you have multiple ARCHIVE
> Management Classes within the same Policy Set, does ADSM ignore the assigned
> default Management Class in favor of the one that has the longest retention,
> as it does with BACKUP? For example, if we have an assigned default ARCHIVE
> class with a 365 day retention, and another class with a permanent
> retention, does that mean that the permanent class is the actual default
> class by virtue of its longer retention?
>
<Prev in Thread] Current Thread [Next in Thread>