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/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 02/12/2004 09:15 Please respond to "ADSM: Dist Stor Manager" To [EMAIL PROTECTED] 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
expire.dir.out
Description: Binary data
