[snipping]--On den 10 mars 2005 16:18 +1100 Stuart Lamble <[EMAIL PROTECTED]> wrote:
On 10/03/2005, at 8:15 AM, Ragnar Sundblad wrote:
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.
