TERRA CLOUD Backup and Satellite

The TERRA CLOUD Backup and TERRA CLOUD Satellite checks monitor WORTMANN's TERRA CLOUD Backup. TERRA CLOUD Backup reads the status files that the backup agent leaves behind on a protected machine after every run and evaluates each job's last result, backup age, and reported errors and warnings. TERRA CLOUD Satellite asks a satellite for its replication status over HTTPS and evaluates its services, the free space on drive S, and the age of the replicated backup jobs. Neither check signs in to the TERRA CLOUD portal — octoja only reads what your TERRA CLOUD components already produce, so the TERRA CLOUD side has to be in place first.

Pick the right check

This is where most setups go wrong. The two checks look at completely different things and are not interchangeable.

The most common mistake: assigning TERRA CLOUD Backup to a machine that has no local TERRA CLOUD Backup agent — an admin workstation, or the satellite VM — in the expectation that octoja will query the portal for it. It will not. The check reports Failure with "TERRA CLOUD Backup agent not found". The mirror-image mistake is rolling TERRA CLOUD Satellite out to every protected device: it reports the state of the satellite, so one check per satellite is enough.

Prerequisites

You need the Monitoring Check Management permission. Your administrator assigns permissions under Administration → Groups.

Neither check provisions anything in TERRA CLOUD. Each one reads state that the vendor side must already have produced, so the prerequisites below are the difference between a working check and one that reports nothing at all.

For the TERRA CLOUD Backup check

• The TERRA CLOUD Backup agent is installed on the machine, licensed, and registered against your vault. octoja neither installs nor registers it.
• The octoja agent is installed on the same device.
• At least one backup job has run at least once. The check parses the status file a completed run leaves behind — a freshly registered agent that has never run reports Warning with "No backup jobs found under …".
• You know which agent type protects the machine. The classic Windows Agent keeps one folder per job below its agent directory; the Hyper-V Agent Management keeps one status file per VM below its own data folder. octoja detects which of the two layouts it found, but you have to point it at the right directory — see the steps below.

For the TERRA CLOUD Satellite check

• A running TERRA CLOUD Backup Satellite whose backup storage sits on drive S:. The check evaluates the drive with the letter S; if there is no such drive, storage is reported as critical.
• The satellite is reachable over HTTPS (TCP 443) from the device you assign the check to. If the satellite sits in a different network segment, the firewall rule has to exist before the check can return anything.
• The satellite's replication status document is served without authentication. octoja sends a plain request to https://<satellite-address>/replication/backupstatus/ and sends no credentials with it — a login prompt on that path means the check cannot read the status.
• A self-signed certificate is fine. The check deliberately does not validate the satellite's certificate, so you do not need a trusted certificate just for monitoring.

Verify before you assign. On the device that will run the check, open https://<satellite-address>/replication/backupstatus/ in a browser. You should get an XML document whose root element is satellitestatus. Anything else — a login prompt, a 404, a refused connection, a certificate wall you cannot get past — is a TERRA CLOUD-side item to sort out (firewall rule, satellite configuration, or WORTMANN support) before octoja can help.

Steps

Set up the TERRA CLOUD Backup check

1. Go to Devices and open the protected machine — or, for virtual machines protected by the Hyper-V Agent, the Hyper-V host.
2. Click the Checks tab → Add Check → TERRA CLOUD Backup.
3. Set Agent directory. The default C:\Program Files\TERRA Cloud Backup\Agent is correct for the classic Windows Agent. On a Hyper-V host protected by the Hyper-V Agent, change it to the Hyper-V Agent Management data folder — C:\Program Files\TERRA CLOUD Backup\Hyper-V Agent Management\Data\Hyper-V, which holds one status file per VM.
4. If backups do not run every night, list the weekdays under Expected backup days — using the English names such as Monday that the field suggests — and give the schedule some slack with Grace period (hours). octoja then only flags a missing backup once an expected day has fully elapsed plus the grace period, and never raises an age alert on a day no backup was scheduled.
5. Use Job filter if you only want to watch some of the jobs on this machine — wildcards are allowed, an empty field evaluates all of them.
6. Click Add Check.

Set up the TERRA CLOUD Satellite check

1. Go to Devices and open one device that can reach the satellite — an on-site server is a good choice, and the satellite itself works too.
2. Click the Checks tab → Add Check → TERRA CLOUD Satellite.
3. Enter the satellite's IP address or hostname in Satellite address (required). Enter the address only — not a full URL. octoja adds the protocol and the status path itself.
4. Click Add Check.

The first result appears in the device's Checks tab shortly after the agent picks the check up; after that it runs on its interval.

Settings

TERRA CLOUD Backup

Two field interactions are worth knowing, because they are easy to trip over:

• As soon as Expected backup days is filled in, staleness is judged per expected day and Maximum backup age (hours) no longer decides it. Leave the days empty if you want the plain age threshold instead.
• Warn on job warnings/errors only has an effect for the classic Windows Agent. The per-VM status files written by the Hyper-V Agent carry no error or warning counts, so Hyper-V jobs are judged on their result and their age alone.

TERRA CLOUD Satellite

There are no other settings. The thresholds are fixed.

Results

TERRA CLOUD Backup

Each job is evaluated on its own. The worst job result becomes the check status.

When a job is overdue:

• Without Expected backup days: the last backup is older than Maximum backup age (hours). An age exactly equal to the threshold is not yet overdue.
• With Expected backup days: the backup for an expected day is due by midnight at the end of that day plus Grace period (hours). If the last backup is older than the most recent expected day whose deadline has passed, the job is overdue. Days without an expected backup never raise an age alert. The device's local time applies.

A backup that is too old or overdue raises at most a warning, never a critical status. Only a failed run makes the check critical. If the time of the last backup cannot be read, that job's age is not evaluated.

TERRA CLOUD Satellite

The check evaluates three areas. The worst area determines the check status.

A job's backup time is the newest time across all of its safesets.

Collected metrics

TERRA CLOUD Backup

For each job, the result shows:

• Job name (folder name or VM name) and last result
• Time and age of the last backup, and whether the job is overdue
• Number of reported errors and warnings, and the original size of the backup
• Whether ransomware detection is enabled for the job (classic Windows Agent only). This is information only and does not change the status

TERRA CLOUD Satellite

• Number of services, and the services that are not running with their state
• Size, free space, and free percentage of drive S
• Per backup job: job name, agent, time and age of the newest backup, and the result

Notes

• The agent directory layout is detected automatically: if the Agent directory contains job folders with Windows Agent status files, those are evaluated; otherwise the check looks for the Hyper-V Agent Management's per-VM status files.
• The Hyper-V Agent Management status files carry no error or warning counts and no ransomware detection information. Hyper-V jobs are therefore judged on result and age only.

When a check does not return anything

Tips

• For a fleet of protected machines, roll the backup check out with config packages instead of adding it device by device. Use two packages, though — the agent directory differs between Windows Agent machines and Hyper-V hosts.
• The satellite check stays a single check per satellite even when you use config packages. Assign it to one stable on-site device rather than to a rule that matches many.
• If a machine runs jobs on very different schedules — a nightly file backup and a weekly archive run — add one TERRA CLOUD Backup check per cadence and narrow each with the Job filter, rather than stretching one age threshold to cover both.

See also: Checks · Assign checks with config packages · Set up alerts for a check