Hi, I would think that collocation would be the solution, but I would caution that collocation by node with "a couple hundred" nodes equals "a couple hundred" tape mounts each morning for migration. I would suggest that you look closely at two things:
1) Is there a subset of servers that are of critical importance. We have a rating scale that basically defines SLA's including a restore time SLA (which no one asked the backup admin about before they defined). If there is a subset, then put the critical servers into another pool and use collocation on that pool. 2) Upgrade to 5.3 and use collocation 5.3 and use collocation by groups. Basically you create collocation groups which says that this group of nodes can be on a set of tapes together. This greatly reduces the tape creep, but also requires more tapes that #1 above. In this case, you would have tape mounts equaling at least the number of collocation groups you have. Either way you will have to migrate that data from the current tape pool to a new one to reorg it. Additionally, collocation is largely not useful on copy pools unless you have a remote library or something of that nature. IMHO, the holy grail for all of this is disk based virtual tape libraries. None of us would care about the number of tape mounts if they tool 5 ms instead of 30-60 seconds. Granted, tape will always have its place (can anyone say oracle backups), but for windows servers with tens to hundreds of thousands of small files, tape can be difficult even at its best. My $0.02 Michael Wheelock Integris Health of Oklahoma -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Jones, Eric J Sent: Monday, November 14, 2005 9:05 PM To: [email protected] Subject: Re: Backup question - Full and Incremental Thanks. The problem I have is the backup policies where set long before I arrived. I'm working to correct what we have so it's more efficient. My thought initially was to do a full backup on some of the key servers to get the data on a single tape so it is not on so many tapes then work on a long term solution. Collocation was something I was considering but needed to do more homework to understand what affect it would have. We have a few hundred servers that backup and I wanted to understand the full effects of collocation before implementing. A full backup would give us a short term solution while working on the long term solution. Thanks Eric -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Monday, November 14, 2005 7:42 PM To: [email protected] Subject: Re: [ADSM-L] Backup question - Full and Incremental On Nov 14, 2005, at 3:19 PM, Jones, Eric J wrote: > ...We normally just run incremental for all our machines and over the > years > the data gets scattered every where(number of tapes and in some cases > 30+) so restores can be very slow. ... Eric - The magic word "collocation" does not appear in your posting. It is the standard means by which data, related by node or filespace, is kept together. That, plus reclamation, minimizes the number of tapes needed to perform a restoral. Being a full-featured product, TSM provides a host of capabilities by which one may satisfy enterprise data recovery needs. A storage pool hierarchy involving frontal disk, migration, caching, and copy storage pools will allow quick restoral of most recent data. Full backups can be done, but are often testimony to an ill-thought-out backup/restore architecture. Review redbook "IBM Tivoli Storage Management Concepts" and the Administration Guide manual for methods by which client-sent data may be managed. This topic is also heavily represented in the List archives. A good data recovery design focuses first on restoral methodologies and performance, then looks at realistic approaches to backup to facilitate restoral. Richard Sims
