Arcserve UDP

The Arcserve UDP check reads the Arcserve UDP console database and reports the backup state of every protected node in one place: how old the newest recovery point is, how many recovery points exist, the result of the last backup job, and how much room is left at the backup destination. One check covers your whole UDP estate — you do not install anything on the protected nodes themselves. The check runs on Windows only, every 60 minutes. That interval is fixed by the check and cannot be changed in the editor — which suits backup monitoring, because backup state changes on the scale of a backup window rather than a minute.

Because the check talks to SQL Server rather than to Arcserve, almost all of the setup work is database-side: finding the right SQL instance and giving the check read access.

Prerequisites

• Arcserve UDP Console installed on a Windows server
• The octoja agent installed on a Windows device — the Console server itself is the usual choice, but the check needs no Arcserve role on the device it runs on. It is published for Windows only, so a Linux or macOS agent never receives it
• Network access from the agent to the SQL Server instance holding the console database
• A login that can read three tables in that database (created in Step 2)
• An octoja account with the Monitoring Check Management permission — it is required to add a check to a device

Install the agent on the Console server

This is the decision that costs the most time with this check, so make it first. What the check needs is a network path to the SQL Server instance that holds the arcserveUDP database and a login that can read from it — it does not detect or require any Arcserve role on the device it runs on. In practice the machine hosting the Arcserve UDP Console is the right place for it, because the shipped default localhost\ARCSERVE_APP points at the device the check runs on, and on a stock installation that instance lives on the Console. Devices that look like candidates but are not:

• a protected node. Nodes run a UDP agent, but the console database is not there
• a Recovery Point Server that is not also the Console, if you have split those roles across machines — same reason
• any device with no network path to the SQL instance, if your console database was moved onto a separate SQL Server

If the console database does live on a separate SQL Server, you do not need an agent on that database server. Keep the check on the Console host (or any Windows device that can reach the instance) and point it at the database by hostname.

Steps

Step 1 – Find the SQL instance

The check ships with the values a stock Arcserve UDP installation produces: instance localhost\ARCSERVE_APP, database arcserveUDP. Many installs need no change at all here — but verify rather than assume, because a wrong instance name means the check never reaches the database at all. If it does go wrong, the result shows the raw SQL Server error text, so a wrong instance name and a permission problem read differently — the Troubleshooting table below tells them apart.

On the Console server, list the SQL Server instances that are installed:

Get-Service 'MSSQL*' | Select-Object Name, DisplayName, Status

A named instance runs as a service called MSSQL$<instance>, so the part after the $ is the instance name — seeing MSSQL$ARCSERVE_APP confirms the check's default is right. The unnamed default instance is the exception: its service is called just MSSQLSERVER, with no $ and no instance name.

Then confirm the database name on that instance. Arcserve calls it arcserveUDP:

SELECT name FROM sys.databases ORDER BY name;

A named instance on another server. To reach SQLHOST\INSTANCE, the client has to resolve the instance to a TCP port, which normally requires the SQL Server Browser service to be running on the database host. If it is not running and you cannot start it, enter the instance as host, comma, port — for example SQLHOST,1433 — and skip the lookup entirely.

Step 2 – Give the check read access

The check only ever reads. It runs a single SELECT against three tables in the console database: dbo.as_edge_host, dbo.as_edge_host_d2dStatusInfo and dbo.as_edge_recovery_point_summary. It never writes, and it never touches the Arcserve configuration.

Pick one of the two options below and run the statements on the console instance with an account that can create logins (a SQL Server sysadmin).

Option A — Windows authentication

If you leave SQL username and SQL password empty, the check connects using the identity of the octoja agent service. On Windows that service runs as LocalSystem, which SQL Server sees as the login NT AUTHORITY\SYSTEM. Nothing has to be stored in octoja, and there is no password to rotate.

USE master;
IF SUSER_ID('NT AUTHORITY\SYSTEM') IS NULL
    CREATE LOGIN [NT AUTHORITY\SYSTEM] FROM WINDOWS;
GO

USE arcserveUDP;
IF USER_ID('NT AUTHORITY\SYSTEM') IS NULL
    CREATE USER [NT AUTHORITY\SYSTEM] FOR LOGIN [NT AUTHORITY\SYSTEM];
GO

GRANT SELECT ON dbo.as_edge_host TO [NT AUTHORITY\SYSTEM];
GRANT SELECT ON dbo.as_edge_host_d2dStatusInfo TO [NT AUTHORITY\SYSTEM];
GRANT SELECT ON dbo.as_edge_recovery_point_summary TO [NT AUTHORITY\SYSTEM];

This is the simplest option when the agent and SQL Server are on the same machine. It gets awkward when they are not: across the network LocalSystem authenticates as the computer account (DOMAIN\CONSOLESERVER$), so you would have to grant that account instead. For a remote console database, use Option B.

Option B — a dedicated SQL login

Create a login that exists only for octoja. This works regardless of where the database lives, and you can rotate the password without touching the agent.

USE master;
CREATE LOGIN octoja_udp_monitor
    WITH PASSWORD = N'ReplaceThisWithAStrongPassword', CHECK_POLICY = ON;
GO

USE arcserveUDP;
CREATE USER octoja_udp_monitor FOR LOGIN octoja_udp_monitor;
GO

GRANT SELECT ON dbo.as_edge_host TO octoja_udp_monitor;
GRANT SELECT ON dbo.as_edge_host_d2dStatusInfo TO octoja_udp_monitor;
GRANT SELECT ON dbo.as_edge_recovery_point_summary TO octoja_udp_monitor;

A SQL login only works if the instance accepts SQL Server authentication, that is, if it runs in mixed mode. If the check reports "Login failed for user" while the same instance is happy to let you in with a Windows account, mixed mode is the thing to check.

Why not just db_datareader? Adding the login to that role is one line shorter and does work — but it grants read on every table in the console database, including node and destination configuration. The three grants above are exactly what the check reads and nothing more.

Step 3 – Add the check

1. Make sure the octoja agent is installed on the Arcserve UDP Console server.
2. Go to Devices and open that server.
3. Click the Checks tab → Add Check → Arcserve UDP.
4. Leave Nodes to monitor empty to watch every node the console knows about. That is the right setting for most installations — new nodes are picked up automatically. Only fill it in when you want a subset.
5. Adjust Backup age warning (hours), Backup age critical (hours) and Destination free space warning (in GB) if your backup windows differ from the defaults (26, 50 and 50).
6. Turn on Show advanced options and enter the connection details you established above.
7. Click Add Check.

After the first check interval, the result appears in the device's Checks tab: a list of current problems, followed by one row per node showing the age of its newest recovery point, its recovery-point count, and free space at its destination.

Settings

Both age values are measured against the age of a node's newest recovery point — Warning at the first, Critical at the second. When no recovery point is recorded, the age falls back to the last backup start time — so a job that starts and never produces a restore point still ages out.

Results

Each monitored node is evaluated on its own, and the worst node result becomes the status of the check.

Troubleshooting

Tips

• Set Destination free space warning (in GB) to 0 to switch that alert off. That is worth doing for deduplicating or cloud destinations, where reported free space is not a meaningful number.
• If you run more than one UDP Console, install the agent on each Console server and add one check per console. To roll the same settings out to all of them at once, put the check in a config package instead of adding it device by device.
• Keep the login read-only. The check has no write path, so a broader grant buys nothing and widens what a leaked credential exposes.

See also: Checks · Assign checks with config packages

FAQ