ADSM-L

Re: Export feasibility

2005-03-10 18:04:37
Subject: Re: Export feasibility
From: Stuart Lamble <adsm AT CAROUSEL.ITS.MONASH.EDU DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 11 Mar 2005 10:04:10 +1100
On 11/03/2005, at 6:25 AM, Ragnar Sundblad wrote:
--On den 10 mars 2005 16:18 +1100 Stuart Lamble
<adsm AT CAROUSEL.ITS.MONASH.EDU DOT AU> wrote:

On 10/03/2005, at 8:15 AM, Ragnar Sundblad wrote:
[snipping]
I think that the most logical way to accomplish this with TSM
is to do a complete export like
export server filedata=allactive ...

What's wrong with using backup sets? The end result is the same -- all
currently active data is stored on tape and can be moved offsite,
without needing any maintenance from the main TSM server.

Backup sets may be fine too. There are two issues with it that
made me think that they were not as suitable for this as an export:
- There seem to be no way to generate a backup set that contains
multiple nodes, so I take it that if I don't want one tape
per node (hundreds), I will have to generate the backup sets to
disk and find some other way to pack them on tapes.
Am I wrong here?

Not as far as I can tell, alas. The other is probably not as important
-- I agree that symmetry is nice to have, but for DR purposes, you can
probably live without it.

[more snipping]

I was just thinking that there might be some other resource
that that server could get short of, like database rollback or
something, if it was both doing an export for days and at the
same time was backing up. I hope that is not a problem, and
especially it shouldn't be if I use backup sets instead.

On that, I'll have to defer to the more knowledgeable crowd on the
mailing list; I honestly don't know. One option you do have is to
export in batches -- say, a quarter of the nodes in one batch; another
quarter in the next batch; and so on, giving the server time to do any
maintenance it needs but can't perform whilst an export is occurring.
I'd be surprised, though, if there was any of significance. Not saying
there won't be any, just that it would surprise me.

If backup sets (see the
"generate backupset" command in the admin reference manual) fill your
needs, my advice would be to make use of them, rather than using the
rather fragile option of server data exports.

I very much agree, simple is good! :-)

It is interresting, but sad, to hear that you too find exports
fragile. May I ask what the problems typically are?

I've found, for example, that if the server is unable to read the data
it wants off the primary tape, it doesn't appear to revert to the
backup copy to complete the export; rather, the export fails. I haven't
chased this up, as I had far too many other (rather urgent) matters on
my hands when it occurred, so there may be other factors at play -- but
that's one example.

There are a couple of other things that may or may not be of concern;
again, I haven't spent as much time as I should verifying all the ins
and outs, so without knowing, I'd prefer to keep my mouth shut on them
lest I be seen as a fool. :-)

If I can do what I want with backup sets instead, that is
probably a better way.

One suggestion I do have would be to test. If you can afford to have
the backup system in a potentially not-working state for a period of
time, run some tests and see what happens. Try to make it break as much
as you can; take tapes out of the silo (telling TSM about it, of
course) to see how it copes; things like that. You'll end up being much
more secure in what you're doing if you know how it can break, and how
to recover if it does break.

All this, of course, is with the understanding that, more likely than
not, you'll not be in a position to do any of this. :-(

Hope this is of help in some small way.

<Prev in Thread] Current Thread [Next in Thread>