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?
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. Bill Smoldt STORServer, Inc. -----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 . . . --
