RE: Informix/TSM Point In Time Restore
Martin,
I think you missed one crucial piece of information from the original
question.
> > In order to implement a point in time recovery, we made the choice
> > to
only
> > backup criticals dbspaces and the intraday's one:
If you haven't backed up all dbspaces you can never achieve point-in-time
restore.
Regards
Malcolm
-----Original Message-----
From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On
Behalf Of Martin Fuerderer
Sent: 16 September 2005 16:46
To: owner-informix-list@iiug.org
Cc: informix-list@iiug.org
Subject: Re: Informix/TSM Point In Time Restore
Hi,
I first didn't about this this due to time issues.
But since Tech Support discussed this with me, I've
done that thinking now and here are our conlcusions
(though not all of this has not been verified by testing):
- you can't do a warm PIT (Point In Time) restore of a
dbspace, because obviously this would leave that
dbspace inconsistent with the rest of the instance
(i.e. the other dbspaces).
- when doing a cold restore with PIT, then you have to
restore all dbspaces. This is because otherwise you
will never get the dbspaces consistent.
- what (I think) you can do is to first do physical PIT restore
of all critical dbspaces and optionally some other
dbspaces, then do physical (PIT) restore of the remaining
dbspaces, then do logical restore (to that PIT).
That way it will be ensured that all dbspaces are consistent
to the same PIT. (Maybe you need to specify the PIT only
for the first onbar command.)
- doing physical PIT restore of some dbspaces, followed by
logical restore, then doing PIT restore of remaining dbspaces
will not work, as it will leave the remaining dbspaces out of
sync (there may have been things happening to the already
restored dbspaces in the meantime).
- in theory it would be possible to PIT restore only selected
dbspaces (critical dbspaces always included), and then
never restore the remaining dbspaces.
However, as far as I know, this is not implemented, i.e.
ON-Bar will not let you do this.
Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management
owner-informix-list@iiug.org wrote on 15.09.2005 20:32:10:
> ptitchuisse wrote:
> > Hello,
> > I am using Informix IDS 9.4 and TDP as a backup solution (on an AIX
5.1
> > server).
> >
> > Our database contains:
> > - rootdbs
> > - ste_tmp as a temporary dbspace
> > - ste_dbs as an intraday application dbspace
> > - ste_e01_dbs as an archive application dbspace
> > - ste_r01_dbs as an archive application dbspace
> > .
> > .
> > .
> > - ste_e07_dbs as an archive application dbspace
> > - ste_r07_dbs as an archive application dbspace
> >
> > Then, we have have 20 tables which are fragmented on the ste_dbs and
> > ste_e*, ste_r* depend on a dbspace_id field in each table. 0 for
ste_dbs,
> > 1 for ste_e01_dbs, ste_r01_dbs.
> >
> > During the intraday traffic, messages are created in these table
> > with
the
> > dbspace_id field to 0.
> > During the night, we have a process with set this field to [1-7],
depend
> > of the current dbspace to use.
> > It allows to move automatically messages fron the intraday ste_dbs to
an
> > archive dbspace.
> >
> > In order to implement a point in time recovery, we made the choice
> > to
only
> > backup criticals dbspaces and the intraday's one:
> > each archive dbspace are 36Gb chunk and in the case of a crash, it
will
> > take ages to restore.
> >
> > Then, we have defined a "onbar -b rootdbs ste_dbs" in the crontab to
run
> > it each night after our "archiving process"
> >
> > As described in the "IBM Informix Backup and Restore Guide pg 6-6
> > and 6-21" if you use the onbar -r -t time command, you must restore
> > all storage spaces to specific time in a cold restore.
> >
> > I try to :
> > - oninit -i to reinitialise the instance
> > - onmode -BC 1 to activate huge chunk
> > - onspaces to recreate only the ste_dbs
> > - onbar -r -p -t "time1" rootdbs ste_dbs to do a physical point in
time
> > restore of only the critical and the intraday dbspaces
> > - onbar -r -l -t "time1" to replay the logs
> >
> > and it failed with :
> > Unable to start the logical log restore: A Point-In-Time Logical
Restore
> > is only permitted during a Full Restore.
> > DBSpace 'ste_e01_dbs' was not recovered during this restore..
> >
> > Using the onstat -d command, I was surprised to see my 14 archive
dbspaces
> > automatically recreated !!!
> >
> > Is somebody already met this issue and was in the same startegy ?
> >
> > Any help would be much appreciated
> >
> > Regards
> > David
> >
> >
> >
> >
> >
> >
> >
>
> What are you trying to do??
>
> You have an instance.
>
> That instance has :
>
> rootdbs
> datadbs1
> datadbs2_archive
> datadbs3_archive
>
> What do you want to be able to restore to "a point in time?"
>
> > As described in the "IBM Informix Backup and Restore Guide pg 6-6
> > and 6-21" if you use the onbar -r -t time command, you must restore
> > all storage spaces to specific time in a cold restore.
> >
>
> So, are you saying that you are quite happy to "lose" the archive
> dbspaces in case of a failure?
>
> Well, let's say on Monday you backup :
>
> rootdbs
> datadbs1
>
> on Tuesday you backup :
>
> rootdbs
> datadbs1
>
> On Wednesday, you want to restore rootdbs and datadbs1 to 2005-09-14
> 00:00:00 :
>
> With the engine offline, issue
>
> onbar -r -p -t "2005-09-14 00:00:00" rootdbs datadbs1>
> Which will do a physical restore of the rootdbs and the datadbs.
>
> The instance is now expecting you to warm restore the remaining
> dbspaces (datadbs2_archive and datadbs3_archive), but you can roll
> forward rootdbs and datadbs1
>
> onbar -r -l -t "2005-09-14 00:00:00">
> BUT the instance still knows about all the other dbspaces that ... you
> want to "trash" or "lose".
>
> Why not look at it like this :
>
> Sunday - backup everything :
>
> onbar -b>
> Monday - backup rootdbs and datadbs1
> onbar -b rootdbs datadbs1> Tuesday - backup rootdbs and datadbs1
> onbar -b rootdbs datadbs1> Wednesday - backup rootdbs and datadbs1
> onbar -b rootdbs datadbs1> Thursday - backup rootdbs and datadbs1
> onbar -b rootdbs datadbs1> Friday - backup rootdbs and datadbs1
> onbar -b rootdbs datadbs1>
> (Presumably you are also backing up the logical logs!!!)
>
> Now let's say you want to restore to Thursday, but with the least
> amount of down time :
>
> With the engine offline (no oninit -i needed anywhere!!!) onbar -r -p
> -t "2005-09-14 00:00:00" rootdbs datadbs1 onbar -r -l -t "2005-09-14
> 00:00:00" rootdbs datadbs1
>
> Now the engine will come