Second copy of redo log with scp.

[benoit-schmid]

Hello,

As I had asked in ,

I would like to use brarchive to do a first copy on our tape robot with backint and and second copy with scp.

When I test:

brarchive -s -c -u / -p initTST.brarchive.sap -> works fine

brarchive -sc -c -u / -p initTST.scp.sap -> does not work

BR0002I BRARCHIVE 7.10 (27)

BR0181E Option '-sc' not supported for 'stage'

initTST.scp.sap contains the following:

backup_dev_type = stage

stage_copy_cmd = scp

archive_stage_dir = /xxx/yyy

remote_host = host.unige.ch

remote_user = username

Is there something that I would have missed in the config or there is no way to get a second copy with scp?

Thanks in advance for your answer.

[volker_borowski2]

Hi,

looks like you need to switch the runs.

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/0d/d309254a0c11d182b80000e829fbfe/content.htm

says:

> When you back up the offline redo log files to disk, you can only use the BRARCHIVE options -s, -sd and -ds.

So you need to run the stage target with -s first and the tape run with -scd as the second.

Sorry, I did not come accross this one in the first thread of yours.

Volker

[benoit-schmid]

Hello,

But are you sure that "backup_dev_type = util_file" is supported for brarchive -sc option?

Thanks in advance for your answer.

[volker_borowski2]

Hi,

well I use a double run technique with brarchive an util_file

run one (-s) to util_file runs every 2 hours a goes to a utility disk pool.

run two (-sc) to util_file runs daily to a tape pool.

Delete runs (-dc -n 50) are fired by nagios when fs is 70% full.

So yes, -sc to util_file should work.

Volker

[benoit-schmid]

Thanks for the answer.

I will try.

[benoit-schmid]

Hello,

For my information, would you know why stage is not supported with -sc?

Thanks in advance for your answer.

[volker_borowski2]

Hi,

I think this is because there is up to now no target destination parameter for a second copy.

For tapes it is assumed, that you change the tape and therefore "really" write two copies.

If you did not, but reformatted the tape, ... your fault.

With a single targetdirectory, a second copy makes no sense, as you will overwrite your primary backup

(because brarchive is obviously too dumb to check, that first copy did go to a diffrent device, like util_file or tape...)

I hate this for quite some time now.

I have customers who like to backup a first copy to a directory in a local net and a second copy to an offsite location.

I think it might be possible to script something, that involves toggeling the SAPARCH environment and thus having

two archSID.log files, but I'd rather find this approach too risky when it comes to recovery, because, you might have

to find the archived logs on your own, and if you cross-schedule something, you might end up with two brarchives

runnning at the same time, which would not be a very good situation.

Volker

[benoit-schmid]

Hello,

I have tested brarchive -s with stage option.

As you said it works.

#STAGE.... 51 /oracle/TST/saparch/TSTarch1_51_729768278.dbf 2010-09-24 11.37.54 29248000 364646402 1

#STAGESAV. aeeeripp sve xxx/TSTarch1_51_729768278.dbf 2010-09-24 11.38.51 ........... ............

#STAGEDEL. ........ ... .......... ........

If run a second brarchive -scd, with util_file, it does not find any "saved" redo.

There are only "archived" redo.

Therefore it does not save it.

If I run brarchive -sd with util_file, it finds the redo, saves it and deletes it.

#ARCHIVE.. 51 /oracle/TST/saparch/TSTarch1_51_729768278.dbf 2010-09-24 11.37.54 29248000 364646402 1

#SAVED.... aeeerjgt svd *1285321566 2010-09-24 11.46.58 ........... ............

#COPIED... ........ ... ................. .......... ........ ........... ............

#DELETED.. aeeerjgt svd 2010-09-24 11.46.58

#

• TST util_file aeeerjgt svd 2010-09-24 11.46.03 2010-09-24 11.46.58 9 ........... 51 51 0 0 ------- 7.10 (27) @0729768278

#

Therefore the brarchive with util_file consider that the redo has never been saved (by the brarchive with stage options).

Now I have a pseudo solution.

By pseudo, I mean that the redo is deleted after a successfull copy to my tape robot even if the stage did not completed

successfully.

Do I have a way to tell brarchive that it should delete only if it has been STAGESAV AND SAVED?

Thanks in advance for your answer.

[volker_borowski2]

Hi,

not that I tried that, but what happens when you backup to disk with

backup_dev_type = disk

disk_copy_cmd = scp

archive_copy_dir = usernameathost.unige.ch:/xxx/yyy

INFO: edited AT - sign in above line because forum-sw thought it to be an E-mail address

This would appear to be a local copy for brarchive (->archSID.log) but would be in fact a remote copy.

Should make a difference in archSID.log if it does not fail for any check of archive_copy_dir before...

Volker

[benoit-schmid]

Hello Volker,

It does not work:

brarchive -s -c -u / -p initTST.disk.sap

BR0002I BRARCHIVE 7.10 (27)

BR0164E Illegal value 'scp' found for parameter 'disk_copy_cmd'

BR0159E Error reading BR*Tools profile /oracle/TST/102_64/dbs/initTST.disk.sap

BR0007I End of offline redolog processing: aeefurbo.log 2010-09-30 10.49.00

BR0280I BRARCHIVE time stamp: 2010-09-30 10.49.00

BR0005I BRARCHIVE terminated with errors

Regards,

[Former Member]

Hi,

The parameter disk_copy_cmd can have only three possible values (copy|dd|rman). This is disussed in the [help link|http://help.sap.com/saphelp_webas610/helpdata/en/30/18df3a6610696ae10000000a11402f/content.htm].

You need to maintain the target path of the archive files in the parameter archive_copy_dir.

Regards,

Varadharajan M