Question regarding restore of a full (but not "Whole-system") onbar backup
User on IDS 9.30 switched from whole-system ON-Bar backups (onbar -b -L 0 -w) to per-dbspace parallel backups (-f dbspacelist) with ISM, and asked what point in time such a backup can be restored to, since later dbspaces finish after several logical logs have filled. Replies: a non-whole-system backup always needs the logical logs to be made consistent, so you must roll forward at least to the end of the last dbspace backup rather than to the backup's start time; whole-system backups are the ones that can be restored without logs, and they also support point-in-time restore (onbar -r -w -t/-n). IBM's Martin Fuerderer added that -w offers the same functionality, is no longer serial in newer releases, and a PIT can even fall between backup start and end. Advice: if databases are logged and log backups are taken, use normal level 0/1/2 plus log backups with BAR_MAX_BACKUP for parallelism; use -w only if logs aren't backed up. The poster's question was answered, though no final choice is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
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...@googlemail.com> wrote:
> 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!
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
> may have to revert to -w (which disallows point-in-time).
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 backupfinished 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,
> > may have to revert to -w (which disallows point-in-time).
>
onbar -b -w -L 0 does allow for a point in time restoreeither 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...@googlemail.com> wrote:
> Woops - I said
>
> > may have to revert to -w (which disallows point-in-time).
>
> 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...
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@iiug.org wrote on 11/09/2010 02:26:43 PM:
>
> Woops - I said
> > may have to revert to -w (which disallows point-in-time).
>
> 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...
> _______________________________________________> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
On Nov 9, 1:17 pm, Malc <mal...@googlemail.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).
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...@de.ibm.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-boun...@iiug.org wrote on 11/09/2010 02:26:43 PM:
>
>
>
> > Woops - I said
> > > may have to revert to -w (which disallows point-in-time).
>
> > 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...
> > _______________________________________________> > Informix-list mailing list
> > Informix-l...@iiug.org
> >http://www.iiug.org/mailman/listinfo/informix-list