I can think of two options.
1) Save an additional backup of your (ADSM) database, and take
measures to ensure that the tapes upon which your (Informix)
database reside do not get reused.
This will allow you to restore the ADSM database at some stage
in the future, and the tapes that you care about with the
Informix database will still be available from which you can
restore the Informix OLTP data.
2) Restore a copy of the Informix OLTP database to some location,
and then run an *archive* of that data.
Based on your description of the environment, unless you can get
a vendor to loan you equipment for the process, I would think
that of the two options I've proposed, #1 is the better choice.
I'm sure others on the list might approach this question from a
different angle and offer further suggestions.
Thomas A. La Porte
tlaporte AT anim.dreamworks DOT com
On Fri, 21 Sep 2001, Prose, Fred wrote:
>We run Tivoli 4.2 on AIX (4.3.3) with a primary emphasis on backing up
>Informix databases using the Informix TDP. We defined a "database"
>management class for the database backups, with "retain extra versions" set
>to 30 days. All database servers (13) go to this same class. This has
>always proved quite adequate, as the requirement has been to provide
>recovery capabilities, not archive historical copies of the data.
>We now have a Law Enforcement organization interested in some "unusual
>activities" that occurred in one of sixty databases that resides on one of
>the servers. The "request" they placed was to retain the oldest copy that
>we had of this database until they were through with their investigation.
>Restoring the database to a different server is not as simple an option as
>it first might seem. With an Informix database backup, you are backing up
>the entire OLTP environment, not just a single database. This entire
>environment would need to be restored to a different server and as luck
>would have it, the server in question happens to be the biggest and no other
>server could handle the restore (space wise). Saving the current
>environment, restoring from the backup, extracting the database in question,
>and then restoring the current environment I've estimated to take twelve
>hours. While it might be the only option, it's not a popular one.
>To prevent the expiration I set retention to 365 days on the management
>class. That will hopefully provide the opportunity to sort things out. The
>problem now is that without expiring versions, I'm not recycling tapes (as
>expected) and buying additional tapes during a budget crisis is a difficult
>and long process.
>Here's the questions:
>Since I know what tapes (2) the current backup is located on, is there a way
>to "freeze" those tapes so that the files contained on the tapes do not
>If I set up a new management class for this one server, can I force existing
>files from this server into this class?