==> On Wed, 6 Apr 2005 10:15:40 +0200, Peter Duempert <p.duempert AT tu-bs DOT
de> said:
> Just a few questions:
> 1. is anyone out there using/providing this feature ?
Yep. :)
> 2. If so, how does it interfere with normal TSM-usage (server side) ?
Hm. Really, it doesn't.
> 3. Is it supported by TSM 5.3+ ?
No specific experience, no reason why not.
> 4. How about the size of the "bexpi.dsm" file and for the "BACKUPPOOL"
> storage-pool ?
I think the bexpi.dsm file was a script that you can run on your TSM server
which will be perfectlt reasonable if that TSM server is entirely owned by BE
activity. I took the script apart, figured out what it was trying to do, and
separated its bits out.
The backuppool size is more or less what you'd expect: calculate your
full/differential/whatever displacement, and that data will be stored in your
TSM server.
> 5. The VERITAS-doc (Chapter 18, page 789) tells about
> "... to retain position information about each backup set
> that it sends to the TSM server's BACKUPPOOL storage pool".
> Is this "backup set" a usual TSM-backupset or anything else ?
No. BE doesn't have a database like TSM does; the "Position Information"
stream seems to be a vague analog of it. The PI is necessary so that BE can
figure out which "Tape" (which TSM sees as a file) to call for.
Keep the PI on disk, it'll dramatically improve the BE agent's performance.
It's really really tiny. For an example, I've got an exchange server which has
been backing up thru BE to my TSM server for a few months now. The PI
occupancy is 33 files, .21 MB. I set aside a "small" stgpool for it, 18GB,
and I feel silly now. :)
I think it probably comes down to backup session labels, more than anything
else.
> 6. They talk of a "virtual single tape drive robotic library" (page 788).
> Does this imply that only 1 real drive can be used for
> migration/restore ?
For restore, probably: I'd guess that the BE session won't open more than one
stream. (note, that's per-client. If you've got, say, 4 exchange servers
using this, you'd get 4 sessions) For anything else, it's not a problem
because it's all inside the TSM server.
> Any further recommendations/comments "to promote / not to promote" this
> option would be very appreciated.
My main comment would be "Don't struggle too hard if folks want it".
We have several customer-type folks who have been interested in BE's
"Brick-level backup" for a long time. For some of them, its' availability was
the remaining obstacle to TSM adoption. It was pleasant to offer it to
them. :)
I certainly prefer to educate and convert, rather than to maintain BE clients,
but if your staff is accustomed to the full/differential scheme, it can be
culture shock to go to incrementals-forever. If you can offer the BE to TSM
link, then you can at least still leverage TSM infrastructure, and that can be
a neat way of measuring, explicitly, how much space your BE clients are
wasting. :)
On the other hand, the BE - TSM connection is EXPENSIVE.
- Allen S. Rout
|
