The Sefthy Agent

The Sefthy Agent is a binary you install on the server you want to protect. It does three things. It prepares the server for Disaster Recovery, it reports to the Console whether a restore would really start, and it verifies the application services after a restore.

In the Console the backup method carries the same name, because it is this binary that installs and authenticates the backup client on the server.

Installation

From the Console you generate the install command, with the token already in it. You run it on the server once.

sefthy-agent setup --console https://console.sefthy.cloud --token <token>

The binary is the same for Windows and Linux and runs from Windows Server 2008 R2 onward. It uses outbound HTTPS only, so you never open a port on the customer server. The commands it receives are typed, never an arbitrary shell.

Detected data

As soon as it connects, the agent reads CPU, RAM, network cards, BIOS or UEFI boot mode and MAC addresses, then installs and authenticates the backup client and adds the network drivers the restore needs.

The DR wizard stops being a form to fill in and becomes a list of values to confirm.

Connector discovery

The agent looks for the Sefthy Connector on the LAN with mDNS and broadcast, across every VLAN the server can see. When it finds one, it proposes the match in the wizard with the connector serial and the operator confirms with one click.

When the connector is not reachable at layer 2, for example because it sits in another segment, manual pairing from the Console is still available.

Health and readiness

Every five minutes the agent sends a report on the state of the server.

• Connector reachable from the LAN
• VSS service state
• Network drivers installed
• Free disk space
• System clock
• Pending reboots
• DNS resolution

When the network cards on the server no longer match the ones recorded in the DR plan, the agent flags the drift and proposes the realignment. You accept or reject it, nothing changes without your confirmation.

Service checks after a restore

For each DR you can define up to ten application checks. A file that must exist, a TCP port that must listen, a service that must be running, a URL that must answer.

The checks run inside the restored VM during the automatic test, and with Run now you can also run them on the production server to verify they are written correctly. The outcome lands in the test report and in the weekly PDF, kept separate from the boot and network verdict.

The same checks act as readiness gates in orchestration. Start the database, wait for port 1433 to answer, then start the web server.