ADSM-L

Re: Client/Server Expiration Problem (long post)

2004-02-12 11:54:29
Subject: Re: Client/Server Expiration Problem (long post)
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 12 Feb 2004 09:53:48 -0700
OK, I'm probably missing something in what you are saying, but I still
don't understand. Excluded files are expired during regular (full)
incremental backup processing. Nothing has changed in that regard. Using
EXPIRE has the same effect as EXCLUDE: The files are expired on the TSM
server and managed per criteria as deleted files (i.e. subject to
VERDELETED, RETEXTRA, and RETONLY).

I've attached sample data for directory c:\amrtest. The steps I performed
are as follows:

a) Ran QUERY BACKUP to show the existing active and inactive versions.

b) Defined a client option set that contains an EXCLUDE.DIR statement for
c:\amrtest (not shown here).

c) Ran INCREMENTAL. Note the expiring files.

d) Repeat (a) above. This time note that there are fewer versions (VERE=5,
VERD=2). All versions are inactive and will expire per management class
criteria.

Is there anything here that does not accomplish what you wish? By the way,
the EXPIRE command would do the same thing: leave the 2 versions due to
VERDELETED, which will expire based on RETEXTRA and RETONLY value.



Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.



"Gretchen L. Thiele" <gretchen AT PRINCETON DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
02/12/2004 09:15
Please respond to
"ADSM: Dist Stor Manager"


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: Client/Server Expiration Problem






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

Attachment: expire.dir.out
Description: Binary data

<Prev in Thread] Current Thread [Next in Thread>