Fred,
Look what I've got from Backup and Restore Guide for Informix Dynamic
Server 9.2x :
What Is a Whole System Backup?
A whole-system backup is a serial backup of all storage spaces and logical
logs based on a single checkpoint. (During a checkpoint, the database
server synchronizes the pages on disks with the pages in the shared-memory
buffer pool.) The advantage of using a whole-system backup is that you can
restore the storage spaces with or without the logical logs. Because the
data in all storage spaces is consistent in a whole-system backup, you do
not need to restore the logical logs to make the data consistent.
Similar can be found in the B&R Gd for IDS 7.3x.
I've made in a test environment whole-system backup with "onbar -b -w".
After this I was able to do restore to selected dbspaces using either
"onbar -r rootdbs mydbs" or "onbar -r -n <llog num> -p rootdbs mydbs".
So if you made whole system backup (-w option) partial restore can be up to
the Logical Log for the backup (onbar makes a checkpoint and next llog file
becomes current).
If you are creating your backups without -w option (onbar -b [-f
<dbspaces_list_file> | <dbspaces_list> ] ) you will have to make point in
time restore using "onbar -r -t <point in time datetime> rootdbs
<target_dbs> [<target_dbs2>]".
This way you should be able to restore the dbspace(s) which contain the
requested database on another server. You wrote it is one from sixty
databases. So even if it is 3-5 times the average size you will need server
with less than 10% of big box storage.
To find the needed dbspaces use "onarchive list /database=<your_db>".
Zlatko Krastev
IT Consultant
"Prose, Fred" <FProse AT SUPREME.SP.STATE.AZ DOT US> on 21.09.2001 23:52:37
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Expiration "challenge"
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
expire?
If I set up a new management class for this one server, can I force
existing
files from this server into this class?
|
