* Salak Juraj <j.salak AT ASAMER DOT AT> [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:mds AT HELICES DOT ORG]
> Gesendet: Dienstag, 02. März 2004 15:45
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: archive to tape ???
>
>
> * Steve Harris <Steve_Harris AT HEALTH.QLD.GOV DOT AU>
> [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?
>
>
> > >>> mds AT HELICES DOT ORG 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
|
