03-03-2022 09:29 AM
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...
Solved! Go to Solution.
03-04-2022 09:21 AM
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.
03-03-2022 09:30 AM
On backup server No.Restrictions file is present, mentioning just in case
03-04-2022 01:16 AM
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
03-04-2022 04:01 AM
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
03-04-2022 04:14 AM
Also if I check without "-t 4" and policy name, I can see file system backup files. I am very confused...
03-04-2022 04:26 AM
Is this of any help? There's additional steps needed for Oracle redirected restores:
03-04-2022 04:58 AM - edited 03-04-2022 05:14 AM
@AlexChrist A few things to check
03-04-2022 07:51 AM
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.
03-04-2022 09:21 AM
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.
03-04-2022 10:28 AM