Very interesting. It sounds to me like an opportunity for Tivoli to create a white paper for us TSM admins on "Best Practices in a Disk-Only TSM Environment". Although I would really prefer that they come up with a solution for the DISK fragmentation problem so that I don't have to cludge around with FILE types. While they are at it, maybe an online database defrag utility would come in useful as well...
Steve Schaub Systems Engineer, Operations & Storage Haworth, Inc 616-393-1457 (desk) 616-886-8821 (cell) [EMAIL PROTECTED] -----Original Message----- From: Richard Rhodes [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 02, 2004 12:54 PM To: [EMAIL PROTECTED] Subject: Re: D2D backup with TSM Thanks for all the replies . . . . an interesting discussion. That is an interesting presentation Tim pointed to. It answeres lots of questions. It's sounding like using only a DISK device pool for d2d backups isn't a very good idea. But FILE device pools seem to be limited. It sounds to me like you want to keep DISK device pool for staging are just like we do today, providing multiple concurrent access for backups. Then, migrate the files to FILE device pool for long term storage. And, make sure you turn on client compression. Also, realize that all the files for the FILE device pool will have to be in one filesystem. The copy storage pool could be a FILE device pool on another disk system, or, a tape system if you need to ship them offsite. Since I have experienced disk subsystem crashes with loss data, I couldn't ever use just one disk system. I think I'd have to have separate disk systems for the primary pools and copy pools (or tape), and maybe even a third subsystem for the db and staging pools. Yes, I've been called paranoid . . . but it comes from experience. Thanks! Rick "Rushforth, Tim" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] PEG.CA> cc: Sent by: "ADSM: Subject: Re: D2D backup with TSM Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 06/02/2004 12:23 PM Please respond to "ADSM: Dist Stor Manager" That can only be done on a sequential access pool. If you try on a storagepool of device type disk you will get: ANR1718E MOVE DATA: Reconstruction of file aggregates is supported only for movement in which the source and target storage pools are sequential-access. ANS8001I Return code 3. -----Original Message----- From: Steve Schaub [mailto:[EMAIL PROTECTED] Sent: June 2, 2004 11:03 AM To: [EMAIL PROTECTED] Subject: Re: D2D backup with TSM I was under the impression that performing a "move data xxxxxx reconstruct=y" would reconstruct the aggregate, thus effectively performing reclamation on a disk type volume. Probably not what the TSM developers intended it for, but it might be just the ticket for those moving to disk-only infrastructures (and not wanting to use file based volumes). Steve Schaub Systems Engineer, Operations & Storage Haworth, Inc 616-393-1457 (desk) 616-886-8821 (cell) [EMAIL PROTECTED] -----Original Message----- From: Rushforth, Tim [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 02, 2004 10:39 AM To: [EMAIL PROTECTED] Subject: Re: D2D backup with TSM > When would an aggregrate be reclamed when using a DISK device pool? > Rick Once again check out http://ew.share.org/callpapers/attach/Long_Beach_Conference/S5725a.pdf There is a table that compares Disk Pools (Random Access) to Seq File Disk pools. The answer is aggregrate reconstruction is not supported on disk pools.
