backup remote agents

Don't try connecting to the RA server as you connect to an agent. It is not a substitute for an agent, it is a different piece of the software. To work with RA servers you need to write little JAL scripts to establish the connection and tell the server what to do. Please see 24x7 Linux & UNIX RA Server Reference manual for details. Same commands work on Windows systems, with same parameters and virtually the same behavior.

An example script copied from RARunAndWait topic is below

RAConnect "123.45.789.01", 1096, "user", "password"
// move remote files
Dim process_id, number
Dim output, string
RARunAndWait "mv /trade/ftp/*.dat /trade/backup", 0, process_id, output
// now, files from the remote directory are backed, let's copy new file
RARunAndWait "do_ftp", 0, process_id, output
// and finally start the load process
RARun "do_load", process_id
// close connection
RADisconnect

Note that the local "output" variable contains the standard and error output of the remote process and the "process_id" variable refers to the system id of the remote process.

To test this first time try something really simple,

RAConnect "myserver", 1096, "user", "password"
Dim process_id, number
RARun "notepad.exe", process_id
RADisconnect

Might be username and pwd related? When I try to use the raconnect statement in a jal script, I don't have a uname and pwd to specify so it fails. How do I specify a username and password in the remote agent or is it windows auth?

oic, yes it is windows auth.

Yes, it is either a local Windows system user or a valid network user. For local users, enter their names in scripts as .\\user, for network users, enter them as domain\\user. The user authentication is performed by the Windows server. The process is also created in the context of the authenticated user account, sort of a remote session.

Is there any way to cloak the password in the JAL script? It shows up in clear text

Or use current logged on credentials?

1. you can password protects the job definition using File/Protect Job menu. Use a different password for the job.
2. Use a variable instead of a hard-coded password, and populate that variable in run-time getting the required password value from some secure place.

You cannot use "current user" because for every connection, the server creates a separate remote session specifically for the connected user.