A general question about RMAN Backup in Linux

[Former Member]

Hi,

It is always wired for me.

As we all know, when we create a backup job with DB13. The job will start within username <SID>adm

The job creates a directory for the backup and it is writable only for <SID>adm.

But after the integration of RMAN, the username will be altered to ora<SID>, and then, how could RMAN be able to write the file in the backup directory?

I know that it is not a general case, but thanks in advance for your response.

[lbreddemann · Accepted solution]

> It is always wired for me.

Hopefully it is wired and not too weired.

> As we all know, when we create a backup job with DB13. The job will start within username <SID>adm

> The job creates a directory for the backup and it is writable only for <SID>adm.

Nope.

The "Job" does not create a directory - it's brbackup that does this.

And brbackup performs the RMAN call as well - in the same session.

> But after the integration of RMAN, the username will be altered to ora<SID>, and then, how could RMAN be able to write the file in the backup directory?

Because it does this as <SID>ADM in that case.

regards,

Lars

[Former Member · Accepted solution]

Yes it is brbackup that creates the directory, so the owner of directory is <sid>adm. with the permission 747.

And then, when the RMAN is called. I think (Maybe wrong), the connected database user is OPS$ora<sid>. which cannot add a file in the backup directory. So the normal backup couldn't be continued.

Am I right ?

[lbreddemann · Accepted solution]

> And then, when the RMAN is called. I think (Maybe wrong), the connected database user is OPS$ora<sid>. which cannot add a file in the backup directory. So the normal backup couldn't be continued.

>

> Am I right ?

Nope, you're wrong.

When the DB13 calls brbackup to start the backup it does this as <sid>adm.

And within this user context brbackup calls RMAN.

That's one of the reasons why you need to assign the DBA and OPER groups to the <sid>adm user as well.

regards,

Lars

[Former Member · Accepted solution]

At first, thanks for your responses. Your response is correct, however it does not hit the point.

What I talked about is brbackup with RMAN (such as full / incremental backup).

In these cases:

1. backup starts with brbackup - The user is <sid>adm now

2. brbackup creates the directory with OS user <sid>adm, of permission 747

3. however, when the backup really begin , brbackup calls RMAN as following commands:

SHELL=/bin/sh /oracle/DEV/102_64/bin/rman nocatalog

RMAN> connect target *

.....

At this time, the connected database user is OPS$ora<sid>, and then the related OS user has been altered to ora<sid>, and then it could not write a file to the created backup directory.

Anyway, I don't think that RMAN uses <sid>adm. And it is the origin of my question.

Waiting for hearing that I've made some mistakes and have a good 2010!

[lbreddemann · Accepted solution]

> In these cases:

> 1. backup starts with brbackup - The user is <sid>adm now

> 2. brbackup creates the directory with OS user <sid>adm, of permission 747

> 3. however, when the backup really begin , brbackup calls RMAN as following commands:

> SHELL=/bin/sh /oracle/DEV/102_64/bin/rman nocatalog

> RMAN> connect target *

> .....

> At this time, the connected database user is OPS$ora<sid>, and then the related OS user has been altered to ora<sid>, and then it could not write a file to the created backup directory.

Ok, let's do it the other way round.

What makes you believe that brbackup changes it's user context before calling RMAN?

Why should this be the case?

How and where did you see that?

regards,

Lars

[stefan_koehler · Accepted solution]

Hello Xia,

please let me put some thoughts to your last post.

At first i have to mention, that we don't perform RMAN backups with the BR*Tools, but i think you have some fundamental understanding "problems".

> 1. backup starts with brbackup - The user is <sid>adm now

Ok, this is correct.

> 2. brbackup creates the directory with OS user <sid>adm, of permission 747

Maybe - i don't exactly know the permissions that are set by the BR*Tools, but keep in mind if the permissions ar set to 747 then every OS-user is able to write in this directory .. no matter if it is <SID>adm or ora<SID>.

> At this time, the connected database user is OPS$ora<sid>, and then the related OS user has been altered to ora<sid>, and then it could not write a file to the created backup directory.

Wrong - you connect to the database with the RMAN client with an external authentication (prefix OPS$), but this has no influence on the corresponding database shadow process. The shadow process normally runs with ora<SID>. If you perform a "normal" (= not parallel) backup with RMAN, the database spawns 2 shadow processes (one process for calling packages, performing backup and coordinating other RMAN channels processes, one process for "monitoring").

If you think about it now, you should get the solution.

Regards

Stefan

[Former Member · Accepted solution]

Thanks for your answers. I've recently made a test, how I can't explain the result.

Here is my test:

1. I've modified the init<sid>.sap to activate the backup with RMAN.

- backup_dev_type = disk

- disk_copy_cmd = rman

2. Run a full online backup in DB13.

3. The error occurs

BR0280I BRBACKUP time stamp: 2010-01-03 16.34.03

BR0198I Profiles saved successfully

BR0202I Saving /oracle/DP1/sapdata2/sr3_1/sr3.data1

BR0203I to /backup/backup/becguudi/sr3.data1 ...

BR0278E Command output of 'SHELL=/bin/sh /oracle/DP1/10264/bin/rman nocatalog':_

Recovery Manager: Release 10.2.0.4.0 - Production on Sun Jan 3 16:34:03 2010

4. However, I check the directory /backup/backup/becguudi, it has been created. And the permission is set to 755(I was wrong, it is not 747), owner is <sid>adm.

The error in RMAN is:

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03009: failure of backup command on dsk channel at 01/03/2010 16:34:06

ORA-19504: failed to create file "/backup/backup/becguudi/sr3.data1"

ORA-27040: file create error, unable to create file

Linux-x86_64 Error: 13: Permission denied

Why it could occur... If the owner of the processes of RMAN is <sid>adm.

It is weired, no?

[stefan_koehler · Accepted solution]

Hello Xia,

please perform the following commands and post the output.

shell> ls -la /backup/backup/
shell> ls -la /backup/backup/becguudi/
shell> ps -ef | grep oracle

Regards

Stefan

[Former Member · Accepted solution]

[1]ls -la /backup/backup/

total 20

drwxrwxrwx 5 root root 4096 2010-01-03 15:27 .

drwxr-xr-x 4 root root 4096 2010-01-01 22:01 ..

drwxr-xr-x 2 dw1adm sapsys 4096 2010-01-03 05:14 becgspyo

drwxr-xr-x 2 dw1adm sapsys 4096 2010-01-03 15:27 becguudi

drwxr-xr-x 2 dw1adm sapsys 4096 2010-01-03 05:14 DP1

[2]ls -la /backup/backup/becguudi/

total 8

drwxr-xr-x 2 dw1adm sapsys 4096 2010-01-03 15:27 .

drwxrwxrwx 5 root root 4096 2010-01-03 15:27 ..

[3]ps -ef grep oracle

oradp1 712 1 0 17:30 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 714 1 0 17:30 ? 00:00:00 oracleDP1 (LOCAL=NO)

dw1adm 839 7778 0 17:34 ? 00:00:00 sh -c ps -ef grep oracle

dw1adm 841 839 0 17:34 ? 00:00:00 grep oracle

oradp1 7193 1 0 Jan02 ? 00:01:32 /oracle/DP1/102_64/bin/tnslsnr LISTENER -inherit

oradp1 24619 1 0 06:21 ? 00:00:08 oracleDP1 (LOCAL=NO)

oradp1 24622 1 0 06:21 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24624 1 0 06:21 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24626 1 0 06:21 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24638 1 0 06:21 ? 00:00:04 oracleDP1 (LOCAL=NO)

oradp1 24640 1 0 06:21 ? 00:00:03 oracleDP1 (LOCAL=NO)

oradp1 24642 1 0 06:21 ? 00:00:04 oracleDP1 (LOCAL=NO)

oradp1 24678 1 0 06:21 ? 00:00:01 oracleDP1 (LOCAL=NO)

oradp1 24772 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24774 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24776 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24778 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24780 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24782 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24784 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24786 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 24788 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 27666 1 0 09:45 ? 00:00:08 oracleDP1 (LOCAL=NO)

oradp1 29872 1 0 14:15 ? 00:00:00 oracleDP1 (LOCAL=NO)

oradp1 31411 1 0 15:26 ? 00:00:00 oracleDP1 (LOCAL=NO)

[stefan_koehler · Accepted solution]

Hello Xia,

thanks for the output ... you can see the cause of the problem there.

shell> ls -la /backup/backup/
          drwxr-xr-x 2 dw1adm sapsys 4096 2010-01-03 15:27 becguudi

shell> ps -ef grep oracle
          oradp1 24619 1 0 06:21 ? 00:00:08 oracleDP1 (LOCAL=NO)
          oradp1 24622 1 0 06:21 ? 00:00:00 oracleDP1 (LOCAL=NO

The owner of the directory "becguudi" is dw1adm and the group members of "sapsys" and any other user are not allowed to write into this directory ( drwx r-xr-x ). The oracle shadow processes (and also the ones that are spawned through the RMAN client) are running under oradp1, and this user is not allowed to write into "/backup/backup/becguudi".

No idea, why the BRTools are creating the folder "becguudi" with such a strange permission. Have you already checked the permissions of the BRTools itself (especially the s-bit) .. take a look at sapnote #113747 for that.

Regards

Stefan

[Former Member · Accepted solution]

I've checked the Note 113747.

Changing the permissiom of brtools will change the permission of the create directory?

If it could happen, I will take a test....

Anyway, should I create an OSS message for it?

P.S. Thanks for your help, fortunately, I've learned a lot about this thread. I will let it open for some more day and then close it.

P.S.2: My first thread is right .

[stefan_koehler · Accepted solution]

Hello Xia,

> Changing the permissiom of brtools will change the permission of the create directory?

If the s-bit or owner is not set correct - yes.

Explanation: If setuid bit is set, when the file will be executed by a user, the process will have the same rights as the owner of the file being executed

> If it could happen, I will take a test....

Check the s-bit and the owner of the BR*Tools binaries ... it could be the problem.

> Anyway, should I create an OSS message for it?

As i already mentioned we are not using BR*Tools and if the s-bit and owner is set correctly i would suggest this. By the way Lars Breddemann, who already posted some replies to this thread is a SAP employee in the database team .. so ...

Regards

Stefan

[Former Member · Accepted solution]

I've change the brbackup in /usr/sap/<sid>/SYS/exe/run to:

permission = 777

owner = ora<sid>.

But always the same error.....

[stefan_koehler · Accepted solution]

Hello Xia,

> But always the same error.....

Sure ... Did you read and perform the steps from sapnote #113747 ... I can't imagine ...

There is no permission "777" in the corresponding note ...

Read the sapnote and perform the checks and changes

Regards

Stefan

[Former Member · Accepted solution]

Here is the my verification of note 113747

(1)
ora<sid> and <sid>adm on DB server have a search path on /sapmnt/<SID>/exe. (All br* and sapdba are contained in this directory.)
ora<sid> belongs to the dba group,
<sid>adm belongs to the sapsys group,

Done

(2)
<sid>adm on the database server has the rhosts entry: "+ <sid>adm". 

DB server and central instance server is the same one.

(3)
The ops$<sid>adm Oracle user must be created in the DB and must have the sapdba role (not DBA!) (refer to Note 134592 for more information about the role).

<sid>adm has the following role: DBA, SAPDBA, CONNECT, RESSOURCE

P.S. sapdba_role.sql has been executed.

(4)
brarchive, brbackup, and brconnect have permission 4775:
-rwsrwxr-x   ora<sid>   sapsys   ...
These can be started by the ora<sid> or the <sid>adm OS user.

brrestore, brrecover, brspace, brtools, and sapdba have permission 755:
-rwxr-xr-x   <sid>adm   sapsys   ...
These should only be started by the ora<sid> OS user.

The result of command line:

[4]ls -la /sapmnt/DW1/exe/brbackup

-rwxrwxr-x 1 oradp1 sapsys 4284895 2009-02-24 21:37 /sapmnt/DW1/exe/brbackup

[5]ls -la /sapmnt/DW1/exe/brarchive

-rwxrwxr-x 1 oradp1 sapsys 4178065 2009-02-24 21:37 /sapmnt/DW1/exe/brarchive

[6]ls -la /sapmnt/DW1/exe/brconnect

-rwxrwxr-x 1 oradp1 sapsys 5527676 2009-02-24 21:37 /sapmnt/DW1/exe/brconnect

And.. again. The same error.

[stefan_koehler · Accepted solution]

Hello Xia,

> And.. again. The same error.

And again you haven't read the sapnote #113747 accurately.

Your command output:

shell> ls -la /sapmnt/DW1/exe/brbackup
          -rwxrwxr-x 1 oradp1 sapsys 4284895 2009-02-24 21:37 /sapmnt/DW1/exe/brbackup
shell> ls -la /sapmnt/DW1/exe/brarchive
          -rwxrwxr-x 1 oradp1 sapsys 4178065 2009-02-24 21:37 /sapmnt/DW1/exe/brarchive
shell> ls -la /sapmnt/DW1/exe/brconnect
          -rwxrwxr-x 1 oradp1 sapsys 5527676 2009-02-24 21:37 /sapmnt/DW1/exe/brconnect

.... and it should look like (corresponding to sapnote #113747)

          -rwsrwxr-x   ora<sid>   sapsys   ...

And what is wrong?

Take a look at the s-bit ... you need a "S" at fourth position ... and you have a "X" ... just execute "chmod 4775" for the files brarchive, brbackup, and brconnect like described in sapnote #113747

Regards

Stefan

[Former Member]

Must re-attribute pointes