need some help with onbar Veritas Netbackup (informix 7.31)

Hello guys, IHAC who wants to restore his informix instance with onbar. He uses Veritas Netbackup as SM. When restoring the folloging error appears in the bar_act.log file 2020-10-08 10:49:55 8486 8484 /opt/informix/bin/onbar_d -r -w -p 2020-10-08 10:49:55 8486 8484 WARNING: Logical Logs cannot be restored because LTAPEDEV value is /dev/null . 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. 2020-10-08 10:49:55 8486 8484 Working with veritas-netbackup as generic storage manager. 2020-10-08 10:49:56 8486 8484 Successfully connected to Storage Manager. 2020-10-08 10:50:07 8486 8484 XBSA Error (BSAGetObject): This object has not been backed up. 2020-10-08 10:50:12 8486 8484 Due to the previous error, logical restore will not be attempted. 2020-10-08 10:50:12 8486 8484 /opt/informix/bin/onbar_d: process exit 26 (0x1a) I've set BAR_DEBUG_FILE and BAR_DEBUG 6, but could not understand its content. Could anyone help me in this issue? Many thanks in advance, JUAN ------------------------------ juan luis roca ------------------------------ #Informix

Hola Joan Luis, Did you try setting anything but /dev/null in LTAPEDEV ? If the engines sees /dev/null in LTAPEDEV, it considers there is no logical logs backup, be it with ontape OR onbar. So put any other value I LTAPEDEV for instance /tmp/llogsbackup (maybe you have to 'touch' this file, not sure) And it should work Abrazos Eric Eric Vercelletto Data Management Architect and Owner / Begooden IT Consulting Board of Directors, International Informix Users group IBM Champion 2013,2014,2015,2016,2017,2018,2019,2020 Tel: +33(0) 298 51 3210 Mob : +33(0)626 52 50 68 skype: begooden-it Google Hangout: eric.vercelletto@begooden-it.com Email: eric.vercelletto@begooden-it.com www : http://www.vercelletto.com www https://kandooerp.org

And did you launch « onbar -r" or more options ? For me "onbar -r" is what you want

| view attached I'm sending attached bar_debug_file ------------------------------ juan luis roca ------------------------------

Hello Erric, I have put LTAPEDEV to /dades/logs but did not work. Initially I have put it to /dev/null to avoid salvage of logs (onbar -r -w -p) as there is no data in chunks. ------------------------------ juan luis roca ------------------------------

same problem with onbar -r ------------------------------ juan luis roca ------------------------------

A closer look at bar_dbug.log: 2020-10-08 10:49:56 8486 8484 buildObjName: set server_name to servbbdd 2020-10-08 10:49:56 8486 8484 buildObjName: output objectSpaceName /servbbdd, pathName /servbbdd/rootdbs/0 2020-10-08 10:49:56 8486 8484 buildObjName: return 0 (0x00) 2020-10-08 10:49:56 8486 8484 initObjDesc: output: object owner name createTime 2020-10-08 10:49:56 8486 8484 initObjDesc: output: INFORMIX informix /servbbdd /servbbdd/rootdbs/0 0 0 0 0 0 0 2020-10-08 10:49:56 8486 8484 initObjDesc: output: copytype copyid restoreOrder size resource type status desc objectInfo 2020-10-08 10:49:56 8486 8484 initObjDesc: output: 3 0 0 0 0 0 0 4 1 2020-10-08 10:49:56 8486 8484 initObjDesc: return 2020-10-08 10:49:56 8486 8484 BSAGetObject: enter 2020-10-08 10:49:56 8486 8484 BSAGetObject: input: object owner name createTime 2020-10-08 10:49:56 8486 8484 BSAGetObject: input: INFORMIX informix /servbbdd /servbbdd/rootdbs/0 0 0 0 0 0 0 2020-10-08 10:49:56 8486 8484 BSAGetObject: input: copytype copyid restoreOrder size resource type status desc objectInfo 2020-10-08 10:49:56 8486 8484 BSAGetObject: input: 3 1 1599085326 0 0 0 0 R 4 1 2020-10-08 10:49:56 8486 8484 BSAGetObject: input: bufferLen = 63488, numBytes = 0 2020-10-08 10:50:07 8486 8484 BSAGetObject: output: bufferLen = 63488, numBytes = 0 2020-10-08 10:50:07 8486 8484 BSAGetObject: return 26 (0x1a ) 2020-10-08 10:50:07 8486 8484 do_xbsa_error: enter 2020-10-08 10:50:07 8486 8484 do_xbsa_error: input the_error 26 function BSAGetObject 2020-10-08 10:50:07 8486 8484 do_xbsa_error: return 138 (0x8a) 2020-10-08 10:50:07 8486 8484 barGetObject: return 26 (0x1a) 2020-10-08 10:50:07 8486 8484 barEndTxn: enter 2020-10-08 10:50:07 8486 8484 BSAEndTxn: enter 2020-10-08 10:50:07 8486 8484 BSAEndTxn: return 0 (0x00) 2020-10-08 10:50:07 8486 8484 barEndTxn: return 0 (0x00) 2020-10-08 10:50:07 8486 8484 barTerminate: enter 2020-10-08 10:50:07 8486 8484 BSATerminate: enter 2020-10-08 10:50:07 8486 8484 BSATerminate: return 0 (0x00) 2020-10-08 10:50:07 8486 8484 barTerminate: return 0 (0x00) 2020-10-08 10:50:07 8486 8484 do_phys_restore: calling bar_phys_close_restore(BU_ABORT, errtxt) 2020-10-08 10:50:07 8486 8484 bar_phys_close_restore: enter 2020-10-08 10:50:07 8486 8484 bar_phys_close_restore: input commit_flag 1 2020-10-08 10:50:07 8486 8484 bar_phys_close_restore: output errtxt 2020-10-08 10:50:07 8486 8484 bar_phys_close_restore: return 0 (0x00) 2020-10-08 10:50:07 8486 8484 do_phys_restore: return 26 (0x1a) 2020-10-08 10:50:12 8486 8484 return from bar_exec 26 It seems as if could not find rootdbs ------------------------------ juan luis roca ------------------------------

Juan: If the client does indeed have LTAPEDEV set to /dev/null then the logical logs have been discarded immediately after each log was completed so they have not been backed up. You can verify this by looking at the onbar log history. If that is the case, then the messages are valid, your client will be able to restore ONLY to the point of the last full archive (or level 1 or level 2 if they take those). Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Check the Veritas storage manager logs next.

Although the manual does seem to indicate that 'onbar -r -w -p' is an option I think you should just use 'onbar -r -p' if you don't want to restore logical logs. The '-w' and '-p' options contradict each other I think. Changing LTAPEDEV is not the right thing to do here. I would restore it to whatever it was before. Looking at your original post, personally I would not start with the bar debug log when attempting to diagnose the problem. It can be very verbose and difficult to understand. I would look at the fundamentals of what you are trying to do first and make sure everything is as it should be. Some pointers: * Check all environment config especially INFXBSA_CLASS, INFXBSA_CLIENT and INFXBSA_SERVER. * Check also the Netbackup bp.conf file on your server. * Take a look at what is in your ixbar file; this should list backed up objects and will be what is referred to when requesting objects from Netbackup. The engine will be starting with rootdbs from the latest level 0. * As already suggested, check Netbackup logs. Netbackup can have replication: * Check with your Netbackup admin: does the rootdbs object exist on the specific Netbackup server you are using for the restore. Netbackup also has a security set up: * Are you restoring to the same host as the backup was done? If not, Netbackup may not permit you access to the backups. * Is the Netbackup client (your Informix server) permitted to do restores by the NBU server ? I am not sure this is a given with NBU even when you are backing up from the same happily. ------------------------------ Benjamin Thompson ------------------------------

Hi Juan Luis, I think, you first need to figure out, how the backups were done: When the backups were done, was LTAPEDEV set to /dev/null? If that was the case, then logical log files were not (never) backed up, as Art Kagel already explained. In this case ( LTAPEDEV set to /dev/null or otherwise missing backups of logical log), the backups (of the dbspaces) must be done as so-called "whole system backups", i.e. the "-w" parameter must be used for the "onbar" backup command. Then such "whole system backups" can be restored, where you again have to use the "-w" parameter in the "onbar" restore command - as recommended in the error message that you see. The problem is that with ON-Bar, backups that are not "whole system backups" never can be restored without restoring logical logs. The next problem is, that the customer is using a rather (you may say "very") old version, 7.31. As far as I remember, in such old versions it unfortunately was possible to do ON-Bar backups that are not "whole system backups", even though LTAPEDEV was set to /dev/null. I.e. it was possible to "successfully" do useless (non-"whole system") backups, even though they can never be restored - without the backup command causing an error. Maybe there was a warning in the ON-Bar activity log, but I think no error was produced. (We have later fixed that, so that it is no longer possible to do such backups where it is known already at backup time, that it cannot be restored - because LTAPEDEV is set to /dev/null. Obviously, this does not help the customer in his situation, as he is still using this old version.) Background (I try to explain this as simple as possible): If the customer did not backup logical logs, but also did not do "whole system backups" ... then, I'm afraid, he is pretty much out of luck. Regards, Martin -- -- DISCLAIMER-- ------------------------------ This document is intended for transmission to the named recipient only. If you are not that person, you should note that legal rights reside in this document and you are not authorized to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. The views expressed in this document are not necessarily those of HCL Technologies Ltd. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail, which must be interpreted accordingly. Any representations, contractual rights or obligations shall be separately communicated in writing and signed in the original by a duly authorized officer of the relevant company. ------------------------------ ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.

It's been a looong time since I've dealt with onbar (never mind 7.31!) but IIRC, running onbar without logical log backups is unsupported. That's because of the differences in how onbar and ontape work. The ontape utility backs up all of the spaces serially, and has a single global start time; when you restore an ontape backup without doing a logical rollforward, the entire engine looks exactly as it did when you started the backup. (Any changes made while the backup is running result in the unchanged pages being copied to temp space; when the backup gets to those modified pages, it backs up the original from temp space instead.) The onbar utility, OTOH, was designed for much larger systems where this type of backup is impractical, and runs the risk of running you out of temp space. With onbar, spaces are backed up in parallel , and each space is effectively its own independent backup object. When you restore a space without logical rollforward, each space looks as it did when the backup of that space started. If you do a full-system restore that way, your database will be in an inconsistent state, because the different dbspaces will be reflective of different timestamps. The only way to get the system to a consistent state is to roll forward to at least the point in time at which the final dbspace backup began. Now it's always possible that I'm remembering this incorrectly ( @Art Kagel ? ) or that there was some option to change this behavior that I'm forgetting about, but I don't recall ever being able to successfully restore from onbar backup without doing a logical rollforward. When logical rollforward failed, advanced support had to get in there and hack flags in the dbspaces to make things quasi-consistent again. ------------------------------ TOM GIRSCH ------------------------------

Tom: I'm not sure that it is a problem to restore from onbar without a logical log rollforward, certainly it's not a problem if the archive was taken with the -w (whole system) flag. With -w the archive is essentially done the same way as ontape does it in that the physical log records of pages modified during the archive are copied into temp tables (one per dbspace) and appended to the archive after each dbspace's archive is completed. Those pages restore the disk to the state it was in at the beginning of the archive no matter what changes happened on disk after the archive began. Now, if the archive was not a whole system archive, ie each dbspace was its own separate archive, then, yes, each dbspace will be restored to a different point in time and may be inconsistent without logical logs to be used to rollback those dbspaces whose archives started after the first dbspace's archive (usually the rootdbs) started. That's when you will have an issue. And, yes, you cannot backup the dbspaces with ontape or onbar but back up the logical logs with the other utility! Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Art: That's right. I had forgotten about the –w option. The couple of times I messed with it, in those way early days, I didn't have much luck with it. So you need to do an onbar –b –w before doing an onbar –r –w –p is possible. Not for nothing, I detested onbar. ;) - TJG

Onbar is generations better than onarchive! Art ------------------------------ Art Kagel ------------------------------

Talk about damning with faint praise! J

Nothing faint about it. Onarchive was HORRIBLE and its archives were not reliable. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Fantastic syntax though