Here's the situation: We are a managed hosting company that uses TSM
for backup, and we would like to hand off day to day administration of
the environement to the operations staff. There are a number of
inexperienced (in TSM) staff. We want a way to audit (beyond the normal
activity log) what
Is there any way to quantify the amount of space that will be reclaimed
via changing a retention policy and letting expiration run until it's
done? For example, the current policy is 180 day/8 versions. If I
change that to 30 days/3 versions, how much space would I gain? I'm
sure it's quite subst
I have several events listed as being "In Progress", with no associated
session. A restart of both the TSM application and the entire server
has been unsuccessful at resolving the issue, so I think that the issue
is database related, but can't be sure. Is there something that I can
do to fix this
Install the client with --nodeps. Then do an ldd
/opt/tivoli/tsm/client/ba/bin/dsmc. Then make a symlink in /usr/lib for
the version of libstdc++ that you have to the version that it claims is
missing.
I don't have a Fedora box hanging around, so I can't be more specific
than that, but that proc
Don't know anything about Quick I/O, but we have several Solaris TSM
servers that used to use filesystem volumes (on a VxFS filesystem) for
database, disk pool, and recovery log. Upon implementing the
recommendation to switch to raw volumes (we did volumes under VxVM
control, but with no filesyste
I just inheritied a TSM server that is running on AIX that I need to
migrate to Solaris. The system is using an ACSLS controlled library,
has about a 65GB database, and 11GB recovery log. I've read many times
on this list that a database backup is not a migration tool - more of a
disaster recover
