* Bill Smoldt <smoldt AT STORSOL DOT COM> [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:mds AT HELICES DOT ORG]
> Sent: Tuesday, March 02, 2004 7:45 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: 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 . . .
--
signature.asc
Description: Digital signature
|
