==> On Wed, 6 Apr 2005 10:15:40 +0200, Peter Duempert <[EMAIL PROTECTED]> 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
