Forum Discussion

guilhemlflo's avatar
7 years ago

archive catalogue NBU

Hi,

I am trying to archive an NBU catalog.
I use the following link to do the actions:
https://www.veritas.com/support/en_US/article.TECH36433

only I have the error "exit status 227: no entity was found"
The netbackup job runs without errors but the return of the command outputs this error.
in the log bpdbm ​​I have the following error:
"request complete: exit status 227 no entity was found"

if I run the following command: "bpcatlist -before 01 DEC 2007" I have backups that go back up.

i verify ths :"https://www.veritas.com/support/en_US/article.000020429" but the name of my master in bp.conf and this is not the ip adresse.

have you any idea ?

Thanks.

 

  • Marianne's avatar
    Marianne
    7 years ago

    May I ask again - why do want to archive catalogs?

    Have you had a look at and considered my suggestions in my post above?

    There are better ways to deal with limited space on catalog filesystem:
    1. Add more disk and move catalogs to new volume.
    2. Try catalog compression.
    3. Review retention levels - I have never heard of a legal requirement to keep information for more than 10 years.

    Do you really want to take this chance knowing that something could go wrong? And knowing that you don't have any support from Veritas ?

    If you want to know if anything has been archived previously, you can find the command in the Catalog Archive overview:
    https://www.veritas.com/support/en_US/article.100016714.html

    To determine what images have been previously archived and removed from disk, run the following command. 

    # /usr/openv/netbackup/bin/admincmd/bpcatlist -offline 

    Note: This should return "no entity was found" if catalog archiving has not been previously run.  For more information on what the fields in the bpcatlist output indicate, refer to 000028580 in the Related Articles section. 

     

13 Replies

  • I don't know how to assist without having insight into the full procedure that you followed - every single command and its output along with bpdbm log.

    All I can say is that catalog archiving has the potential of causing major issues. If the archive tape is not taken care of and/or gets damage, you have no way of recovering catalogs. This can result in data loss.
    (I have seen this where backup admins for some reason (despite proper media management procedures) could not locate the archive tape.)

    You will also appreciate the fact that you have NO support from Veritas if anything goes wrong because of your EOSL 7.6 version.

    There are better ways to deal with limited space on catalog filesystem:
    1. Add more disk and move catalogs to new volume.
    2. Try catalog compression.
    3. Review retention levels - I have never heard of a legal requirement to keep information for more than 10 years.

    • guilhemlflo's avatar
      guilhemlflo
      Level 4

      when i do :

      "bpcatlist -before 01 DEC 2007" i have no error in the log. :

      09:21:13.838 [13522] <2> image_db: Q_IMAGE_LIST
      09:21:13.843 [13522] <2> read_legacy_touch_file: Found /usr/openv/db/data/vxdbms.conf; requested from (vxdbms_conf.cpp.1529).
      09:21:13.864 [13522] <2> DbmOdbcConnect::set_connection_id: -1 -> 355
      09:21:16.934 [13522] <2> process_request: request complete: exit status 0  ; query type: 76
      09:21:18.249 [2640] <2> vnet_pbxAcceptSocket: Accepted sock[9] from XXXXXXXXXXXX:35848
      09:21:18.251 [13541] <2> logconnections: BPDBM ACCEPT FROM XXXXXXXXXX.35848 TO XXXXXXXXXXX.1556 fd = 9
      09:21:18.251 [13541] <4> bpdbm: VERBOSE = 0
      09:21:18.252 [13541] <2> get_user_identity: Using local Admin creds(user_identity.cpp:158)
      09:21:18.312 [13541] <2> process_request: request complete: exit status 0  ; query type: 91
      09:21:18.320 [2640] <2> vnet_pbxAcceptSocket: Accepted sock[9] from 132.169.100.61:60542
      09:21:18.321 [13542] <2> logconnections: BPDBM ACCEPT FROM XXXXXXXXXXX.60542 TO XXXXXXXXX.1556 fd = 9
      09:21:18.322 [13542] <4> bpdbm: VERBOSE = 0
      09:21:18.322 [13542] <2> get_user_identity: Using local Admin creds(user_identity.cpp:158)
      09:21:18.336 [13542] <2> process_request: request complete: exit status 0  ; query type: 91

      but when i put verbose 5 and i run this commande agin, i have this :

      "No data found when fetching from Join of DBM_Image, DbmImageCopy, DbmImageFragment"

      Doyou know what this error mean ?

    • guilhemlflo's avatar
      guilhemlflo
      Level 4

      when i do :

      "bpcatlist -before 01 DEC 2007" i have no error in the log. :

      09:21:13.838 [13522] <2> image_db: Q_IMAGE_LIST
      09:21:13.843 [13522] <2> read_legacy_touch_file: Found /usr/openv/db/data/vxdbms.conf; requested from (vxdbms_conf.cpp.1529).
      09:21:13.864 [13522] <2> DbmOdbcConnect::set_connection_id: -1 -> 355
      09:21:16.934 [13522] <2> process_request: request complete: exit status 0  ; query type: 76
      09:21:18.249 [2640] <2> vnet_pbxAcceptSocket: Accepted sock[9] from XXXXXXXXXXXX:35848
      09:21:18.251 [13541] <2> logconnections: BPDBM ACCEPT FROM XXXXXXXXXX.35848 TO XXXXXXXXXXX.1556 fd = 9
      09:21:18.251 [13541] <4> bpdbm: VERBOSE = 0
      09:21:18.252 [13541] <2> get_user_identity: Using local Admin creds(user_identity.cpp:158)
      09:21:18.312 [13541] <2> process_request: request complete: exit status 0  ; query type: 91
      09:21:18.320 [2640] <2> vnet_pbxAcceptSocket: Accepted sock[9] from 132.169.100.61:60542
      09:21:18.321 [13542] <2> logconnections: BPDBM ACCEPT FROM XXXXXXXXXXX.60542 TO XXXXXXXXX.1556 fd = 9
      09:21:18.322 [13542] <4> bpdbm: VERBOSE = 0
      09:21:18.322 [13542] <2> get_user_identity: Using local Admin creds(user_identity.cpp:158)
      09:21:18.336 [13542] <2> process_request: request complete: exit status 0  ; query type: 91

      but when i put verbose 5 and i run this commande agin, i have this :

      "No data found when fetching from Join of DBM_Image, DbmImageCopy, DbmImageFragment"

      09:30:01.014 [16117] <2> DBEnumerator::move_next: SQL_SUCCESS
      09:30:01.014 [16117] <2> fetch_DBM_AllImageCopyFrag: Entering
      09:30:01.015 [16117] <2> fetch_DBM_AllImageCopyFrag: Success fetching (2) records from join of DBM_Image, DbmImageCopy, DbmImageFragment
      09:30:01.015 [16117] <2> fetch_DBM_AllImageCopyFrag: Entering
      09:30:01.015 [16117] <2> fetch_DBM_AllImageCopyFrag: No data found when fetching from Join of DBM_Image, DbmImageCopy, DbmImageFragment

      Doyou know what this error mean ?

      • Marianne's avatar
        Marianne
        Level 6

        I don't see any error(s). 
        Everything is debug info <2>.
        There are
        no Warnings <8>
        no Errors <16>
        no Severe Errors <32> 

        Level 5 logs will show all the 'hidden' checks that are done. Whatever is searched for is clearly not perceived by NBU as a problem.

        I cannot tell you what the entries in level 5 log mean.
        That will be of interest to a Veritas backline support engineer should a problem be experienced.

  • Oh! If you look at the example in the doc that you are following, you will notice that your date format is wrong.

    Example from KB article:
    # bpcatlist -client <name> -before Jan 1 2000 

    Your command: 
    bpcatlist -before 01 DEC 2007
    should therefore be:
    bpcatlist -before Dec 01 2007

    • guilhemlflo's avatar
      guilhemlflo
      Level 4

      Hello, indeed for the date, but following test with the format indicated by the documentation, I have the same error.

      Note that I recover this platform and I have great difficulty knowing what has been done.

      Indeed in view of the error, I do not know if I will archive the data but rather try a compression.

      But I would not want to leave mistakes "under the carpet" and using another method.

      I have infinite retention and some backups date from the year 2000/2001. I would have wanted to archive this data in view of ancestry

       

      I try "/usr/openv/netbackup/bin/admincmd/bpcatlist -offline " but i have : "no entity was found"