(Once more, this time with the _right_ From address. Sigh.)
On 26/08/2004, at 12:40 PM, Steven Pemberton wrote:
On Thursday 26 August 2004 09:19, Stuart Lamble wrote:
Hey ho. Here's the skinny. We will, eventually, have a number of
clients backing up to a TSM server on a regular basis (we're still
setting up the SAN and other ancillary things that are needed to
support the TSM server). Some of them will be filesystem backups;
others will be database backups (which, if I understand correctly, are
most likely to be seen as archives rather than backups as such). The
setup involves two sites, A and B, which have multiple gigabit fibre
connections between them (so they're effectively on the same LAN; the
only real difference is a very small amount of additional latency.)
Systems at site A will backup to a server at site B, and vice versa.
So, you have the following?
1/ Clients at "A" backup to TSM server at "B".
2/ Clients at "B" backup to TSM server at "A".
Yup, pretty much.
Where are you producing the copypool versions? Eg:
1/ Client A -> TSM B (primary) -> TSM A (copy) ?
2/ Client A -> TSM B (primary) -> TSM B (copy) ?
3/ What copy pools? :(
Oh, option three of course -- we want to save money on media! *ducks*
Seriously, though, it'll be option 2, is my understanding -- if site A
goes down, and some of the media at site B is dead, we'd like to still
be able to recover the data. If we lost two sets of media at the same
time, well, we're obviously not meant to have that data any more. (Cue
the story I heard whilst doing Legato Networker training: a site with
several copies of key data. Key data goes poof. First copy on tape is
bad. Second copy on tape is bad. They send for the offsite copy.
Courier manages to have an accident, and the tapes are ruined...)
(The scary thing is, there were a couple of people advocating no copy
pools for some of the clients. Thank God _that_ got shot down in short
order.)
[verbose description of the basic plan snipped in favour of Steven's
summary]
Something like this?
1/ Client A -> TSM B (primary) -> TSM A (copy) (all)
-> TSM C (copy/export)
(critical
only)
A healthy paranoia. :)
That's pretty much it. A more accurate picture would be:
Client A -> TSM B (primary/copy) (all) -> TSM C (copy/export) (critical)
Client B -> TSM A (primary/copy) (all) -> TSM C (copy/export) (critical)
And remember: just because I'm paranoid, it doesn't mean they're _not_
out to get me... ;)
[copying data from the original backup server to the remote site]
The two solutions I've come up with involve data export, and copy
pools
(via virtual volumes). The problem is, both of those operate at the
storage pool level; there's no way to specify "copy/export only the
data for _this_ client, and no others" that I can see.
Actually, you can "export node" for individual hosts, but I'm not sure
if it's
the best way to do what you're planning. However, "export node" can
specify a
client, time range, backup and/or archive data, active files only, and
export/import directly via a server to server connection.
Hm. Going to have to re-read the manual on that; I must have missed
that point. *flick flick flick* ... ok, I missed that point. Excuse me
whilst I carefully extract my foot from my mouth. :)
It's preferable
that we not have to create separate storage pools (all the way down to
the tape level) for these systems just so we can do this -- we'd
prefer
to have one disk pool and one tape pool for the whole shebang if
possible.
I'd normally recommed that you DO create multiple storage pools, so
that you
can better control the physical location of the backup data. This can
improve
recovery performance by separating "critical" clients to their own
storage
pools and tapes. With only one huge disk/tape storage pool hierarchy
each
client's data will tend to "fragment" across a large number of tapes
(unless
you use collocation, which may greatly reduce tape efficiency instead).
Interesting point. Everybody here is an utter newbie when it comes to
TSM; we've done the initial training course (you should remember; IIRC,
you were the one taking the course I was on :) which is all fine and
dandy, but it doesn't really expose you to the little tricks of the
trade which come up when you're actually _using_ the product. :) (And
besides -- after too many months of not using the product because of
wrangling that's out of the hands of the techies, you tend to forget
the finer points that were covered on the course.) Still, I have a fair
amount of faith that TSM will do the job we need; it's more or less a
matter of what problems we run into along the way (and don't tell me we
won't run into problems -- we will; it's just a question of how severe
they are and how difficult to fix. With luck, they'll be less than what
we have with our current backup system.) We've already ruled out
collocation for the most part; I seem to recall an upcoming version of
TSM has a weaker form of collocation (along the lines of "group clients
A, B, and C on the same tapes; D, E, and F on another set of tapes;
etc.") which would be a bit more useful.
If you do create seperate storage pools, then it's simply a matter of
running
an additional "backup stgpool" command to produce the extra off-site
copy for
site "C". This has another advantage in that it's a completely
incremental
process, and you can probably afford to run it every day (for the
critical
nodes/storage pools only).
*nodnod* I was thinking more in terms of trying not to waste too much
disk/tape space (in the sense of "how much do we need to allocate to
the critical systems, and how much to the non-critical servers?"),
rather than recovery speed and so forth. Of course, I haven't got the
information on how much disk pool we'll be allocating, so that aspect
may be completely irrelevant ... it's always fun trying to predict how
things will hang together once they're up and running.
Backup sets may be doable, but I'm a little uncertain about
how they'd go with virtual volumes, and also whether they'd cover
archive data sets.
Backup sets only encompass filesystem backup data. They cannot be used
for
filesystem archives, nor for application TDP backups (even if the TDP
backups
are really "backup" objects).
That's what I suspected, and given that there are several databases
involved in this whole thing, it makes them kinda useless for our needs
in this regard. Scratch that option, then.
So the question is: is there any way we can say to TSM "Copy this
client's data (backup and archive) to that server over there, ignoring
all other client data in that storage pool"? Or am I smoking crack
(again)?
Probably the easiest way is to use a separate storage pool(s) for the
critical
clients. As I mentioned above, this may also help in controlling tape
"fragmentation" and improve recovery performance.
Looks like that's pretty much the consensus, then. All useful
information, and it's very much appreciated.
Oh, and as for the suggestion of shipping tapes -- one of the reasons
we want to do it this way is to minimise the amount of media we need to
ship from point A to point C (almost wrote point B there :) -- we have
a permanent link to the third site, and the cost of using it for this
purpose is negligible, even if it is relatively slow (well, compared to
gigabit fibre... :)
Many, many thanks for the responses; they've been very enlightening.
Cheers,
Stuart "now to hammer the next piton into the learning cliff..." Lamble.
|
