OmniBack (OB II) v. 3.10 and SAP Backups over secondary NIC (256 Views)
Reply
Occasional Contributor
Jason Heideloff
Posts: 2
Registered: ‎01-08-1998
Message 1 of 2 (256 Views)

OmniBack (OB II) v. 3.10 and SAP Backups over secondary NIC

I'm trying to backup SAP databases over a secondary interface. The primary interface is a FDDI NIC with a hostname twidev. The secondary interface is a gigabit NIC with a hostname backup2. The secondary interface is soley for backup purposes. I'm having difficulties trying to figure out how the users within OmniBack should be setup so that I can direct the traffic over the secondary interface. If I use backup2, the backup seems to complain about the user not being valid. The backup works just fine if I use the primary interface.

The backups fails with the following info:

SAP Backup Specification
---------------------------------------
Hostname: backup2
Ownership: twiadm
Group: sapsys
Host: backup2

OmniBack II Users
---------------------------
Host User Name Group
---------------------------------------------------------
backup2 oratwi sapsys
backup2 oratwi dba
backup2 twiadm sapsys

With this configuration, I get the following error:

BR279E Return code from '/usr/sap/TWI/SYS/exe/run/backint -u TWI -f backup -i /oracle/TWI/sapbackup/.bddeqbak.lst -t file_online -c': 2

.
.
.

[Warning] From: brbackup@twidev "TWI" Time: 07/25/00 01:01:07
OB2/SAP integration finished with exit status 5.

If I change the hosts in the user database to twidev and the ownership remains backup2, the backup works fine but goes over th FDDI interface.

If anyone has some thoughts on how to get this backup to successfully complete over the gigabit (secondary NIC), I would would greatly appreciate it.

Thanks,
Jason Heideloff
Honored Contributor
Joseph T. Wyckoff
Posts: 2,722
Registered: ‎05-31-2000
Message 2 of 2 (256 Views)

Re: OmniBack (OB II) v. 3.10 and SAP Backups over secondary NIC

The secondary nic on each machine has presumably a unique ip address.

In addition to that it should have a unique short and long/fqdn name as if it were on a completely new server.

Presumably the machine was imported into the Omniback cell using the PRIMARY network card name/address - this is the right way to do it, if possible.

Once this is done, you should tell Omniback that this name is actually an alias for a server it already knows about - you IMPORT the NIC as a new server - BUT you check the VIRTUAL SERVER check box. An entry is added to the cell_info file.

This should remove a license issue, and (I think) help with the user not allowed problem. If nothing else it will make the solution more rational and predictable, if name resolution is consistent.

Routing is largely determined by which names (PLURAL and therefore IP addresses) are used, and by parts of TCP/IP that Omniback has no control of.

If your tape drives are on a machine with multiple network cards, you will probaably want to create multiple instances of each tape drive - tape1_nic1, tape1_nic2 and so forth - the difference being the HOSTNAME.

If you are backing up a server with multiple nics, in the backup session, refer to it by the name of the NIC for the backup network.

Good Luck.
Omniback and NT problems? double check name resolution, DNS/HOSTS...
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.