My thanks to the group, especially Mike Walker, for your help in getting that blessed onbar restore going successfully.

Now I have a variation on that issue but it calls for a new thread. I have it working NOW but I'm just hoping for an explanation of a screwy rabbit error in a first attempt.

I am now trying to to a point-in-time restore from that prod server onto a sandbox server.  As I learned earlier, I have copied the ixbar.<servernnum>  saved from Jan 1 backup over the current ixbar.<servernum> on the target host.  Then I ran this command:

nohup onbar -r -p -w -t "2025-01-01 04:51:32" &

After a few stalls (BAR_TIMEOUT The storage manager progress might be stalled for at least 12 minutes.) the restore failed with this message:

Failed to determine archive's encryption mode. Error code 2

After it happened twice, I started to write this letter.  Then the inspiration hit me to omit the -w (whole) .  And, after that same stupid stall, it is running. YAAAY!  So now I can finally get to my question

Why in blazes did I get that ENCRYPTION MODE message?  Or is it just another misleading IBM error message?

Low priority for me here but it's just an interesting question.

Thanks y'all.  (English REALLY needs a plural "you"!)

------------------------------
Jacob Salomon
---
Nobody goes there anymore, it's too crowded.  --Attr: Yogi Berra
------------------------------

I have seen this error before.  I think that the "failed to determine archive's encryption mode" is misleading, and does not necessarily have anything to do with encryption.  Instead, it is related to some other error.  I had this before when I was pointing to the wrong Netbackup server, or some other Netbackup configuration or environment problem.  I was changing the bp.conf file and when I had the wrong combination of SERVER/REQUIRED_INTERFACE/CLIENT_NAME/MEDIA_SERVER or using the wrong policy, then I might get this error.  I feel that this means that it has been able to find the object, but it can't read it...for whatever reason.

Why it would fail when using the PIT restore and the -w option then I am not sure.  But using the -p with the -w seems a bit odd, so perhaps it's related.

------------------------------
Mike Walker
xDB Systems, Inc
www.xdbsystems.com
------------------------------

Original Message:
Sent: 3/13/2025 1:58:00 PM
From: Mike Walker
Subject: RE: Onbar: Failed to determine archive's encryption mode. Error code 2

I have seen this error before.  I think that the "failed to determine archive's encryption mode" is misleading, and does not necessarily have anything to do with encryption.  Instead, it is related to some other error.  I had this before when I was pointing to the wrong Netbackup server, or some other Netbackup configuration or environment problem.  I was changing the bp.conf file and when I had the wrong combination of SERVER/REQUIRED_INTERFACE/CLIENT_NAME/MEDIA_SERVER or using the wrong policy, then I might get this error.  I feel that this means that it has been able to find the object, but it can't read it...for whatever reason.

Why it would fail when using the PIT restore and the -w option then I am not sure.  But using the -p with the -w seems a bit odd, so perhaps it's related.

------------------------------
Mike Walker
xDB Systems, Inc
www.xdbsystems.com
------------------------------

Original Message:
Sent: 3/13/2025 1:58:00 PM
From: Mike Walker
Subject: RE: Onbar: Failed to determine archive's encryption mode. Error code 2

I have seen this error before.  I think that the "failed to determine archive's encryption mode" is misleading, and does not necessarily have anything to do with encryption.  Instead, it is related to some other error.  I had this before when I was pointing to the wrong Netbackup server, or some other Netbackup configuration or environment problem.  I was changing the bp.conf file and when I had the wrong combination of SERVER/REQUIRED_INTERFACE/CLIENT_NAME/MEDIA_SERVER or using the wrong policy, then I might get this error.  I feel that this means that it has been able to find the object, but it can't read it...for whatever reason.

Why it would fail when using the PIT restore and the -w option then I am not sure.  But using the -p with the -w seems a bit odd, so perhaps it's related.

------------------------------
Mike Walker
xDB Systems, Inc
www.xdbsystems.com
------------------------------

HI Jacob,

Try BAR_DEBUG 5 and if that does not help then BAR_DEBUG 9!!

Also check the storage manager logs for a clue.

Regards,
David.

------------------------------
David Williams
Senior Database Platform Engineer
Flutter
London
------------------------------

Is there a -w backup available in the ixbar file you provided? Are backups done using -w?

The fact that it's engaged with the storage manager (?) for so long would indicate it did find something in ixbar that would pass as a -w backup and now is asking the SM to provide it -> do these objects possibly no longer exist there?

Anyway, if some sort of "not found" or "not existing" is the real reason, then this error is more than misleading and should probably be fixed.

------------------------------
Andreas Legner
Informix Dev
HCL Software
------------------------------

Hello Jacob,

I would allways make backup/restore with -w (whole system backup flag). You can verify this in the ixbar file
if the 4th field is set to 1 and 2nd field contains the dbspace name.
It is also impossible to mix backup/restore with/without whle system backup flag...

Maybe it is good to split restore into physical and logical restore:
$ onbar -r -w -p -t "DATETIME"
$ onbar -r -l -t "DATETIME"

And maybe there is a bug in onbar depending on that arguments given.
There is option -pw which is for "encryption password in a file"
So maybe this is used and give that error if you enter -p -w .....

Cheers,
Markus

------------------------------
Markus Holzbauer
------------------------------

Original Message:
Sent: 3/14/2025 6:13:00 AM
From: Markus Holzbauer
Subject: RE: Onbar: Failed to determine archive's encryption mode. Error code 2

Hello Jacob,

I would allways make backup/restore with -w (whole system backup flag). You can verify this in the ixbar file
if the 4th field is set to 1 and 2nd field contains the dbspace name.
It is also impossible to mix backup/restore with/without whle system backup flag...

Maybe it is good to split restore into physical and logical restore:
$ onbar -r -w -p -t "DATETIME"
$ onbar -r -l -t "DATETIME"

And maybe there is a bug in onbar depending on that arguments given.
There is option -pw which is for "encryption password in a file"
So maybe this is used and give that error if you enter -p -w .....

Cheers,
Markus

------------------------------
Markus Holzbauer
------------------------------

Hello Jacob,

normaly there should be following messages in bar_act.log when starting logical restore:
DATE TIME ONBAR_PID ONBAR_D_PID $INFORMIXDIR/bin/onbar_d -r -l -t DATE TIME
... Using Veritas XBSA ... as the Storage Manager...
... bar_build_timelline: target time XXXX ...
... Successfully connected to Storage Manager.
...Begin restore logical log AAAA
...Completed restore logical log AAA
and so on...
Since there is no message in bar_act log when running logical restore I asume that 
the onbar environment is not set correctly.
Maybe Logical Logs are in a different policy/pool than the dbspaces...
Look at following Variables set on the backup system (you need to that these Variables also on Destination system):
INFXBSA_POLICY
INFXBSA_LOGICAL_POLICY

Cheers and good luck,
Markus

------------------------------
Markus Holzbauer
------------------------------

Original Message:
Sent: Fri March 14, 2025 02:13 PM
From: Jacob Salomon
Subject: Onbar: Failed to determine archive's encryption mode. Error code 2

> Maybe it is good to split restore into physical and logical restore:
> $ onbar -r -w -p -t "DATETIME"
> $ onbar -r -l -t "DATETIME"

Hi Mark.

That's exactly what I ended up doing.  Not without its pifalls:

The physical restore actually seems to have finished before 2 AM this morning but there was no message in either the message log nor in the bar_act.log.  But there was no onbar process running.  And the system state was still in fast-recovery.

At about 7:30 AM I took note of this and started onbar -r -l -t "<that time>".  No action in either log. (I have tail -f running in two Putty windows.)  When I got back to it much later I saw that the logical recovery had started at 8:40.  Then, at 8:45 the message appeared: Logical restore suspended.  I noticed this at ~10 AM and did:

$ onbar -RESTART

No action again for over 2 hours.  Then, at 12:30 PM, I got:

12:30:05  Resuming Logical restore.

12:30:06  Suspending logical restore  (Get that program a belt instead of suspenders! :-)

That last onbar command has exited and my server is still stuck in fast-recovery mode.

That's my status as I type this.  I can only check on it periodically; I'm celebrating Purim today and don't want to keep at this all day.

WOW! This thread has veered off from a curiosity question to a minor disaster recovery problem. (Not a production server.)

Next: I killed (-2) the onbar_d, dynamically set BAR_DEBUG=5 (Thanks, Dave)  and restarted the onbar -RESTART.  After all the crazy verbiage I finally got a coherent clue:

• onbar could not get logical log <nnnnnn> from storage manager
• onbar suspended the logical log restore

NOW we're getting somewhere.

Giving up for the weekend.  Thanks all so far!

+----- Jacob Salomon --------------------------------------------------+

| Praise without end for the go-ahead zeal of whoever it was that      |

|  invented the wheel;                                                 |

| But never a word for the poor soul's sake that thought ahead,        |

|  and invented the brake.                                             |

+-------------- Howard Nemerov, on the US Bicentennial ----------------+

Original Message:
Sent: 3/14/2025 6:13:00 AM
From: Markus Holzbauer
Subject: RE: Onbar: Failed to determine archive's encryption mode. Error code 2

Hello Jacob,

I would allways make backup/restore with -w (whole system backup flag). You can verify this in the ixbar file
if the 4th field is set to 1 and 2nd field contains the dbspace name.
It is also impossible to mix backup/restore with/without whle system backup flag...

Maybe it is good to split restore into physical and logical restore:
$ onbar -r -w -p -t "DATETIME"
$ onbar -r -l -t "DATETIME"

And maybe there is a bug in onbar depending on that arguments given.
There is option -pw which is for "encryption password in a file"
So maybe this is used and give that error if you enter -p -w .....

Cheers,
Markus

------------------------------
Markus Holzbauer
------------------------------

OK, folks.  You can finish the bag of popcorn now.  I was able to get help from the previous DBA who set things up here.

• The reason it was unable to find the log to restore (that caused the suspended restore)was that it had been expired 6 weeks ago; no way to retrieve it. The repeated onbar -RESTART commands (without and then with BAR_DEBUG) just dug me deeper into the hole.  (a not unfamiliar situation for me. :-)
• The logical restore was entirely unnecessary in my case, since I was restoring to the same point-in-time as the creation of that ixbar file.  The logs had nothing to contribute, even if they had not expired.
• My befuddlement came as a result of (a) No "physical restore of whole server" message.  And (b) The instance seemed to be stuck in Fast recovery mode.
• My way out of it was to
  • Down the engine
  • Use ipcrm to remove all traces of Informix in the IP infrastructure. (There is a clean utility but I didn't remember the exact name.)
  • $ oninit -rv  I haven't seen this option documented but the former DBA knew of it and revealed the secret. It's not documented on this oninit page. This took a while to open all the chunk files but I was patient.  This still left the server in Fast recovery mode.
• Finally did was I should have done in the first place: onmode -m.  This took a loooong time because my system as a lotta logs to clean out but the server eventually came on-line.

YAAAAY!!

My thanks to all who contributed to our general knowledge about onbar.

------------------------------
Jacob Salomon
---
Nobody goes there anymore, it's too crowded.  --Attr: Yogi Berra
------------------------------

Original Message:
Sent: Fri March 14, 2025 02:13 PM
From: Jacob Salomon
Subject: Onbar: Failed to determine archive's encryption mode. Error code 2

> Maybe it is good to split restore into physical and logical restore:
> $ onbar -r -w -p -t "DATETIME"
> $ onbar -r -l -t "DATETIME"

Hi Mark.

That's exactly what I ended up doing.  Not without its pifalls:

The physical restore actually seems to have finished before 2 AM this morning but there was no message in either the message log nor in the bar_act.log.  But there was no onbar process running.  And the system state was still in fast-recovery.

At about 7:30 AM I took note of this and started onbar -r -l -t "<that time>".  No action in either log. (I have tail -f running in two Putty windows.)  When I got back to it much later I saw that the logical recovery had started at 8:40.  Then, at 8:45 the message appeared: Logical restore suspended.  I noticed this at ~10 AM and did:

$ onbar -RESTART

No action again for over 2 hours.  Then, at 12:30 PM, I got:

12:30:05  Resuming Logical restore.

12:30:06  Suspending logical restore  (Get that program a belt instead of suspenders! :-)

That last onbar command has exited and my server is still stuck in fast-recovery mode.

That's my status as I type this.  I can only check on it periodically; I'm celebrating Purim today and don't want to keep at this all day.

WOW! This thread has veered off from a curiosity question to a minor disaster recovery problem. (Not a production server.)

Next: I killed (-2) the onbar_d, dynamically set BAR_DEBUG=5 (Thanks, Dave)  and restarted the onbar -RESTART.  After all the crazy verbiage I finally got a coherent clue:

• onbar could not get logical log <nnnnnn> from storage manager
• onbar suspended the logical log restore

NOW we're getting somewhere.

Giving up for the weekend.  Thanks all so far!

+----- Jacob Salomon --------------------------------------------------+

| Praise without end for the go-ahead zeal of whoever it was that      |

|  invented the wheel;                                                 |

| But never a word for the poor soul's sake that thought ahead,        |

|  and invented the brake.                                             |

+-------------- Howard Nemerov, on the US Bicentennial ----------------+

Original Message:
Sent: 3/14/2025 6:13:00 AM
From: Markus Holzbauer
Subject: RE: Onbar: Failed to determine archive's encryption mode. Error code 2

Hello Jacob,

I would allways make backup/restore with -w (whole system backup flag). You can verify this in the ixbar file
if the 4th field is set to 1 and 2nd field contains the dbspace name.
It is also impossible to mix backup/restore with/without whle system backup flag...

Maybe it is good to split restore into physical and logical restore:
$ onbar -r -w -p -t "DATETIME"
$ onbar -r -l -t "DATETIME"

And maybe there is a bug in onbar depending on that arguments given.
There is option -pw which is for "encryption password in a file"
So maybe this is used and give that error if you enter -p -w .....

Cheers,
Markus

------------------------------
Markus Holzbauer
------------------------------

That's great!  You have found out a lot about using onbar and Veritas...and that will be useful for the future.

The command to clean up the memory segments, etc has the cryptic name of...."onclean"!    :-)

------------------------------
Mike Walker
xDB Systems, Inc
www.xdbsystems.com
------------------------------

Original Message:
Sent: Tue March 18, 2025 06:47 PM
From: Jacob Salomon
Subject: Onbar: Failed to determine archive's encryption mode. Error code 2

OK, folks.  You can finish the bag of popcorn now.  I was able to get help from the previous DBA who set things up here.

• The reason it was unable to find the log to restore (that caused the suspended restore)was that it had been expired 6 weeks ago; no way to retrieve it. The repeated onbar -RESTART commands (without and then with BAR_DEBUG) just dug me deeper into the hole.  (a not unfamiliar situation for me. :-)
• The logical restore was entirely unnecessary in my case, since I was restoring to the same point-in-time as the creation of that ixbar file.  The logs had nothing to contribute, even if they had not expired.
• My befuddlement came as a result of (a) No "physical restore of whole server" message.  And (b) The instance seemed to be stuck in Fast recovery mode.
• My way out of it was to
  • Down the engine
  • Use ipcrm to remove all traces of Informix in the IP infrastructure. (There is a clean utility but I didn't remember the exact name.)
  • $ oninit -rv  I haven't seen this option documented but the former DBA knew of it and revealed the secret. It's not documented on this oninit page. This took a while to open all the chunk files but I was patient.  This still left the server in Fast recovery mode.
• Finally did was I should have done in the first place: onmode -m.  This took a loooong time because my system as a lotta logs to clean out but the server eventually came on-line.

YAAAAY!!

My thanks to all who contributed to our general knowledge about onbar.

------------------------------
Jacob Salomon
---
Nobody goes there anymore, it's too crowded.  --Attr: Yogi Berra
------------------------------


Original Message:
Sent: Fri March 14, 2025 02:13 PM
From: Jacob Salomon
Subject: Onbar: Failed to determine archive's encryption mode. Error code 2

> Maybe it is good to split restore into physical and logical restore:
> $ onbar -r -w -p -t "DATETIME"
> $ onbar -r -l -t "DATETIME"

Hi Mark.

That's exactly what I ended up doing.  Not without its pifalls:

The physical restore actually seems to have finished before 2 AM this morning but there was no message in either the message log nor in the bar_act.log.  But there was no onbar process running.  And the system state was still in fast-recovery.

At about 7:30 AM I took note of this and started onbar -r -l -t "<that time>".  No action in either log. (I have tail -f running in two Putty windows.)  When I got back to it much later I saw that the logical recovery had started at 8:40.  Then, at 8:45 the message appeared: Logical restore suspended.  I noticed this at ~10 AM and did:

$ onbar -RESTART

No action again for over 2 hours.  Then, at 12:30 PM, I got:

12:30:05  Resuming Logical restore.

12:30:06  Suspending logical restore  (Get that program a belt instead of suspenders! :-)

That last onbar command has exited and my server is still stuck in fast-recovery mode.

That's my status as I type this.  I can only check on it periodically; I'm celebrating Purim today and don't want to keep at this all day.

WOW! This thread has veered off from a curiosity question to a minor disaster recovery problem. (Not a production server.)

Next: I killed (-2) the onbar_d, dynamically set BAR_DEBUG=5 (Thanks, Dave)  and restarted the onbar -RESTART.  After all the crazy verbiage I finally got a coherent clue:

• onbar could not get logical log <nnnnnn> from storage manager
• onbar suspended the logical log restore

NOW we're getting somewhere.

Giving up for the weekend.  Thanks all so far!

+----- Jacob Salomon --------------------------------------------------+

| Praise without end for the go-ahead zeal of whoever it was that      |

|  invented the wheel;                                                 |

| But never a word for the poor soul's sake that thought ahead,        |

|  and invented the brake.                                             |

+-------------- Howard Nemerov, on the US Bicentennial ----------------+

Original Message:
Sent: 3/14/2025 6:13:00 AM
From: Markus Holzbauer
Subject: RE: Onbar: Failed to determine archive's encryption mode. Error code 2

Hello Jacob,

I would allways make backup/restore with -w (whole system backup flag). You can verify this in the ixbar file
if the 4th field is set to 1 and 2nd field contains the dbspace name.
It is also impossible to mix backup/restore with/without whle system backup flag...

Maybe it is good to split restore into physical and logical restore:
$ onbar -r -w -p -t "DATETIME"
$ onbar -r -l -t "DATETIME"

And maybe there is a bug in onbar depending on that arguments given.
There is option -pw which is for "encryption password in a file"
So maybe this is used and give that error if you enter -p -w .....

Cheers,
Markus

------------------------------
Markus Holzbauer