1. is anyone out there using/providing this feature ?
>> Did so a long time ago with some EXCHANGE backups, not recently.
2. If so, how does it interfere with normal TSM-usage (server side) ?
>> What it does is let the Veritas client end continue to work as it usually
>> does, and just use TSM as its backstore, instead of giving Veritas its own
>> tape drives.
To TSM, Veritas looks a lot like one of TSM's TDP clients. Just like adding
any other TSM client - the effect on the TSM server depends on the amount of
data you are sending. To Veritas, TSM looks like a strange tape driver.
3. Is it supported by TSM 5.3+ ?
>> I don't' think any TSM version has any formal support for it; I think
>> Veritas calls the TSM API.
You would need to ask Veritas if THEY support it on TSM 5.3.
FWIW, since VERITAS calls the API, you will not get the same statistics on the
TSM server end about filespaces and backup contents as you do for regular TSM
clients. It's pretty much up to the API caller what it reports back to the TSM
server. That is not a failing with VERTAS, necessarily; it has been true to
varying degrees with different versions of the TSM TDP clients, as well.
4. How about the size of the "bexpi.dsm" file and for the "BACKUPPOOL"
storage-pool ?
>> As I recall the, bexpi.dsm file is very small; I believe VERITAS just stores
>> some control info there.
As for the BACKUPPOOL, it think it's just the same logic as you use when
setting up one of the TSM TDP clients; you figure out how much data you are
sending, and if it's a lot, you may want to put it in a pool by itself.
Perhaps not. Strictly a matter of the size of what you re backing up.
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, it's not a TSM "backupset". I think that's just a VERITAS term meaning
>> "chunk of backup data".
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 ?
>> I don't know about restores. I don't have a copy of the manual, and I never
>> had to address the issue.
But I don't think VERITAS has any control over migration. VERITAS calls the
TSM API, and sends a chunk of data to the TSM server.
It lands in a TSM storage pool. After that, MIGRATION is controlled by TSM
rules. VERITAS won't know or care if it migrates. So you should be able to
migrate with multiple drives, same as any other TSM storage pool.
Any further recommendations/comments "to promote / not to promote" this option
would be very appreciated.
>> Depends on your situation.
Does VERITAS still support it? If so, no technical reason to rule it out.
If you have a group/customer that already has a large investment in BackupExec
licenses, and/or your DBA's have a lot of BE knowledge in managing large data
bases, then it's a good way to leverage your $ and skills, while consolidating
hardware.
If you haven't bought VERITAS licenses yet, and you are considering only one or
two new clients as a new project, the question is WHY? Using BE for your
backups gives you MULTIPLE vendors involved with debugging a problem, which is
a bad thing. And debugging any of the API-based clients is harder than
debugging one with fewer parts.
SO you should have a GOOD REASON for requiring more work and more $ to go with
the additional vendor. But those are management issues, not technical ones.
Hope that helps..
Wanda Prather
"I/O, I/O, It's all about I/O" -(me)
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Peter
Duempert
Sent: Wednesday, April 06, 2005 4:16 AM
To: ADSM-L@VM.MARIST.EDU
Subject: VERITAS TSM-Option
Hi *SM-ers,
it's the first time for us, that we have a request to consider to
provide the TSM-service for the VERITAS
BACKUP EXEC TSM OPTION,
i.e. "Backup Exec as a TSM Client"
Just a few questions:
1. is anyone out there using/providing this feature ?
2. If so, how does it interfere with normal TSM-usage (server side) ?
3. Is it supported by TSM 5.3+ ?
4. How about the size of the "bexpi.dsm" file and for the "BACKUPPOOL"
storage-pool ?
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 ?
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 ?
Any further recommendations/comments "to promote / not to promote" this
option would be very appreciated.
Peter
--
MfG / Ciao - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Peter Dümpert Email: [EMAIL PROTECTED]
Rechenzentrum der Technischen Universität Fax : ++49/531/391-5549
D 38092 Braunschweig Tel : ++49/531/391-5535
