Yes. And you can forget the consultancy and the arguments about backups
not being archives etc, the keeping hardware and software to run the old
system etc.  Have been through all that with the business.

Data needs to be retained offsite for 25 years.  Its the industry my
company is in.   As a result, I need to generate these archival offsite
tapes - whether via TSM Backup sets or TSM Archives.     
TSM backup sets + TOC appears the quickest way of doing it - and perhaps
a yearly TSM Archive will be run as well (which will then be less
dependant on the tsm server db) 



>
> You mean a business requirements to retain some data for 25 years?
> Backups are not archives. Really repeat after me, "backups are not
> archives". I can think of no legitimate reason to retain backups for
> more than maybe 2 years, and even that is pushing it.
>
> Here's a bit of free consultancy ;)
>
> When retaining TSM backupsets, are you also retaining:
>
> 1- drives that can read the tapes
> 2- software versions that can read the media and interpret the data
> 3- hardware that can run that software
>
> Have you considered that even enterprise archival tapes are only
> guaranteed for 10 years?
>
> This is a very hard problem to solve and I really don't believe that
> it's easy to have TSM be part of the solution. If you have a real
> business-case, make a real design, assume nothing but open standards.
> You'll probably wind up writing tapes in tar or cpio format with
> plain-
> text, pdf or maybe odf formatted files and copying those tapes over
> every year or so. IBM is a very big company, but I doubt that even IBM
> will guarantee availability of software that can interpret current TSM
> on-tape format in 25 years. And that is just one link in the chain.
>
> In the old days there were people that specialized in retaining data,
> called archivists. Now, in current day and age, anyone thinks that can
> do this on a PC, but really there are just to many thing to think of.
>
>> -----Original Message-----
>> From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On
>> Behalf Of
>> Nick Laflamme
>> Sent: Sunday, 28 December 2008 3:39 AM
>> To: ADSM-L@VM.MARIST.EDU
>> Subject: Re: [ADSM-L] Backupset media goes to Copypool too?
>>
>> On Dec 26, 2008, at 9:10 PM, Cheung, Richard wrote:
>>
>>> Hi...
>>>
>>> So if i wanted these to be kept offsite AND onsite, do I need to
>>> issue a
>>> manual copy command?
>>
>> The following is speculation, but I'll bet a beer at SCIDS that the
>> premise is valid.
>>
>> If you want two backup sets, run the command twice. Presumably, after
>> each one, you'll CHECKOUT the LIBVOLs on which the backup set was
>> created. What you do with the media once it's out of the library is
>> up
>> to you. Send one to an off-site repository, or store one is a user's
>> office so they "know" they have a copy of their data, it's up to
>> them.
>>
>> Like database backups, backup sets are created on a device type but
>> are not part of storage pools. They're just "different."
>>
>> Remind me, why are you so gung-ho to have backup sets in the first
>> place? What problem are you solving?
>>
>> Nick
>>
>> <html>
>> <body>
>> <font face="arial" color=#808080 size="-2"><img
>> alt="Santos Logo" src="http://www.santos.com/library/logo.gif";>
>> <br>Santos Ltd A.B.N. 80 007 550 923<br>
>> Disclaimer: The information contained in this email is intended only
>> for the use of the person(s) to whom it is addressed and may be
>> confidential or contain privileged information.
>> If you are not the intended recipient you are hereby notified that
>> any perusal, use, distribution, copying or disclosure is strictly
>> prohibited.
>> If you have received this email in error please immediately advise
>> us by return email and delete the email without making a copy.</font>
>> <font face="arial" color=#008000 size="-2">Please consider the
>> environment before printing this email</font>
>> </body>
>> </html>
>
> --
> Met vriendelijke groeten,
>
> Remco Post
> r.p...@plcs.nl
> +31 6 248 21 622

--

Remco Post
r.p...@plcs.nl
+31 6 24821 622

Reply via email to