* Salak Juraj <[EMAIL PROTECTED]> [2004:03:02:18:05:33+0100] scribed: > Hi, > > > 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? > > What do you mean by archiving from disks?
Currently, instead of tape, my client successfully uses TSM to `backup' to 6TB disk array. Not being expert in `archive', I thought that an archive can be generated from TSM database, data for which resides on that 6TB disk array. > What do you not like by backup storage pools? I do not have problem with backup storage pools, per se. In fact, that may turn out to be the optimal solution to the problem. > Once you can afford moving tapes physically offsite, > this works great. What do you mean, ``afford moving tapes physically offsite''? > I would suggest you describe less what others suggested, > but what your business needs are: > > - what is "your" catastrophic failure (TSM failure? OS failure? > Total TSM HW failure? Whole server room destroyed but network > still working? Whole server room including routers, switches, > cables burned down? > Whole building burned out including all safes and their content? > Both primary and secondary site burned down (twin towers case)? The catastrophic failure my client wants to address is the total destruction of DC#1 (data center). In that event, although TSM#2 at DC#2 is supposed to be an exact mirror of TSM#1 at DC#2, which no longer exists, my client wants to know that they have at least two (2) recovery options: [1] recover from TSM#2, or [2] recover from offsite tape. > - what shall work how soon after the catastrophic failure? > Is it enough TSM Server be available 6 hours after failure? > Or must be all restores of all file servers totaling > million files and 1 TB done 6 hours > after failure? Current expectation is twenty-four (24) hours for _all_ critical servers to be functional. > - how old may be the restored data? Day? Two? Week? An hour? According to plan, no data in TSM#2 nor on offsite tape will be _less_ current than forty-eight (48) hours. > - can you afford moving tapes physically offsite? How often? Yes, in my original post, that is the *whole* idea behind my current project: The client says that they want to copy daily to tape only the most recent version of files that have changed since previous day. > - what online connection to your second site you have? T1 -- soon to be DS3. > - what TSM Hardware do you currently have? IBM 345 server, w2k, sp3 3ware IDE over SCSI arrays, currently 6TB, 2TB yet unpopulated Overland LoaderXpress LTO-2, including 11-slot magazine > Such kind of information will make it easier for forum members to give you a > sound advice. Thank you. > -----Urspr�ngliche Nachricht----- > Von: Michael D Schleif [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 02. M�rz 2004 15:45 > An: [EMAIL PROTECTED] > Betreff: 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 . . . > -- > -- 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
