Once a backup version becomes inactive, normal inventory expiration processing
on the ADSM server should handle expiring the inactive versions, regardless of
whether the file system has been deleted. The issue then becomes how the active
backups are handled.
Active backups are never deleted by inventory expiration. This is because the
active backups are intended to reflect the state of the file system as of the
time that file system was last backed up, regardless of how long it's been
since the last backup.
In order for an active version to be automatically deleted via ADSM client
processing, it must first become an inactive version. Some reasons that a
backup version may become inactive include:
* A newer backup version of the file is made
* During incremental processing of the file system, ADSM detects that the file
no longer exists
The key phrase in the second item is "During incremental processing of the file
system". If ADSM can not detect the file system, then it can not traverse it to
determine whether the file has expired. Thus it can not cause the active
version to become inactive.
In sum, in order for the ADSM to automatically delete backup versions:
1) Inventory expiration will automatically delete inactive versions that meet
the copygroup version and retention criteria.
2) Active versions must become inactive before inventory expiration can delete
them.
3) Active versions do not become inactive until a newer backup version is
created, or the ADSM client detects that the file no longer exists on the file
system.
4) The ADSM client can not detect that the file no longer exists unless it can
traverse the file system.
5) ADSM can not traverse a file system that it can not see.
6) ADSM can not assume that it should delete the filespace on the ADSM server
just because it can not see the file system on the client.
Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com
ADSM-L AT VM.MARIST DOT EDU on 05/26/98 09:47:14 AM
Please respond to ADSM-L AT VM.MARIST DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: How do you deal with...?
This is a good point, but I would like the backup copies to expire
as they would have anyway. I use RETE and RETO to control backup
retention. VERE and VERD are both "No Limit". I expect backup
copies for most files to expire in X days (X is currently 14, but
we're planning to increase it soon). Once a week, I activate policy
sets whose copy groups have the "absolute" flag, so it's like a full
backup. Yes, I know this is contrary to ADSM's design philisophy,
but it's what we want...
The best option I saw in the responses so far is to do "Q FILES F=D"
and look at "days since last backup", but it's something I wish would
just work as one would expect.
I appreciate everyone's input.
--
Gene Mangum
Gene Mangum
University of Michigan Medical Center
On Tue, 26 May 1998, Andrew Raibeck wrote:
> ADSM can determine that a file system is not present, but it can not determine
> *why* it is not present. While it is possible that the file system has been
> deleted, it is also possible that it simply is not mounted, or that it has
been
> renamed.
>
> For example, on Windows NT, if I have a volume (file system) named APPS and I
> rename it to MY_APPS, then ADSM will detect that APPS no longer exists. It
will
> also detect the presence of a new file system, MY_APPS, but it can not
> necessarily conclude that MY_APPS is what used to be APPS. Maybe I meant to
> rename the ADSM APPS filespace to MY_APPS, but forgot to do it. In this case,
> it would be an unhappy situation if ADSM arbitrarily decided to delete the
APPS
> filespace from ADSM's inventory. Thus ADSM prefers to err on the side of
> caution, and not automatically delete a filespace just because it can't "see"
> it.
>
> Andy Raibeck
> IBM Storage Systems Division
> ADSM Client Development
> e-mail: storman AT us.ibm DOT com
>
>
>
> ADSM-L AT VM.MARIST DOT EDU on 05/25/98 02:11:19 AM
> Please respond to ADSM-L AT VM.MARIST DOT EDU
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: Re: How do you deal with...?
>
>
> >I'm wondering how large shops deal with the problem that when a filesystem
> >is deleted from a client, ADSM will not expire backups of files in that
> >filesystem. I had expected that it should treat them just as deleted
> >files, ...
>
> I would also expect them to be treated as deleted files. What is the
philosophy
> behind this anomalous behaviour? Is it documented? I don't think large shops
> should have to run around in circles looking for this situation.
>
> Could IBM comment on this, please?
>
> Bob Matthews,
> University of Geneva.
>
>
>
>
|
