IDS9.30HC5, HP-UX 11i
We've moved to backing up our databases using "onbar -b -L 0 -f
<dbspacelist_file>" using ISM, whereas before we used "onbar -b -L 0 -
w".
We used to do a regular simple imported physical restore of the -w
backups to our test server and obviously only needed the dbspaces and
the logical log that was current at the start of the backup.

Doing the new backup using a dbspace list file, I'm a little uncertain
of the entire chain of events with regard to restoring; we'll
obviously need the dbspaces and logical logs but I'm trying to work
out exactly what will happen.
It may be the case that several logical logs fill during the database
backup process (we stop all processing at the start of the backup and
allow it to restart once the backup is confirmed as running). This
means that some later dbspaces are being backed-up when a couple of
logical logs have been filled since rootdbs was backed up. ixbar shows
us the log required to restore each particular dbspace (which may be a
couple of logs later than the one active when rootdbs was backed up)
but I'm wondering which point-in-time I can use for the restore - we'd
rather the restore restored the database to the point-in-time that the
backup was started; is this possible? It looks to me like the later
dbspaces can't be restored to that time, and we can't hold off system
processing for the whole duration of the backup...

I supoose I should have paid more attention in the onbar training
course!

--> We've moved to backing up our databases using "onbar -b -L 0 -f
--> <dbspacelist_file>" using ISM, whereas before we used "onbar -b -L
0 -
--> w".

Why??? a onbar -b -L 0 -w is really save and does not require trx
logs.
or is it getting really big so you need paralel??

REMARK ism support only 4 streams paralel.
One of them i would dedicate to trx logs.

HMM make real sure that <dbspacelist_file > contains all dbspaces.
HMM sounds obvious but... make sure your databases are logged!!!

--> but I'm wondering which point-in-time I can use for the restore -
we'd
--> rather the restore restored the database to the point-in-time that
the
--> backup was started; is this possible? It looks to me like the
later

This can be done using a previous backup and the log.logs to
rollforward to the
start of your new backup....

for the current backup if you start rootdbs and log/plog at say
9:00
then start dbs1,2,3 at 10:00
and start dbs4 at 11:00
you need to restore root/llog/plog/ dbs1,2,3,4 and rollforward until
at least
11:00.
The reason is that collecting before images of a dbspace is done as
soon as
a backup of a dbspace is started.
With the -w all is backupped and from the beginning the before images
are collected
and stored in temp. When done it is copyd to archive in order to get a
backup
the moment it started.

even with another storage manager then ism :with your version a
paralel backup requires transaction logs
to make it all consistent even if BAR_MAX_BACKUP is set unlimited.
(dono about later versions i recall reading somewhere that you can
nowadays
create a parallel backup without trx logs??)


SOO that means you can not restore to the exact point in time the
backup started.

Superboer.

On 9 nov, 13:04, Malc <mal... (AT) googlemail (DOT) com> wrote:

SB, thanks. All databases are log mode U or B.
Looking back at my OnBar course notes, they go on at length about
backup consistency being guaranteed such that a backup "Contains all
pages required to restore the system to [the time the backup was
started]". Note it says "the system" and "the time the backup was
started". No mention of dbspaces that may occur later in the process,
or whether this is only valid for a type -w backup. It also says "A
level 0 backup contains a copy of all data in the server system as of
the time the backup was started"; this seems to conflict with your
analysis but I'd tend to go with an experienced user's POV, I think...
Decided to go to "-f" to take advantage of point-in-time as a banker
option (in case of anyone stuffing up critical data) but looks like we
may have to revert to -w (which disallows point-in-time).

Woops - I said
Yes you can. onbar -r -w -t or onbar -r -w -n.

OK; so if logical logs 1000 to 1005 were filled after the backup
completed, I can do
onbar -r -w -n 1003 and it'll restore to that log; or if the backup
finished at 13:00 I can do
onbar -r -w -t "2010-11-09 14:00" if I have the logical logs from that
time.
More reading required...

Hello Malc,

onbar -b -w -L 0 does allow for a point in time restore
either the moment the backup was taken or if you want to have a later
point in time.
no worries.(do test though!! )

So that should not be a reason to goto a paralel backup.

Superboer.


On 9 nov, 14:26, Malc <mal... (AT) googlemail (DOT) com> wrote:

Hi,

an ON-Bar whole system backup (done with the "-w" command line parameter)
should offer all functionality just like an ON-Bar backup without "-w".
(In older versions of Informix whole system backups used to be serial,
whereas
only non-whole system backups were parallel ... but this restriction has
been
lifted in a past release.)

The real difference is that a whole system backup *can* be restored
without
restoring logical log files. Whereas a non-whole system backup always
needs logical log files for a complete restore. Therefore a whole system
backup can also be used for long term archiving (e.g. for legal reasons)
- without needing to worry that the corresponding logical log file backups
do not get deleted.

If I remember correctly, then a point in time (PIT) for a restore can be
even in the intervall between backup start and backup end (not only after
the backup end). Logical log records should be rolled back correctly
(or before images will be applied) to get to the correct and consistent
state.
Thus with ON-Bar backups and logical log backups done regularly, basically
any PIT can be given for a restore - ON-Bar will find the corresponding
backup needed (given that it still exists) and the needed logical log file
backups and restore them accordingly.

[ For reasons of common sense restore PITs that would be before the
first available backup or too far in the future are ... not really
supported. ]

Regards, Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

IBM Deutschland Research & Development GmbH
Chairman of the Supervisory Board: Martin Jetter
Board of Management: Dirk Wittkopp
Corporate Seat: Boeblingen, Germany
Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294

informix-list-bounces (AT) iiug (DOT) org wrote on 11/09/2010 02:26:43 PM:

On Nov 9, 1:17*pm, Malc <mal... (AT) googlemail (DOT) com> wrote:
If all databases are logged AND you are taking log backups (onbar -b -
l as should should be i.e. LTAPEDEV is NOT set to /dev/null)

Then you should do normal archvie (level 0/1/2) and log archives.and
use parallel backups with onconfig parameter BAR_MAX_BACKUP
controlling parallelism from the database server side.

You can then restore to current time (onbar -r) or a given point in
time (onbar -r -t time).

If however your database are unlogged or you do not take log backups
then you will need to run level 0/1/2 with -w (whole system) option
and log backups will not be required for restores
(as you do not have any!). Ignoring version 11.10 then prior to
version 11.50 your backups with -w option will be single threaded and
NOT be parallel.

Assuming you backup logs then what is stoppiing you from allowing
processing whilst the backup runs?

-->>(In older versions of Informix whole system backups used to be
serial,
-->>whereas
-->>only non-whole system backups were parallel ... but this
restriction has
-->>been lifted in a past release.)

Thanks Martin!! that was what i read.; will try not to forget it.

Superboer.

On 9 nov, 16:20, Martin Fuerderer <MARTI... (AT) de (DOT) ibm.com> wrote:

On Nov 9, 8:59*pm, "da... (AT) smooth1 (DOT) co.uk" <da... (AT) smooth1 (DOT) co.uk> wrote:

Thanks, David.
All databases are log mode B or U; we stop processing for a few
minutes either side of the backup start point but once we've confirmed
it's started, processing begins again.
What I was concerned with is whether a -f <spacelist> backup is
consistent to the start time of the entire backup, i.e. the point
where onbar -b -L 0 -f <list> was issued.
Using the -f method, backups (to disk) take 4 hours, using -w it takes
6 hours. We'd rather take the shorter option
But SB above said that using -f, we can't restore to the time we
issued onbar -b -L 0 if logs are being filled and some dbspaces start
backing up later than rootdbs; whereas the training notes and the BAR
manual imply differently, as I wrote earlier.

e.g.
Time zero: issue onbar -b -L 0 -f <dbspacelist> (where <spacelist> is
created by the initiating process as an SQL on sysmaster and lists all
the dbspaces)
T0+1: rootdbs backs up, processing is allowed to restart
T0+2: space1 backs up
T0+3: log log fills and gets backed up by ALARMPROGRAM
T0+4: space 2 backs up
T0+4 to T0+5: several more log logs fill up and get backed up by
ALARMPROGRAM
T0+6: space 3 backs up
T0+7: onbar ends

We only ever would do a COLD restore.
Can we restore the database, using the data written by the above
processes, to Time zero?
I know we can, using -w. I'm asking if the -f version allows the same,
or can we only restore to the point where space 3 was backed up?
Simple as that.
Remember our versions - IDS9.30HC5 on HP-UX11.11. Not negotiable.

Hello Malc,

--> I know we can, using -w. I'm asking if the -f version allows the
same,
--> or can we only restore to the point where space 3 was backed up?
--> Simple as that.

No you can not. The onbar -b -w -L 0 does backup the content of your
logical logs too simular as an
ontape would do. So the restore can do a fast recovery after a
physical restore.

onbar -b -L 0 does not backup the content of your logs;
(believe me i have been there you need your trx log to restore which
means that you can not restore
to the point in time the archive starts. this you can only do with an
archive taken before and using trx logs.)
Besides that collecting before images of a dbspace starts when the
backup for that dbspace starts.

There is a FEA out there to allow this; however this got implemented
in
onbar -b -w -L 0 as Martin said to be in paralel which is more then
acceptable.


Superboer.

You could try and tune a bit in upping BAR_NB_XPORT_COUNT
make sure BAR_XFER_BUF_SIZE is 31 make a not if you change
BAR_XFER_BUF_SIZE because you may not be able to restore an older
archive taken with a different BAR_XFER_BUF_SIZE size.