Forum Discussion

AlexChrist's avatar
AlexChrist
Level 3
3 years ago

Unable to perform Oracle restore. Doesn't see backupsets. Exit status 227

Hello,

I am running netbackup 7.7.3 and I want to restore database to a new host.

I have production server, and two test servers.

On prod:

[oraprod@r12db netbackup]$ bin/bplist -C r12db -S backup-a -k r12db_db -t 4 -R /
/DB2.LOGS.PROD.s1760.p1
/DB2.LOGS.PROD.s1759.p1
/DB2.INC0.PROD.s1758.p1
/DB2.INC0.PROD.s1757.p1
/DB2.INC0.PROD.s1756.p1

On first test server I get:

[oratest@testdb2 netbackup]$ bin/bplist -C r12db -S backup-a -k r12db_db -t 4 -R /
/DB2.LOGS.PROD.s1760.p1
/DB2.LOGS.PROD.s1759.p1
/DB2.INC0.PROD.s1758.p1
/DB2.INC0.PROD.s1757.p1
/DB2.INC0.PROD.s1756.p1

But on second test server I get:

-bash-4.2$ bin/bplist -C r12db -S backup-a -k r12db_db -t 4 -R /
EXIT STATUS 227: no entity was found

 

I am confused on what can cause this, and I verified multiple settings. I do not know what else to check...

  • AlexChrist's avatar
    AlexChrist
    3 years ago

    So I figured it out. Problem was to assign same gid to user (dba (gid=200) in my case on prod) as where backup was made.

    sudo usermod -g 201 oratest (201 = dba on destination server)

    and everything works.

9 Replies

  • Hi AlexChrist 

    Second test server is missing alternate restore rights. By default Netbackup will only allow a client to restore it's own data. If you are going to clone a database from production to test/dev you have to give the client alternate restore rights.

    Pls See:

    https://www.veritas.com/support/en_US/doc/18716246-126559472-0/v41612926-126559472

    Pls be very careful using No.Restrictions since it may allow any client to restore any data, totally defeating data confidentiality. Where is the "No.Restrictions" file located ? 

    Best Regards
    Nicolai

     

     

    • AlexChrist's avatar
      AlexChrist
      Level 3

      Thanks Nicolai, but that document refers to same approach I tried.

      No.Restrictions file is located on backup-a server: /usr/openv/netbackup/db/altnames/No.Restrictions

      • AlexChrist's avatar
        AlexChrist
        Level 3

        Also if I check without "-t 4" and policy name, I can see file system backup files. I am very confused...

  • On backup server No.Restrictions file is present, mentioning just in case

  • AlexChrist A few things to check

    • Are name resolution working correctly - both forward and reverse on the master server for second test server ?
    • On the master server, take a look at bprd/bpcd or use vxlogview -p 51216 -t 00:01:00 to view all activity on the master server one minute back. There should be a cause for bplist not working in the debug text.
    • AlexChrist's avatar
      AlexChrist
      Level 3

      Nicolai 

      Thank you.

      1. Yes, all that works

      2. That wasn't very informative as well. Sample what I get:

      16:22:10.372 [18972] <16> child_fork: from BPRD_GET_BPLIST, bp error = no entity was found
      16:22:36.193 [18987] <16> child_fork: from BPRD_GET_BPLIST, bp error = no entity was found
      16:23:19.914 [19074] <16> child_fork: from BPRD_GET_BPLIST, bp error = no entity was found
      16:24:20.052 [19171] <16> child_fork: from BPRD_GET_BPLIST, bp error = no entity was found
      16:24:55.262 [19193] <16> child_fork: from BPRD_GET_BPLIST, bp error = no entity was found

      But good news I was able to get closer to finding root cause. It is something related to user permissions.

      Because if on problem client I will check from root - I am able to see oracle backup files.

      So I asked for sudo permission for oratest user and checked same command but with sudo:

      sudo bin/bplist -C r12db -S backup-a -k r12db_db -t 4 -R /

      which happily listed oracle backup files.

      Testdb3 server (problem one)

      bash-4.2$ id oratest
      uid=1001(oratest) gid=1001(oratest) groups=1001(oratest),10(wheel),201(dba)
      doesn't show without sudo

      testdb2 server
      [oratest@testdb2 ~]$ id oratest
      uid=510(oratest) gid=200(dba) groups=200(dba)
      Works OK as is. Only differece I see is gid, but Unix team says it shouldn't matter, and will look at it later.

       

      • AlexChrist's avatar
        AlexChrist
        Level 3

        So I figured it out. Problem was to assign same gid to user (dba (gid=200) in my case on prod) as where backup was made.

        sudo usermod -g 201 oratest (201 = dba on destination server)

        and everything works.

  • Glad you got it sorted out, please remember to restart oracle so new GID take effect.

    /Nicolai