* Bill Smoldt <[EMAIL PROTECTED]> [2004:03:02:08:21:09-0700] scribed: > Michael, > > What are you intending to archive on the disk array? You can't see the > files on the disk in their native format. You can't archive the disk > storage pools because they're locked by TSM. Unless the native files are > stored on this disk array, you would have to archive from the clients, not > archive the data on the disk array. Perhaps there is more to your archive > plan than you've mentioned?
Thank you. I admit, I am not well versed in the Archive functionality, hence my posts and questions ;> Research has turned up `portable client backup set' functionality. This looks to fit the bill, except I am not clear _how_ to apply this in batch mode to all clients? Can this be used, and then expire the backup set when the tapes are returned onsite and made available in the tape magazine? > The second data center configuration makes much more sense. Presumably, you > have virtual volumes at each data center for the other. A critical missing > element in what you're revealing to us is the speed of the link between the > two datacenters and the volume of data that changes daily. Without that > information it's impossible to know if the configuration is realistic. OK, my client is mysterious and gun-shy. Upper management has discussed shelving TSM and buying BackupExec, or some other ;< However unusual and un-optimal their current situation is, they are not interested in re-architecting their backup system again, for the sixth time. I may be able to get to that point; but, only after I demonstrate considerable value -- even if that value is illusory and only addresses what they insist that they want done now. I believe that they are right, insofar as my client needs to take data offsite. Under the status quo, the easiest way to accomplish that -- right now -- is to copy data to tape, and take tapes offsite. Do you disagree? Please, let me put my predispositions aside. What data do you suggest that we put on tape, how do you suggest that we get it there, and how do you suggest that we rotate tapes offsite? What do you think? > -----Original Message----- > From: Michael D Schleif [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 02, 2004 7:45 AM > To: [EMAIL PROTECTED] > Subject: Re: archive to tape ??? > > * Steve Harris <[EMAIL PROTECTED]> [2004:03:02:16:18:51+1000] > scribed: > > Weird requirement. > > Yes. > > > Not something that I'd recommend. And I don't see the logic for having > > only part of the data, but, its an intellectual challenge as to how > > this can be done. > > Their design is a bit more complex than I originally posted. They have a > second data center (DC), and there, a second TSM using a second disk array. > TSM#1 in the main DC#1 is supposed to replicate itself in TSM#2 at DC#2. > DC#2 is supposed to house failover servers for all critical servers at DC#1. > In the event of catastrophic failure at DC#1, TSM#2 (and DRM#2?) are > supposed to recover to these failover servers at DC#2, and all will be back > online in a few hours. I am not yet privy to the reality of this setup, and > I do not believe that this is fully functional as I write this; but, that is > their idea. > > Also, they have already spent alot of money, and a parade of consultants > precede me. They need to minimize cost to whatever they do that they are > not already doing. I hope to demonstrate my value by implementing a sound, > and simple, and inexpensive tape solution -- then, I may have opportunity to > get them to question their overall strategy. > > > Try this > > > > Set up a random diskpool big enough to hold one nights backup. > > Point backup at this. > > Set up a main sequential file diskpool. Make this the nextstg of > > the nightly pool with manually controlled migration between the two. > > Each day, run a backup stg from the nightly pool to the tape pool > > and send the tapes off site. Then migrate the nightly pool to the > > main pool. > > Script a tape return process keyed on the state and update date of > > the drmedia table. > > When the tapes come back, run a delete vol discardd=yes on them. > <snip /> > > OK. Thank you, for your ideas. > > But, what about my idea to _archive_ from the disk array to tape? Is that > not doable? What are the flaws in this idea? Comments? > > > >>> [EMAIL PROTECTED] 02/03/2004 13:05:26 >>> > <snip /> > > > The client says that they want to copy daily to tape only the most > > recent version of files that have changed since previous day. > > > > They will accept copy daily to tape all most recent file versions. > > > > Each morning, those tapes last written will be taken offsite, and > > tapes from seven (7) days ago brought back onsite and available. > > > > Furthermore, there are two (2) offsite locations, one for Windows > > platforms, and one for *NIX platforms. > > > > > > I am thinking that this can be accomplished by _archiving_ from the > > arrays to tape. I am not clear how to specify policy. Any ideas? > <snip /> -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . --
signature.asc
Description: Digital signature
