Backrest vs Zerobyte vs Rested: which restic control plane fits?

All three put a web interface around restic concepts such as repositories, schedules, retention, snapshots, logs, and restores. A feature checklist can therefore make them look interchangeable. They are not. Backrest instances run close to their visible paths and can synchronize operation history and repository configuration, Zerobyte acts as a self-hosted control plane for defined volumes, and Rested sends work to agents enrolled on Linux servers.

That data-access choice shapes security, networking, permission fidelity, failure recovery, and the amount of infrastructure the customer must maintain. Decide where the source is read and where management state lives before comparing notification badges or the number of supported storage logos.

Backrest documents a standalone binary and container image with restic as its primary dependency. It can create or import repositories, schedule snapshots and health operations, browse files, perform restores, send notifications through several services, and call command hooks around a backup. Advanced operators can still use the restic CLI against the repository.

This design is straightforward when Backrest runs on the machine being protected or on a NAS where source paths are already mounted. For several machines, Backrest documents a server-and-client synchronization model: clients send operation history and can receive shared repository configuration, while the individual instances still perform their local work. The project gives you a capable interface, not a hosted service, so availability, authentication exposure, updates, configuration backup, pairing, and host monitoring remain customer responsibilities.

Zerobyte models a backup job as a source volume, repository, schedule, and retention policy. Its volume documentation covers local directories and remote sources including NFS, SMB, WebDAV, SFTP, and rclone. The service can browse volumes and snapshots, stream run progress, restore to a path, download selected data, mirror repositories, and send notifications.

Central mounting is powerful, particularly for NAS shares and remote filesystems, but it changes the recovery boundary. Network reachability, mounted permissions, translated metadata, and the credentials held by the central service all matter. Zerobyte's documentation explicitly warns that remote volumes can expose translated ownership and ACL information rather than the source system's exact model.

Rested's management interface is hosted, while backup work executes on an enrolled Linux server. The current product covers filesystem paths, PostgreSQL and the MySQL/MariaDB family alongside MongoDB and Redis, writing encrypted standard restic repositories to customer-owned S3-compatible object storage.

The agent model avoids mounting every server into one central backup container and keeps file access on the protected host. It introduces a different dependency: each host must remain enrolled and able to reach the control plane and storage at schedule time. Rested also supports a narrower destination family than tools that expose restic's entire backend set.

Backrest offers pre- and post-backup command hooks. Zerobyte documents pre- and post-backup HTTP webhooks and explains how their failures affect the run. These are useful integration primitives. They can coordinate a database dump, application pause, or external snapshot when the operator supplies and maintains the implementation.

A guided database source has a different promise: the product owns supported preparation and recovery semantics for that engine and source type. Even then, a buyer should test version compatibility, permissions, empty databases, all-database scope, partial failure, cleanup, and restore behavior. The distinction is maintained product behavior versus an extension point—not whether a hook is technically capable of starting a dump.

Backrest and Zerobyte both document scheduled retention and repository health operations. Their notification coverage is broader than a single local cron email, and Zerobyte exposes current and next run information. Rested centralizes run state across enrolled servers and keeps retention and restores beside repository history.

For any product, inspect missing-run behavior separately from failed-run behavior. A dead host cannot report its own failure, and a vanished mount can produce a misleadingly small but technically successful snapshot. Repository checks help find structural damage; they do not prove application consistency, source coverage, or recovery time. Those alerts need external expectations and restore evidence.

Each option relies on restic repositories, but operational independence is more than format compatibility. Record the backend URL, credentials, repository password, expected host or path filters, and the restic version used. Put those recovery facts somewhere that does not depend on the dashboard being available.

On a clean rescue machine, list snapshots and restore representative data without the normal interface. For a self-hosted control plane, separately rebuild its configuration and prove schedules return without duplicating destructive maintenance. For a hosted control plane, prove the repository can still be read directly. Independence should be demonstrated, not inferred from an open-source logo.

Use Backrest when a lightweight service near the data is the simplest truthful architecture and your operator already owns the host. Use Zerobyte when you want to self-host a richer central system for local, NAS, and remote volumes, and you understand the permissions and availability of those mounts.

Use Rested when several Linux servers or supported databases need one hosted operating view and S3-compatible storage fits the recovery plan. If none of those models matches, direct restic, Kopia, or a broader managed service may be a better choice. A product that does less in the right failure domain is safer than a longer checklist deployed where it cannot see or recover the data correctly.