Informix

 View Only
Expand all | Collapse all

need some help with onbar Veritas Netbackup (informix 7.31)

  • 1.  need some help with onbar Veritas Netbackup (informix 7.31)

    Posted Thu October 08, 2020 06:21 AM
    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


  • 2.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    Posted Thu October 08, 2020 06:24 AM

    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
    ibm-champion-rgb-130px

    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

     

     






  • 3.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    Posted Thu October 08, 2020 06:51 AM
    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
    ------------------------------



  • 4.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    Posted Fri October 09, 2020 05:09 AM
    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
    ------------------------------



  • 5.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    Posted Thu October 08, 2020 06:27 AM

    And did you launch « onbar -r" or more options ?

    For me "onbar -r" is what you want

     






  • 6.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    Posted Thu October 08, 2020 06:59 AM
    same problem with onbar -r

    ------------------------------
    juan luis roca
    ------------------------------



  • 7.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    Posted Thu October 08, 2020 06:32 AM
      |   view attached
    I'm sending attached bar_debug_file

    ------------------------------
    juan luis roca
    ------------------------------

    Attachment(s)

    log
    bar_dbug.log   672 KB 1 version


  • 8.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    Posted Thu October 08, 2020 07:08 AM
    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
    ------------------------------



  • 9.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    Posted Thu October 08, 2020 12:25 PM

    Check the Veritas  storage manager logs  next.

     

     

     






  • 10.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    IBM Champion
    Posted Thu October 08, 2020 08:13 AM
    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


    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.








  • 11.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    Posted Fri October 09, 2020 05:32 AM
    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):

    With ON-Bar, dbspaces are backed up "individually" (and possibly in parallel). The "individually" here means, that each dbspace is backed up by a separate process (and these then can run in parallel). It also means, that each process creates its own "archive timestamp" - for the individual dbspace it has to backup. This "archive timestamp" determines during the backup processing, which records (or their versions) need to be backed up, because they are "from before the archive timestamp", and which records (or their versions) do not need to be backed up, because "they were inserted or changed after the archive timestamp". With that, the dbspace backup itself then contains all the data that is consistent to the time of the "archive timestamp" of the dbspace.

    Now the problem is, that an ON-Bar backup of a system (normally) contains one "individual" backup of each dbspace, i.e. these backups of the dbspaces have different "archive timestamps". With that, the content of the backup is only consistent within each individual dbspace backup, but across the dbspaces, these individual backups are not consistent. Therefore, it is necessary to use logical log records during the restore to re-establish the consistency across all the individual dbspaces. Without restoring logical logs, it is not possible to restore the system to an overall consistent state.

    To allow backups and restores to be usable with ON-Bar even without backing up logical logs, there is the concept of a "whole system backup" and corresponding "whole system restore". When doing an ON-Bar "whole system backup", there is only one single "archive timestamp" for the whole system, i.e. for all dbspaces. In addition - in this old version 7.31 at least, I think - this meant that a "whole system backup" was not done in parallel. I.e. all dbspaces were backed up serially. This obviously made a "whole system backup" much slower than a normal (parallel) backup. This was the price to pay for the "luxury" to not need to backup logical logs and still to be able to do a restore of the system. (Basically, an ON-Bar "whole system backup" was done in the same way that was always used for "ontape" - which always was to use just one single "archive timestamp" and backup the dbspaces serially. We later enhanced ON-Bar to be capable of doing "whole system archives" in parallel, but I think that was quite a while after version 7.31.)

    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

    --
    Martin Fuerderer
    Informix Development Germany


    HCL Technologies Germany GmbH
    Frankfurter Ring 17
    80807 Munich, Germany
    http://www.hcltech.com/de
    --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.






  • 12.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    IBM Champion
    Posted Fri October 09, 2020 11:48 AM

    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
    ------------------------------



  • 13.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    IBM Champion
    Posted Fri October 09, 2020 01:29 PM
    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


    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.








  • 14.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    IBM Champion
    Posted Fri October 09, 2020 03:12 PM

    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






  • 15.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    IBM Champion
    Posted Fri October 09, 2020 03:25 PM
    Onbar is generations better than onarchive!

    Art

    ------------------------------
    Art Kagel
    ------------------------------



  • 16.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    IBM Champion
    Posted Fri October 09, 2020 04:00 PM

    Talk about damning with faint praise! J






  • 17.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    IBM Champion
    Posted Fri October 09, 2020 04:03 PM
    Nothing faint about it. Onarchive was HORRIBLE and its archives were not reliable.

    Art

    Art S. Kagel, President and Principal Consultant
    ASK Database Management


    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.








  • 18.  RE: need some help with onbar Veritas Netbackup (informix 7.31)

    IBM Champion
    Posted Fri October 09, 2020 04:23 PM

    Fantastic syntax though