Oracle RAC 10 - Backup Exec agent

Oracle RAC Solution · Previous: Database creation and user environments · Next: Backup Exec server and RAC backup

The cluster was backed up with Symantec Backup Exec 15: a Windows server, mng-backupsrv01, and an agent on every Linux machine. This part is the Linux side: installing the agent on both nodes, giving it a group and an account, switching on its log, telling it where the Backup Exec server is and which Oracle instance lives on the node. The agent is the only piece of the backup that runs on the nodes, and both the operating system backup and the database backup go through it, so everything the server does in the next part depends on what was set here.

What was installed

The agent is called RALUS in its own file names (the installer, the package, the configuration directory). Everything here was done on both nodes as root, unless a node is named.

The parts on one node and what they talk to:

flowchart LR
  subgraph n1["oradb01"]
    init["/etc/init.d/VRTSralus.init"]
    ber["/opt/VRTSralus/bin/beremote"]
    cfg["/etc/VRTSralus/ralus.cfg"]
    tab["/etc/VRTSralus/beoratab"]
    log["/var/VRTSralus, log directory"]
    ac["AgentConfig"]
    grp["group beoper, GID 666: be, root, oracle"]
    asm["ASM instance +ASM1"]
    db["database instance clsopdb1"]
  end
  srv["mng-backupsrv01-bck.example.net, 10.30.30.14"]
  init -- "start, with --log-file-auto" --> ber
  cfg -- "debug levels, server list, advertising" --> ber
  tab -- "instances and their homes" --> ber
  ber -- "beremote.service.log and debug logs" --> log
  ac -- "system account oracle, instance account sys" --> ber
  ber -- "sys as SYSDBA" --> db
  tab -.- asm
  ber -- "advertises the node, Agent Directory List 1" --> srv
  ber -- "Oracle operations, port 5633" --> srv
  grp -. "accounts the server may log on with" .- ber

Unpacking and installralus

The medium was unpacked under /data/install, the directory that already held the Oracle installation files, and the ISO image inside it was mounted through a loop device. The agent archive was copied from the image to the local disk and unpacked there. The 64-bit installer is in the directory RALUS64; on a 32-bit system it would be RALUSx86.

$ mkdir /media/iso
$ cd /data/install
$ unzip ./Backup_Exec_15_14.2_FP5_MultiPlatforms_Multilingual.zip
$ mount ./Backup_Exec_15_14.2_FP5_MultiPlatforms_Multilingual.iso /media/iso -t iso9660 -o loop
$ cp /media/iso/LinuxMac/RALUS_RMALS_RAMS-1180.3142.tar.gz /data/install
$ cd /data/install
$ tar -xvf ./RALUS_RMALS_RAMS-1180.3142.tar.gz
$ cd /data/install/RALUS64
$ ./installralus

installralus is a text dialogue. Most of it is pressing Return; four questions matter, and two of them were answered with Return as well.

The last question, whether to start the agent after the installation, was answered with the default y. The installer then says what comes next: to establish trust between the Backup Exec server and the agent, the agent computer has to be added to the server's list of servers. The whole dialogue, with the dotted filler lines of the output trimmed, is a Config document: installralus session.

The notes hold the dialogue of oradb01 only. The agent was installed on both nodes (the notes' header says "all Oracle RAC servers", and the Backup Exec server later lists ORADB02-BCK), so the second run was the same with the other name; it is not recorded.

The group beoper and the account be

Backup Exec logs on to a Linux agent with an account of that machine, and the installer says which: to perform backups there must be a group beoper with root account privileges. After the installation the group was checked.

$ cat /etc/group | grep beoper

beoper:!:666:root,oracle

The installer added root. The line also lists oracle, and no step in the notes adds it: either the step is missing or the output was captured later than its place in the notes suggests. I cannot tell which.

The account with which the Backup Exec server reaches the Linux servers is a local account of its own, be. It was created and put into beoper. This was done in YaST (Security and Users, User and Group Management), not on the command line, so there is no command to show. The second check shows the result.

beoper:!:666:be,root,oracle

So three accounts can be used by the Backup Exec server on a node: be for the operating system backup, oracle for the Oracle operations, and root, which was never given to the server.

Switching on the log

The control script starts beremote and sends its standard output and error to one file. Logging proper is switched on with the argument --log-file-auto, with which the agent writes its log into its standard directory /var/VRTSralus. The argument was added in the start function of /etc/init.d/VRTSralus.init. The notes show the change as an original and a changed line.

# ORIGINAL
# /opt/VRTSralus/bin/beremote >/var/VRTSralus/beremote.service.log 2>/var/VRTSralus/beremote.service.log &

# CHANGED
/opt/VRTSralus/bin/beremote --log-file-auto >/var/VRTSralus/beremote.service.log 2>/var/VRTSralus/beremote.service.log &

This is an edit of a file that belongs to the package, so it is worth checking after any update of the agent whether the argument is still there.

ralus.cfg

The agent's configuration file is a flat list of key=value lines whose keys look like Windows registry paths, all under Software\Symantec\Backup Exec For Windows\Backup Exec\. The installer creates the file. Four keys were added or changed after the installation, and a fifth one later.

The server is named by its backup-network name on purpose. The Backup Exec server has two addresses, 10.30.40.14 on the management network and 10.30.30.14 on the backup network, and the backup was to stay on the second.

The notes also describe three keys that were looked at and not set: Advertise All, Advertising Disabled in its default state and Encoder. They are in the Config document together with the keys as set: ralus.cfg.

beoratab

To back up Oracle the agent needs to know which instances run on the node and where their homes are. It has a file of its own for that, in the format of /etc/oratab: /etc/VRTSralus/beoratab. The file was made by copying /etc/oratab, and the group beoper was given write access.

$ cp /etc/oratab /etc/VRTSralus/beoratab
$ chown root:beoper /etc/VRTSralus/beoratab
$ chmod g+rw /etc/VRTSralus/beoratab

The copy is not correct for a RAC node. In /etc/oratab the cluster agent enters the database by its name, clsopdb, and an instance on a RAC node is not called by the database name: it is clsopdb1 on oradb01 and clsopdb2 on oradb02. The Backup Exec agent takes the first field as the ORACLE_SID, so the line had to be corrected on each node by hand.

The ASM line (+ASM1, +ASM2) was already right. The file is a Config document: beoratab. The database is called clsopdb throughout the Backup Exec notes, while the installer answers and the srvctl output of the earlier parts say clsdb; the contradiction is described in the next part.

AgentConfig

The last tool is /opt/VRTSralus/bin/AgentConfig, a menu program run as root. It was run twice, once for each of the two things the agent needs to know.

First, "Configure database access": the system credentials for Oracle operations. This is the operating system account under which the agent runs the Oracle side of a backup, and it was oracle, the owner of the database home. The tool asked whether to use a custom port to connect to the Backup Exec server during Oracle operations; the answer was no, and the entry it then showed carries the port 5633.

     Entry 1
          ObjectName: DBAID
          Port: 5633
     Entry 2
          ObjectName: Machine
          HostUsername: oracle
          Port: 5633

Then, "Configure Oracle instance information": the instance to protect. The tool offered one entry, clsopdb1, the name in the corrected line of beoratab. It asked for a SYSDBA account and its password, for the Backup Exec server (again the backup-network name), for a recovery catalog (none) and for a customized job template (none).

The notes say why sys: this part of the configuration is what gives access to the RAC instances, so the Oracle account sys has to be used. A dedicated database account for the backup was created too, and what became of it is in the next part. Both dialogues are a Config document: AgentConfig sessions. The notes show them for oradb01; on oradb02 the instance offered would be clsopdb2, and that run is not recorded.

Restart, and the advertising that had to go

After the server side was prepared (the accounts and the Oracle server list of the next part), the agent was restarted on both nodes as root.

$ /etc/init.d/VRTSralus.init restart

On restart the agent publishes itself to the server named in Agent Directory List 1, and the nodes appeared in the Backup Exec console on their own. They appeared twice, under the name with -BCK and under the name without it, and the entries without -BCK were not wanted and were removed on the server. At the next restart the agent published them again. The notes give a second reason as well: with advertising on, logging in to the database from the Backup Exec server was troublesome or did not work at all, and the list of database objects (tablespaces, archive logs) could not even be printed. So advertising was switched off in /etc/VRTSralus/ralus.cfg on both nodes and the agent restarted once more.

Software\Symantec\Backup Exec For Windows\Backup Exec\Engine\Agents\Advertising Disabled=1

From then on the server knows the nodes only because they were added there by hand. This is the opposite of what the installer suggests, and it was the state the configuration was left in.

Checked against Backup Exec 25.1

Backup Exec 15 reached its End of Support Life on 7 November 2019. The product has changed hands since: Symantec completed the sale of Veritas in January 2016, so it was already a Veritas product when I installed it under the Symantec name; in December 2024 it went to Arctera and in December 2025 to Cloud Software Group. The current release is 25.1 of 6 October 2025, and the agent side has changed remarkably little.

The four debug and directory keys of ralus.cfg are still documented with the same meaning; the details are in the Config document.

What the notes do not hold

• The installation and the AgentConfig run on oradb02.
• The creation of the account be beyond the YaST menu path: its UID, home directory and shell are not recorded.
• The step that put oracle into beoper.
• The whole ralus.cfg as the installer created it; only the lines that were added or changed are in the notes.
• Any firewall setting. The only port the notes name is 5633, in the AgentConfig output.
• A log excerpt showing what --log-file-auto and the debug keys produced.