ADSM-L

Re: Client/Server Expiration Problem

2004-02-12 11:32:00
Subject: Re: Client/Server Expiration Problem
From: Bill Kelly <kellywh AT AUBURN DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 12 Feb 2004 10:31:31 -0600
Hi,

If I understand correctly what you're trying to accomplish (perhaps a big
'if'), then...

I needed to do something similar recently.  The problem for me was that
files that you exclude are marked inactive, but kept around on the server
according to the retention criteria for the mgt class that applies.  My
solution was:

1) decide on the files/directories to be gotten rid of.

2) set up a new mgt class with the minimal retention criteria - 0 days, 1
copy, etc.

3) implement include statements (either in opt files or client option
sets) that rebind the stuff you want to get rid of to that new mgt class.
This is where you get wildcards, etc. into play.

4)  leave this in place until most of the clients you care about have done
incremental backups and rebound the files

5) change the include statements to excludes.

On the next backup, files are marked as inactive and will go away during
the next expiration process.

As I said, I may well not understand what the problem for you is, so this
posting may be a waste of people's time.  If so, sorry!  I'll go back to
lurking.  :-)

Regards,
Bill

Bill Kelly
Auburn University OIT
334-844-9917


On Thu, 12 Feb 2004, Gretchen L. Thiele wrote:

> I've tried this, but the files are not expired on the server
> (no Expiring ---> message in the dsmsched.log). The unexpected
> or unpleasant side effects that I am referring to are actually
> expiring the files on the server - maybe people didn't expect
> this to work this way? Principle of least astonishment? Should
> I expect to see expiring messages or a change in the number
> of files expired (when I run the incremental manually)? When I
> change the dsm.opt and run either the scheduled incremental
> or a manual incremental, run the server expiration, then check
> from the client, the files I want to get rid of are still there,
> both active and inactive versions.
>
> I don't have a problem with excluding a directory. My problem
> is getting the files to expire on the server after I have
> excluded the directory. I want to be able to modify the client
> dsm.opt file (or in our case, put these statements in a
> client option set) to implement our new policy, and then
> run an expire command on each client to force the expiration
> of the files on the server that aren't part of the new policy.
>
> I can do this if I specify each and every directory and
> subdirectory on the client, but this could run into the
> thousands and would be different on each computer. I need
> the client expire command to support directory wildcards
> or recognize the -subir=yes option. Maybe the exclude on
> the client should force the expiration of those files on
> the server?
>
> Andrew Raibeck wrote:
>
> > Gretchen, I don't understand the following:
> >
> >
> >>Prior to the v4.2 client, you could simply exclude the files on the
> >>client side and the files would be expired. This probably led to
> >>unpleasant/unexpected results, so this doesn't work anymore and the
> >>client expire was introduced.
> >
> >
> > What unpleasant/unexpected results are you referring to? If no longer wish
> > to back up files in c:\junk and it's subdirectories, then I don't see why
> > using EXCLUDE.DIR wouldn't work. You could use a client options set to do
> > this.
> >
>
> Gretchen Thiele
> Princeton University
>