ADSM-L

Re: Deleting backup files/API from Visual Basic

2004-10-05 05:06:34
Subject: Re: Deleting backup files/API from Visual Basic
From: "Warren, Matthew (Retail)" <Matthew.Warren AT POWERGEN.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 5 Oct 2004 09:32:04 +0100
Hello,

This sounds like you just need a management class setup to immediatley
expire files deleted on the workstation.

You can do this with the VERsionsDeleted and RETainOnly parameters in a
backup copygroup. If you set them both to 0, the next time an
incremental is run against the workstation, TSM will notice the file is
deleted and mark it for expiration. Next time expiration runs on the TSM
server, the file will be deleted from its inventory.

Matt.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Matuschak, Brian J
Sent: Monday, October 04, 2004 8:54 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Deleting backup files/API from Visual Basic

Richard:
 
Thanks for your "call above the line of duty" service.  I believe "what
goes around comes around" with the caveat "but not always in the way you
expect!" in terms of how it gets back to you, so I try to help and
volunteer in other subjects I have more expertise in to keep the cycle
going.
 
Anyway, to clarify the client need, once a particular file is deleted
from a particular network workstation, he merely wants to make it
impossible for that file--which was previously backed up--to be restored
back to the original location from the backup tape.  Fortunately, he
doesn't care whatever method I use to prevent the file from being
restored.  If it's as simple as having the application take a selected
file and scripting dsmc to do an immediate expiration, he will be happy.
 
Meanwhile, I have to wait for him to have someone forward me the
technote you suggested since I don't have the IBM number--GRRRRR!  But
at least I can rephrase the question to "How do I prevent a single file
from being restorable?"
 
Thanks again,
 
Brian J. Matuschak
Ciber, Inc.
BMatuschak AT ciber DOT com
(425) 284-1319

________________________________

From: ADSM: Dist Stor Manager on behalf of Richard Sims
Sent: Fri 10/1/2004 8:56 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Deleting backup files/API from Visual Basic



>I'm working on a project where the client wants to have individual
files
>deleted from backups in TSM 5.2 0.0; his organization does not use
>archives. ...

Welcome to the product, and the List, Brian.

>From time to time we see postings like this from client customers who
spring for a big, expensive product like TSM and then completely ignore
what it's all about, seeking instead to have it do things which are
contrary to its nature.  Very much a Dilbert P.H.B. scenario.

That client may not use Archives, but obviously should for this
expressed need.  You can otherwise try to bend the product to make
it do what they want, but I doubt that anyone involved in the effort
will be happy with the result.

Stay away from anything which is not a standard, supported part of
the product, which is to say Delete Object.  There are procedural
alternatives: one is found in the IBM site Technote 1166278, "How
to remove a single file from a TSM backup tape volume".  But not
trivial.  Another approach is to employ limited retentions for
Inactive files and then do 'dsmc EXPire'; or do a selective backup
on an empty surrogate file to push the real data out of existence
in the TSM storage pool; or just Exclude the file to incite its
expiration.

Overall, though, I don't get the sense that the client has fully
defined EXACTLY what they want to achieve.  A file not in the Backup
storage pool implies that the file is no longer in the originating
file system - which doesn't seem like the situation they'd have (but
which is the inherent, most simple way that files expire out of TSM).

That client obviously does not understand what "backup" means, or
perhaps care.  Archive was created for what they want to do.
Have them define their requirements in detail, and then outline
the aspects of the product which meet their needs.  Beyond that,
a whole different methodology - and perhaps product - would be
called for.

   Richard Sims     http://people.bu.edu/rbs


___________________________ Disclaimer Notice __________________________
This message and any attachments are confidential and should only be read by 
those to whom they are addressed. If you are not the intended recipient, please 
contact us, delete the message from your computer and destroy any copies. Any 
distribution or copying without our prior permission is prohibited.

Internet communications are not always secure and therefore Powergen Retail 
Limited does not accept legal responsibility for this message. The recipient is 
responsible for verifying its authenticity before acting on the contents. Any 
views or opinions presented are solely those of the author and do not 
necessarily represent those of Powergen Retail Limited. 

Registered addresses:

Powergen Retail Limited, Westwood Way, Westwood Business Park, Coventry, CV4 
8LG.
Registered in England and Wales No: 3407430

Telephone +44 (0) 2476 42 4000
Fax +44 (0) 2476 42 5432