Endpoint backup overview

Endpoint backup protects servers and client machines, such as laptops and desktops, file by file. A small program, the Restow agent, runs on the machine, drives restic and sends the backup to your Restow instance over HTTPS. Backups end up in the storage target of the tenant, like every other backup in Restow.

This section uses the word endpoint for such a machine. The web interface says “machine” in places. An endpoint has one of two profiles: Server or Client.

What you get

File-based backups with restic 0.19.1. Deduplicated, compressed and encrypted. Single files and folders are backed up and restored.
One repository per endpoint. Each endpoint has its own restic repository with its own password. The password is generated by the server and stored there, encrypted with the tenant key.
Append-only. The agent can add backups. It can never delete or overwrite one. The instance enforces this, not the agent. Retention, pruning and integrity checks run on the Restow server only.
Outbound only. The agent opens no port. It talks to your Restow instance over HTTPS and to nothing else.
Restores never overwrite. A restore goes into a new folder on the machine, or you download files as a ZIP from the web interface.
Restore tests. Restow reads sample files of the newest backup back and compares their SHA-256 hashes. The result feeds Recovery readiness like mailboxes and OneDrives do.
Alerts for silent servers, clients without a recent good backup, failed backups, failed restores and failed restore tests or repository checks.
Pre and post commands (hooks) around each backup, for example to dump a database. See Profiles, schedule and hooks.

Supported systems

System	Supported in the 0.1.0 beta
Linux	With systemd, on x86_64 and aarch64. The binaries are static and run on any distribution with systemd.
macOS	macOS 13 (Ventura) or newer, on Intel and Apple Silicon.
Windows	Planned, not part of 0.1.0. There is no Windows build, installer or service. The web interface shows Windows as “Planned” and does not let you choose it. See the roadmap.

How it fits together

In the web interface you create a server or client. Restow creates a one-time install command.
You run the command on the machine. The script downloads the agent and restic from your Restow instance, verifies them, installs a service and enrolls the machine. See Install on Linux and macOS.
The agent contacts your instance every 5 minutes (a “heartbeat”) and receives tasks, fetches its configuration when it needs it, and starts backups on its schedule. The instance never connects to the machine: tasks such as “back up now” or “restore” travel in the answer to the heartbeat.
The backup data goes to a restic repository that your instance exposes to that one agent in append-only mode. The repository lies in the tenant’s primary storage target, below endpoints/<endpoint id>/.
The server applies retention, checks the repository and runs restore tests.

Where endpoints appear

The section Server/endpoint backup in the sidebar, with the pages Agents (every endpoint), Servers and Clients. Only tenant administrators and provider administrators see it.
The Recovery readiness overview, in a section Servers and clients. Endpoints count in the tenant summary too.
The integration API: GET /api/v1/endpoints lists them, and the recovery readiness data carries an endpoints field. A failed endpoint run also triggers the job.failed webhook. See Integration API.

Alerts

Endpoint backup uses the same alert rules, recipients and channels (bell, email, webhook) as every other job. See Alerts and reports.

Event	When it fires
Server or client not reporting (`endpoint.stale`)	A server has not been in contact for more than 2 hours. A client has had no good backup for 7 days. Clients never count as silent, because a laptop is off at night. Both limits can be set per endpoint.
Backup failed (`backup.failed`)	A backup run failed. This includes a run whose agent disappeared and that was closed after 6 hours without progress.
Restore failed (`restore.failed`)	A restore run on the endpoint failed.
Restore check failed (`verify.red`)	A restore test failed. `verify.recovered` follows when a later test passes.
Storage damage found (`scrub.corrupt`)	The repository check found damage.

An existing rule for backup failed and restore check failed therefore covers endpoints without a change. A run that was interrupted because the agent restarted (an update, a reboot) is not a failure: it continues by itself and raises no alert and no job.failed webhook.

Retention and repository checks

Retention runs on the server once a day for every active endpoint. The default keeps 30 daily, 12 weekly and 12 monthly snapshots. You can change the numbers per endpoint. Lowering a number permanently removes older snapshots at the next retention run. A revoked endpoint is no longer pruned.
Repository check runs once a week for every endpoint. It runs restic check on one twentieth of the stored data, in a fixed order, so the whole repository is read over roughly five months. Damage turns the endpoint Not restorable and raises scrub.corrupt.
Restore tests run after every new good backup. See Restore.

What it is not

Not a disk image. There are no images and no bare-metal restore. Restoring a whole machine means reinstalling the operating system and restoring the files.
Not for Windows yet. Windows is planned.
No snapshots of the file system yet. LVM, ZFS, btrfs and APFS snapshots are not used. Consistency comes from optional hooks.

Known limits

No mTLS yet. Each agent authenticates with its own secret over HTTPS. See Security model.
No LVM, ZFS or btrfs snapshots, and no APFS integration. Files that change while they are read can end up inconsistent in a snapshot.
File-based only: no disk images, no bare-metal restore.
No Windows in 0.1.0.
Agent updates are not signed. The install scripts and self-updates check SHA-256 checksums from the same instance.
Linux without systemd is not supported by the installer and the service commands.
Whether the machine is on battery is detected on a best-effort basis, and a running backup is not stopped when the charger is unplugged.
A machine runs one backup, restore or restore test at a time. Further tasks queue.
There is no deletion of an endpoint’s repository yet. You can revoke an endpoint, and its data stays in storage.
The move of a tenant’s primary storage target copies the tenant’s data but not the endpoints/ folder. Copy that folder by hand before you change the primary target.
As of the 0.1.0 beta, the project’s tests ran the agent on Linux (Debian, arm64, in Docker) and natively on macOS 26 (Apple Silicon). The amd64 builds were cross-compiled and checked but not run there, and the systemd unit and the LaunchDaemon were not started on a real systemd or launchd in that environment. Do a first install on a test machine.