Jeff and Kelly ... Don't look to the Tivoli software to solve all the "issues" involved in long-term data storage. Hardware obsolescence must be considered, as well as media life, and having redundant copies, at multiple locations, such as would be recommended in a real DR plan.
Kelly, mixing archive files and backup files, and using reclamation, doesn't quite give me that warm, fuzzy feeling I'd like to have. Archive files are usually the data you absolutely need to protect for regulatory, legal, scientific, or historical reasons! And, if this data is really so valuable, doesn't it follow that it deserves more attention? A separate procedure to "exercise" (read/clean/retension) archive media, refresh the media based on some threshold of read errors, and, ultimately, media/format conversion should be employed, regardless of the volume of data ... Tis a conundrum ! -----Original Message----- From: Jeff Bach [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 13, 2002 8:25 AM To: [EMAIL PROTECTED] Subject: Re: Backup Sets for Long Term Storage Kelly, How often should I refresh my ### Terabytes of longterm storage? Jeff > -----Original Message----- > From: Kelly Lipp [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, February 12, 2002 10:15 PM > To: [EMAIL PROTECTED] > Subject: Re: Backup Sets for Long Term Storage > > I believe the key to long term storage is the notion of data refreshment > on > the tapes. With reclamation, we get that. If archive data is mixed with > backup data we get reclamation due to backup retention policies being much > less (typically) than archive. Some will argue that moving this data > around > isn't efficient, but if ensuring that data can be read is the goal, moving > it around occasionally is important. > > Kelly J. Lipp > Storage Solutions Specialists, Inc. > PO Box 51313 > Colorado Springs, CO 80949 > [EMAIL PROTECTED] or [EMAIL PROTECTED] > www.storsol.com or www.storserver.com > (719)531-5926 > Fax: (240)539-7175 > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of > Seay, Paul > Sent: Tuesday, February 12, 2002 6:36 PM > To: [EMAIL PROTECTED] > Subject: Re: Backup Sets for Long Term Storage > > > I would not put something I wanted to keep that long on "doggies little > toy" > or "ate my momma". You get the picture. I do not think DLT and 8mm are > reliable enough to be comfortable that they will be able to be restored > that > far out. This is a nasty problem for all of us. LTO is too new to bet on > and we are limited by what we can do. In the mainframe world you archive > the stuff and just keep some tape drives around. Open is different. The > issue is the vendors have not stepped up to the fact that open has > longterm > data now, just like a mainframe. > > -----Original Message----- > From: Haskins, Mike [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 12, 2002 7:10 PM > To: [EMAIL PROTECTED] > Subject: Backup Sets for Long Term Storage > > > Our TSM server has a 3494 library with 3590 tape drives. Now faced with > meeting long term storage requirements (7+ years), I am looking at > generating backup sets to accomplish this. Since backup sets can be used > for stand-alone restores from a backup-archive client, I am thinking that > a > different media type would be better than 3590. There's not much chance > that many of my nodes could have access to a 3590 drive. DLT or 8mm seem > more appropriate. Any experiences or opinions would be appreciated. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. ********************************************************************** *************************************************************** This message and any attachments is solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use, or distribution of the information included in this message is prohibited -- please immediately and permanently delete this message.
