Thank you Stuart for your feedback!

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

We don't want to give up storing away a complete snapshot of
our systems off site every few months, over time maybe reusing
the off site tapes so that we finally save a snapshot a year.

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?
- They can't be imported into the storage pools again. This is
probably not really a problem, it just looks nice and feels
good to be able to move data both ways.

Given LTO 3 with an maximum data speed of 50 MB/s uncompressed,
a moderate guess (I hope) for the data transfer rate would be
30 MB/s, which would give 93 hours to write it down. Given that
a tape has a capacity of 400 GB uncompressed, it would take
at the most 25 tapes.

We would obviously want to be able to use the backup server
as usual while doing the export.

Then you would need to make sure that your server has enough capacity,
in terms of tape drives (and connectivity to the tape drives), network
bandwidth (to cover both the export and the backups), and such like to
cope with both the export (or backup set generation) and regular
backups simultaneously.

Yes, that is quite reasonable. :-)

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.

 From my point of view, being in the middle of fiddling around with
exports (server to server in my case) for various "last ditch" DR
systems, I'd suggest keeping it simple. 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?
If I can do what I want with backup sets instead, that is
probably a better way.

Thank you again for your thoughts!

Best regards,
Ragnar Sundblad