Onbar fails to restore all dbspaces
Posted in 2007
Ulf (IDS 10.00.FC7, HP-UX, Omniback) found that whole-system backups (onbar -b -w) appeared to include both the rootdbs and a smart blobspace, but a physical restore (onbar -r -p -w) restored only the rootdbs, leaving the sbspace inconsistent, with no errors logged. Suggestions to also run onbar -r -l failed because LTAPEDEV was /dev/null. Others confirmed it as a bug in 10.00.xC6/xC7 (xC5 worked), and the restore log only listed rootdbs when LTAPEDEV=/dev/null. Resolution: restore under FC5, or set LTAPEDEV to a real file instead of /dev/null.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Backup & Restore, Storage & Space Management, Logging & Checkpoints, Platform-Specific Issues
We are using version 10.00.FC7 on HP-UX 11.11 with Omniback for
backups.
Backups using onbar -b -w are created for the two dbscapes we have,
the root dbspace
and a smartblobspace. According to the online log and Omniback both
are stored on the backup media. The ixbar tells the same.
We are not using logical logs, they go to /dev/null.
When restoring using onbar -r -p -w the root dbspace is restored as it
is supposed to but the smart blobspace is not. the bar_act.log says
that a complete restore has been made. There are no errors in the
online log or the bar_act.log. Have now tried it 10 times with
different settimg, changes in the ixbar file but it still fails to
restore the smart blob space. This is marked as inconsistent, the
instance is useless.
Any ideas ?
Regards
Ulf
On 16 Nov, 19:57, Ulf <ulf.akerb...@gmail.com> wrote:
> We are using version 10.00.FC7 on HP-UX 11.11 with Omniback for
> backups.
>
> Backups using onbar -b -w are created for the two dbscapes we have,
> the root dbspace
> and a smartblobspace. According to the online log and Omniback both
> are stored on the backup media. The ixbar tells the same.
>
> We are not using logical logs, they go to /dev/null.
>
> When restoring using onbar -r -p -w the root dbspace is restored as it
> is supposed to but the smart blobspace is not. the bar_act.log says
> that a complete restore has been made. There are no errors in the
> online log or the bar_act.log. Have now tried it 10 times with
> different settimg, changes in the ixbar file but it still fails to
> restore the smart blob space. This is marked as inconsistent, the
> instance is useless.
>
> Any ideas ?
>
> Regards
>
> Ulf
You also need to run onbar -r -l.
Even though the database is not logged there are still some logical
logs generated e.g. checkpoint records.
You will find that when running an onbar -b -w after the dbspaces are
backed up the onbar processes kick off an onbar logical log backup.
That log backup is required to bring all dbspaces/blobspaces to the
same point in time.
Try kicking off onbar -r -l and see what happens.
David.
On 17 Nov, 03:42, "da...@smooth1.co.uk" <da...@smooth1.co.uk> wrote:
> On 16 Nov, 19:57, Ulf <ulf.akerb...@gmail.com> wrote:
>
>
>
>
>
> > We are using version 10.00.FC7 on HP-UX 11.11 with Omniback for
> > backups.
>
> > Backups using onbar -b -w are created for the two dbscapes we have,
> > the root dbspace
> > and a smartblobspace. According to the online log and Omniback both
> > are stored on the backup media. The ixbar tells the same.
>
> > We are not using logical logs, they go to /dev/null.
>
> > When restoring using onbar -r -p -w the root dbspace is restored as it
> > is supposed to but the smart blobspace is not. the bar_act.log says
> > that a complete restore has been made. There are no errors in the
> > online log or the bar_act.log. Have now tried it 10 times with
> > different settimg, changes in the ixbar file but it still fails to
> > restore the smart blob space. This is marked as inconsistent, the
> > instance is useless.
>
> > Any ideas ?
>
> > Regards
>
> > Ulf
>
> You also need to run onbar -r -l.
>
> Even though the database is not logged there are still some logical
> logs generated e.g. checkpoint records.
>
> You will find that when running an onbar -b -w after the dbspaces are
> backed up the onbar processes kick off an onbar logical log backup.
>
> That log backup is required to bring all dbspaces/blobspaces to the
> same point in time.
>
> Try kicking off onbar -r -l and see what happens.
>
> David.- Dölj citerad text -
>
> - Visa citerad text -
Tried the onbar -r -l command, but there still is no trace of the
smart blobspace and this is what I get in the bar_act.log.
The smartblobspace is still marked as Inconsistent.
2007-11-17 10:21:23 25637 25635 /opt/informix/10/bin/onbar_d -r -
l
2007-11-17 10:21:23 25637 25635 ERROR: Logical Logs cannot be
restored because
LTAPEDEV value is /dev/
null .Restoring a normal backup (done by onbar -b) is not possible without
restore
of logical logs. Only whole system backups (done with onbar -b -w) can
be
restored without logical logs as whole system physical-only
restore
(using onbar -r -w -p). Then use onmode commands (options -s or -m)
to
bring server up without logical log
restore.
Regards Ulf
This indeed seems to be an issue for 10.00.xC6 and 10.00.xC7. However, 10.00.xC5 and below work as you'd expect. Is there any chance of performing the restore with this version of the engine, just for the purpose of the restore?
On 17 Nov, 12:58, ximrofni <cl...@uk.ibm.com> wrote:
> This indeed seems to be an issue for 10.00.xC6 and 10.00.xC7. However,
> 10.00.xC5 and below work as you'd expect.
>
> Is there any chance of performing the restore with this version of the
> engine, just for the purpose of the restore?
I have tried both FC7 and FC6, no luck. Also tried to do an oninit -i
and the restore , no luck with that either.
Now downloadin FC5 and will give that a try.
Do you if this problem with just the onbar -r -w -p or with other
types of restore as well ?
Ulf
"Ulf" <ulf.akerberg@gmail.com> wrote in message
news:194922cf-667d-4414-b251-a8368e6cd0c4@l1g2000hsa.googlegroups.com...
On 17 Nov, 03:42, "da...@smooth1.co.uk" <da...@smooth1.co.uk> wrote:
> On 16 Nov, 19:57, Ulf <ulf.akerb...@gmail.com> wrote:
>
> You also need to run onbar -r -l.
>
> Even though the database is not logged there are still some logical
> logs generated e.g. checkpoint records.
>
> You will find that when running an onbar -b -w after the dbspaces are
> backed up the onbar processes kick off an onbar logical log backup.
>
> That log backup is required to bring all dbspaces/blobspaces to the
> same point in time.
>
> Try kicking off onbar -r -l and see what happens.
>
> David.- D'lj citerad text -
>
> - Visa citerad text -
The lesson is, IMHO: if you want a backup that you absolutely ,100%,
no-ifs-or-buts HAVE to rely on to be able to restore from, don't use onbar
at all.
Use ontape, or an external backup and restore, instead.
Onbar - or maybe it's is integration with the third-party backup managers,
it doesn't really matter - is.just too flaky.
Just my opinion though ....
On 17 Nov, 14:04, "Neil Truby" <neil.tr...@ardenta.com> wrote:
> "Ulf" <ulf.akerb...@gmail.com> wrote in message
>
> news:194922cf-667d-4414-b251-a8368e6cd0c4@l1g2000hsa.googlegroups.com...
> On 17 Nov, 03:42, "da...@smooth1.co.uk" <da...@smooth1.co.uk> wrote:
>
>
>
>
>
> > On 16 Nov, 19:57, Ulf <ulf.akerb...@gmail.com> wrote:
>
> > You also need to run onbar -r -l.
>
> > Even though the database is not logged there are still some logical
> > logs generated e.g. checkpoint records.
>
> > You will find that when running an onbar -b -w after the dbspaces are
> > backed up the onbar processes kick off an onbar logical log backup.
>
> > That log backup is required to bring all dbspaces/blobspaces to the
> > same point in time.
>
> > Try kicking off onbar -r -l and see what happens.
>
> > David.- Dölj citerad text -
>
> > - Visa citerad text -
>
> The lesson is, IMHO: if you want a backup that you absolutely ,100%,
> no-ifs-or-buts HAVE to rely on to be able to restore from, don't use onbar
> at all.
> Use ontape, or an external backup and restore, instead.
> Onbar - or maybe it's is integration with the third-party backup managers,
> it doesn't really matter - is.just too flaky.
>
> Just my opinion though ....- Dölj citerad text -
>
> - Visa citerad text -
Thanks for you help !
The problem is , as one of you wrote, that FC6 and FC7 does not
work.
I downloaded FC5, installed and it did restore both the root dbspace
and the smart blobspace as it is supposed to do.
Will now install FC7 again and keep the FC5 handy if I need to
restore. I will also test our production servers where we are using
FC6 with logical logs
Ulf
Ulf wrote:
> On 17 Nov, 12:58, ximrofni <cl...@uk.ibm.com> wrote:
>
>>This indeed seems to be an issue for 10.00.xC6 and 10.00.xC7. However,
>>10.00.xC5 and below work as you'd expect.
>>
>>Is there any chance of performing the restore with this version of the
>>engine, just for the purpose of the restore?
>
>
> I have tried both FC7 and FC6, no luck. Also tried to do an oninit -i
> and the restore , no luck with that either.
>
> Now downloadin FC5 and will give that a try.
>
> Do you if this problem with just the onbar -r -w -p or with other
> types of restore as well ?
>
> Ulf
Hi,
I see that you have got the restore going fine with 10.00.xC5.
Not sure if you are in a position to retry the restore using 10.00.xC7, but if you do, try setting LTAPEDEV to something other than
/dev/null.
The other thing to note, is that when doing the restore, for a restore that "works" you will see that all the dbspaces get listed at
the start of the restore :
10:03:31 Physical Restore of rootdbs, blob_dbspace1, dbspace1, dbspace2, dbspace_12k, dbspace_16k, dbspace_4k, dbspace_8k,
er_dbspace, er_sdbspace, sblob_dbspace1 started.
BUT if you have LTAPEDEV set to /dev/null then ONLY the rootdbs is listed :
10:02:40 Physical Restore of rootdbs started.
TBP
On 17 Nov, 09:26, Ulf <ulf.akerb...@gmail.com> wrote:
> On 17 Nov, 03:42, "da...@smooth1.co.uk" <da...@smooth1.co.uk> wrote:
>
>
>
>
>
> > On 16 Nov, 19:57, Ulf <ulf.akerb...@gmail.com> wrote:
>
> > > We are using version 10.00.FC7 on HP-UX 11.11 with Omniback for
> > > backups.
>
> > > Backups using onbar -b -w are created for the two dbscapes we have,
> > > the root dbspace
> > > and a smartblobspace. According to the online log and Omniback both
> > > are stored on the backup media. The ixbar tells the same.
>
> > > We are not using logical logs, they go to /dev/null.
>
> > > When restoring using onbar -r -p -w the root dbspace is restored as it
> > > is supposed to but the smart blobspace is not. the bar_act.log says
> > > that a complete restore has been made. There are no errors in the
> > > online log or the bar_act.log. Have now tried it 10 times with
> > > different settimg, changes in the ixbar file but it still fails to
> > > restore the smart blob space. This is marked as inconsistent, the
> > > instance is useless.
>
> > > Any ideas ?
>
> > > Regards
>
> > > Ulf
>
> > You also need to run onbar -r -l.
>
> > Even though the database is not logged there are still some logical
> > logs generated e.g. checkpoint records.
>
> > You will find that when running an onbar -b -w after the dbspaces are
> > backed up the onbar processes kick off an onbar logical log backup.
>
> > That log backup is required to bring all dbspaces/blobspaces to the
> > same point in time.
>
> > Try kicking off onbar -r -l and see what happens.
>
> > David.- Dölj citerad text -
>
> > - Visa citerad text -
>
> Tried the onbar -r -l command, but there still is no trace of the
> smart blobspace and this is what I get in the bar_act.log.
>
> The smartblobspace is still marked as Inconsistent.
>
> 2007-11-17 10:21:23 25637 25635 /opt/informix/10/bin/onbar_d -r -
> l
> 2007-11-17 10:21:23 25637 25635 ERROR: Logical Logs cannot be
> restored because
> LTAPEDEV value is /dev/
> null .> Restoring a normal backup (done by onbar -b) is not possible without
> restore
> of logical logs. Only whole system backups (done with onbar -b -w) can
> be
> restored without logical logs as whole system physical-only
> restore
> (using onbar -r -w -p). Then use onmode commands (options -s or -m)
> to
> bring server up without logical log
> restore.
>
> Regards Ulf- Hide quoted text -
>
> - Show quoted text -
DId you try onmode -m after the restore?
Why are you passing -p to the restore command? Try ust running onbar -
r -w.
On 17 Nov, 09:26, Ulf <ulf.akerb...@gmail.com> wrote:
> On 17 Nov, 03:42, "da...@smooth1.co.uk" <da...@smooth1.co.uk> wrote:
>
>
>
>
>
> > On 16 Nov, 19:57, Ulf <ulf.akerb...@gmail.com> wrote:
>
> > > We are using version 10.00.FC7 on HP-UX 11.11 with Omniback for
> > > backups.
>
> > > Backups using onbar -b -w are created for the two dbscapes we have,
> > > the root dbspace
> > > and a smartblobspace. According to the online log and Omniback both
> > > are stored on the backup media. The ixbar tells the same.
>
> > > We are not using logical logs, they go to /dev/null.
>
> > > When restoring using onbar -r -p -w the root dbspace is restored as it
> > > is supposed to but the smart blobspace is not. the bar_act.log says
> > > that a complete restore has been made. There are no errors in the
> > > online log or the bar_act.log. Have now tried it 10 times with
> > > different settimg, changes in the ixbar file but it still fails to
> > > restore the smart blob space. This is marked as inconsistent, the
> > > instance is useless.
>
> > > Any ideas ?
>
> > > Regards
>
> > > Ulf
>
> > You also need to run onbar -r -l.
>
> > Even though the database is not logged there are still some logical
> > logs generated e.g. checkpoint records.
>
> > You will find that when running an onbar -b -w after the dbspaces are
> > backed up the onbar processes kick off an onbar logical log backup.
>
> > That log backup is required to bring all dbspaces/blobspaces to the
> > same point in time.
>
> > Try kicking off onbar -r -l and see what happens.
>
> > David.- Dölj citerad text -
>
> > - Visa citerad text -
>
> Tried the onbar -r -l command, but there still is no trace of the
> smart blobspace and this is what I get in the bar_act.log.
>
> The smartblobspace is still marked as Inconsistent.
>
> 2007-11-17 10:21:23 25637 25635 /opt/informix/10/bin/onbar_d -r -
> l
> 2007-11-17 10:21:23 25637 25635 ERROR: Logical Logs cannot be
> restored because
> LTAPEDEV value is /dev/
> null .> Restoring a normal backup (done by onbar -b) is not possible without
> restore
> of logical logs. Only whole system backups (done with onbar -b -w) can
> be
> restored without logical logs as whole system physical-only
> restore
> (using onbar -r -w -p). Then use onmode commands (options -s or -m)
> to
> bring server up without logical log
> restore.
>
> Regards Ulf- Hide quoted text -
>
> - Show quoted text -
Also try setting BAR_DEBUG=7 in the onconfig file and do this again.
On 20 Nov, 00:38, "da...@smooth1.co.uk" <da...@smooth1.co.uk> wrote:
> On 17 Nov, 09:26, Ulf <ulf.akerb...@gmail.com> wrote:
>
>
>
>
>
> > On 17 Nov, 03:42, "da...@smooth1.co.uk" <da...@smooth1.co.uk> wrote:
>
> > > On 16 Nov, 19:57, Ulf <ulf.akerb...@gmail.com> wrote:
>
> > > > We are using version 10.00.FC7 on HP-UX 11.11 with Omniback for
> > > > backups.
>
> > > > Backups using onbar -b -w are created for the two dbscapes we have,
> > > > the root dbspace
> > > > and a smartblobspace. According to the online log and Omniback both
> > > > are stored on the backup media. The ixbar tells the same.
>
> > > > We are not using logical logs, they go to /dev/null.
>
> > > > When restoring using onbar -r -p -w the root dbspace is restored as it
> > > > is supposed to but the smart blobspace is not. the bar_act.log says
> > > > that a complete restore has been made. There are no errors in the
> > > > online log or the bar_act.log. Have now tried it 10 times with
> > > > different settimg, changes in the ixbar file but it still fails to
> > > > restore the smart blob space. This is marked as inconsistent, the
> > > > instance is useless.
>
> > > > Any ideas ?
>
> > > > Regards
>
> > > > Ulf
>
> > > You also need to run onbar -r -l.
>
> > > Even though the database is not logged there are still some logical
> > > logs generated e.g. checkpoint records.
>
> > > You will find that when running an onbar -b -w after the dbspaces are
> > > backed up the onbar processes kick off an onbar logical log backup.
>
> > > That log backup is required to bring all dbspaces/blobspaces to the
> > > same point in time.
>
> > > Try kicking off onbar -r -l and see what happens.
>
> > > David.- Dölj citerad text -
>
> > > - Visa citerad text -
>
> > Tried the onbar -r -l command, but there still is no trace of the
> > smart blobspace and this is what I get in the bar_act.log.
>
> > The smartblobspace is still marked as Inconsistent.
>
> > 2007-11-17 10:21:23 25637 25635 /opt/informix/10/bin/onbar_d -r -
> > l
> > 2007-11-17 10:21:23 25637 25635 ERROR: Logical Logs cannot be
> > restored because
> > LTAPEDEV value is /dev/
> > null .> > Restoring a normal backup (done by onbar -b) is not possible without
> > restore
> > of logical logs. Only whole system backups (done with onbar -b -w) can
> > be
> > restored without logical logs as whole system physical-only
> > restore
> > (using onbar -r -w -p). Then use onmode commands (options -s or -m)
> > to
> > bring server up without logical log
> > restore.
>
> > Regards Ulf- Hide quoted text -
>
> > - Show quoted text -
>
> Also try setting BAR_DEBUG=7 in the onconfig file and do this again.- Dölj citerad text -
>
> - Visa citerad text -
Onmode -m does not solve the problem.
onbar -r -w does not work if you have LTAPEDEV=/dev/null.
The workaround is to set LTAPEDEV to a filename and then do the
restore, there is a bug in version FC6 and FC7.
Ulf