Several reasons:

1.  I already have the exact file versions I want to have in TSM, and have 
no functional reason to create another set of tapes.  It is offensive to 
the spirit of TSM to create an additional file copy, especially when I 
have no capability to use them to locally restore the node. 
2.  Tapes (and tape drive usage) are expensive.  I get one tape per node; 
when you have 100GB tapes and 20GB nodes, this is a problem.
3.  There is no second copy.  If the data are that important, don't I want 
media protection, especially if I'm keeping the data 7 years?  And how do 
I recopy the data periodically, as required for long term data retention? 
And how do I migrate to new media?
4.  In noncollocated environments, I will have to mount a number of tapes 
to create the backup set at the end of the month, and I will have to do it 
over and over for each node.
5.  Backupsets are very inconvenient to restore from.  You can either 
restore the entire dataset, or use the commandline to try to pick out 
exactly the file you are looking for.  If you make a mistake, it searches 
the whole thing before it fails, and you start over.
6.  The backupset tapes are another thing to manage.  At one time they did 
not expire properly; I don't know if that has been fixed or not.

Sorry about the rantish tone, but you did ask...

_____________________________
William Mansfield
Senior Consultant
Solution Technology, Inc





Burak Demircan <burak.demircan AT DAIMLERCHRYSLER DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/16/2002 07:58 AM
Please respond to "ADSM: Dist Stor Manager"

 
        To:     ADSM-L AT VM.MARIST DOT EDU
        cc: 
        Subject:        Re: Monthly Backups, ...again!


Hi, 
Why dont you think of backupsets? They do not require database usage and 
easy 
to use? 
Just create backupset at the end each of period (year or month) and send 
them 
to 
offsite with the volume history file. What else could be missing in that 
senario? I think : nothing. 
Regards, 
Burak 



 
        WMansfield AT SOLUTIONTECHNOLOGY DOT COM 
        Sent by: ADSM-L AT VM.MARIST DOT EDU 
 
        16.04.2002 15:53 
        Please respond to ADSM-L 
                        
                        To:        ADSM-L AT VM.MARIST DOT EDU 
                        cc:         
                        Subject:        Re: Monthly Backups, ...again!

I only wish I had a way to assign different retentions to active files, I
don't actually have one. 

While I'm wishing...I wish I could pick an historical point in time, and
reset the retention for the versions corresponding to that point in time
to an arbitrary value. 

_____________________________
William Mansfield
Senior Consultant
Solution Technology, Inc 





"Don France (TSMnews)" <DFrance-TSM AT ATT DOT NET>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/13/2002 03:58 PM
Please respond to "ADSM: Dist Stor Manager" 


        To:     ADSM-L AT VM.MARIST DOT EDU
       cc:
       Subject:        Re: Monthly Backups, ...again! 


Bill, 

Your arguments are excellent, and I have one large client dealing with the
health
records issue --- they need to save patient records for 32 years;  we are
liking
the export solution, once a year, for those nodes (in order to control TSM
db
size) -- and, continue storing their data in archive storage so we have
access to
all versions generated, then (AFTER THE FACT) deleting extra versions from
each month --- save 2 or 3, delete the rest from archive storage, using a
"smart"
script in concert with the dba's technique of naming the files being
stored. 

However I only know ONE (simple) way to accomplish the desired, stated
results ---
month-end snapshot kept for X months
or years;  ie, a backupset of the desired file systems on specific nodes.
The limitation
of this solution is it only captures files in backup storage;  you need a
different
answer for database backups stored in archive storage -- my DBA's love
using
archive storage, and I have no argument against it, as they only care
about
time
(have no need or interest in counting versions, etc), and they must save
daily
backups for 4-14 days, weekly's for 6 weeks, monthly's for 6-15 months,
etc. 

If you have a method that allows you "mark" the currently active versions
of
backup
files with a different retention than others, I think it would be new news
to most of us...
please share. 

Thanks,
Don 

 Don France
Technical Architect - Tivoli Certified Consultant
Professional Association of Contract Employees (P.A.C.E.)
San Jose, CA
(408) 257-3037
don_france AT att DOT net