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".
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? :(
> 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.
Something like this?
1/ Client A -> TSM B (primary) -> TSM A (copy) (all)
-> TSM C (copy/export) (critical
only)
A healthy paranoia. :)
> 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.
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.
> 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).
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).
> 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).
> 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.
Give me a call if you want to discuss it further.
Regards,
Steven P.
--
Steven Pemberton
Senior Enterprise Management Consultant
IBK, Senetas Group
Mobile: +61/0 418 335 136 | Phone: +61/3 9820 5811 | Fax: +61/3 9820 9907
Level 1, 11 Queens Road, Melbourne, Victoria, 3004, Australia
http://www.senetas.com.au | http://www.ibk.com.au | http://www.datum.com.au
|
