ADSM-L

Re: Selectively duplicating client data across servers

2004-08-25 21:34:15
Subject: Re: Selectively duplicating client data across servers
From: Steve Harris <Steve_Harris AT HEALTH.QLD.GOV DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 26 Aug 2004 11:34:24 +1000
Hi Stuart.

Sorry.  If backupset to virtual volumes won't fit, then you'll have to split 
your backups into two storagepool hierarchies.

but, since this is a belt-and-braces-both-fail scenario, and is thus unlikely 
to be used, is it possible to make the backup by shipping tapes?

Create a third copy using copy stg and ship it, with a database snapshot 
offsite.  Either restore the DB to a recovery TSM server as a matter of course, 
or only do it when necessary.

When its time for a refresh, either delete every volume in the stgpool and 
recreate it, or just run another backup stg and send the new tapes and DB 
snapshot offsite. DRM will handle the tape movements.

Regards

Steve Harris
AIX and TSM Admin

Queensland Health, Brisbane Australia
 

>>> adsm AT CAROUSEL.ITS.MONASH.EDU DOT AU 26/08/2004 9:19:16 >>>
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.

The project I'm working on involves a third site; call it site C. The
connectivity from sites A and B to site C is significantly poorer than
that between A and B, largely because site C is significantly remote to
A and B (whilst A and B are within a few km of each other), precluding
running of fibre to it. (Not sure what the current connections are;
that's not my area.) The idea is that if things go boom in a major way,
and we lose everything at _both_ site A and site B, we want to have
copies of the university's critical data (student records, SAP, that
sort of thing) available for restore. Maybe the data will be a little
old, but better than nothing.

So the idea is this. The servers holding the critical data backup to
their backup server as normal. Once every so often (once a week, once a
fortnight, once a month...), we want to take the data off the _backup
server_, and copy it to another TSM server at site C. We want to do
this only for those critical servers, not for all servers. The data may
be in the form of either archives or filesystem backups, or some
combination of the two. We _don't_ want to be running extra backups for
the servers in question to provide this redundancy.

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. 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. 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.

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)?

Any pointers or suggestions on where to look would be very gratefully
received. For me, this isn't so much a learning curve as a learning
cliff. :) If it's relevant, the clients in question are mostly Solaris,
and we'll be running Tivoli Storage Manager 5.2 on Solaris servers.

Many, many thanks for any tips. I'm coming from a background with
Legato Networker, and I'm still trying to get my head around some of
the more interesting aspects of TSM, learning as I go. :)

Cheers,

Stuart.


***********************************************************************************
This email, including any attachments sent with it, is confidential and for the 
sole use of the intended recipient(s).  This confidentiality is not waived or 
lost, if you receive it and you are not the intended recipient(s), or if it is 
transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this 
email is prohibited.  It may be subject to a statutory duty of confidentiality 
if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in 
error, you are asked to immediately notify the sender by telephone or by return 
email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************