ADSM-L

Re: using TSM as a Veritas repository= library filling up at speed of light !???? how does it work ?

2001-12-22 16:46:50
Subject: Re: using TSM as a Veritas repository= library filling up at speed of light !???? how does it work ?
From: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
Date: Sat, 22 Dec 2001 23:47:37 +0200
You are entering into same problem old versions of TDP products have - all
versions are having unique names and do not expire. You will need to write
your own program using the TSM APIs to expire those files. Or dig down the
Veritas manuals can it expire them for you (is it really TSM aware) by a
command or schedule.

Zlatko Krastev
IT Consultant





PAC Brion Arnaud <arnaud.brion AT PANALPINA DOT COM> on 17.12.2001 17:18:19
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        using TSM as a Veritas repository= library filling up at
speed of light !???? how does it work ?

Hi TSM'ers,

We are trying to build a solution where Veritas BackupExec would be
using TSM as a data repository, but are facing something very strange :
although we respected all recommendations while binding applications
together, it seems Veritas backups are filling up our library extremely
fast.
We have a 3575 l18 library on a new test TSM (4.1.0) sytem, only used by
Veritas and an additional NT system with normal TSM BA client, and after
2 days of utilization, already have 6 primary pool tapes filled up with
veritas backups (Veritas only backups 1 small Exchange server !).
Doing a "q con" on the tapes used by veritas shows something like
(snippet of it) :
BACKUPEXEC Bkup LHR2K010 \{A92E0AEF-C7B5-47B1-879E-03D6AB71AD8- F}\
12013
BACKUPEXEC Bkup LHR2K010 \{A92E0AEF-C7B5-47B1-879E-03D6AB71AD8- F}\
12014
BACKUPEXEC Bkup LHR2K010 \{A92E0AEF-C7B5-47B1-879E-03D6AB71AD8- F}\
12015
BACKUPEXEC Bkup LHR2K010 \{A92E0AEF-C7B5-47B1-879E-03D6AB71AD8- F}\
12016
BACKUPEXEC Bkup LHR2K010 \{A92E0AEF-C7B5-47B1-879E-03D6AB71AD8- F}\
12017
BACKUPEXEC Bkup LHR2K010 \{A92E0AEF-C7B5-47B1-879E-03D6AB71AD8- F}\
12018
doing "show version BACKUPEXEC LHR2K010" shows nothing, and although
those tapes are having thousands of files written on them, result of
expiration process shows :
12/16/01 07:01:26 ANR0812I Inventory file expiration process 96
completed: examined 18 objects, deleting 0 backup objects, 0 archive
objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were
encountered.

How is it possible expiration only went thru 18 objects, as we have
thousands of them on tape ? I am missing something ?  Shouldn't we
normally  have as many objects examined, as objects in TSM DB ?
Now something worse, if I do a "select * from backups", I have (snippet
of it) :
NODE NAME: BACKUPEXEC
FILESPACE NAME: LHR2K010
STATE: ACTIVE VERSION
TYPE: FILE HL NAME: \{064A8A12-D91B-4936-BBC8-A0367F94B943}\
LL NAME: 1000
OBJECT ID: 51147
BACKUP DATE: 2001-11-16 01:02:18.000000
DEACTIVATE DATE:
OWNER: LHR2K010
CLASS NAME: MC VT
of course thousands of entries like this one ....
I am really confused, on one hand, lots of tapes filled, and lots of
entries in the "backups" table, and on the other one, expiration that
examines very few records, and a TSM db that is near to be empty ...
Is it due to the fact Veritas uses a specific "backupexec pi" storage
pool for storing positional information, to locate it's data ?
If yes, should I avoid doing offsite copies from this data, because it's
never going to be expired ?
No idea at all, but if anybody has been building such an application,
all comments, explanations and setting descriptions will be REALLY
WELCOME !!!!!!!!!
Thanks in advance .
Arnaud
<Prev in Thread] Current Thread [Next in Thread>
  • Re: using TSM as a Veritas repository= library filling up at speed of light !???? how does it work ?, Zlatko Krastev/ACIT <=