The copy that survives the bad day.
Snapshots protect you from yourself. Replication protects you from a host. DR Manager is the layer under both — encrypted restic repositories on an appliance that lives outside the fleet it protects, and stays closed until a host proves who it is.
QEMU / KVM
Cloud Hypervisor
OpenZFS
WireGuard
LeilFS
Prometheus
Ubuntu
Rocky Linux
GoThree layers, and only one of them survives losing the rack.
Each answers a different question. Running the first two and calling it a backup strategy is the common mistake.
zfs send to another machine. The guest comes back on a neighbour with minutes of data loss rather than hours — as long as the neighbour is still standing.Retention is a tier you pick, not a spreadsheet you maintain.
Six tiers ship with the appliance. Applying one copies its counts onto the resource, so editing a tier later never silently rewrites machines that already have a policy.
Retention
Applies the tier and prunes what falls outside it. The log records the snapshots kept and restic's reason for keeping each one, so a deletion is never unexplained.
Integrity check
Reads the repository back and verifies it. A backup you have never read is a hypothesis, and this is the job that turns it into a fact before you need it to be one.
Cloud sync
Mirrors the repository, already encrypted, into an archive target that is never mounted. A second off-site copy for the machines that warrant one.
Every repository is closed until a host knocks.
Ordinary backup systems keep long-lived credentials on every machine they back up. Take one host and you can read — or delete — everything. DR Manager inverts that.
- name
- uuid
- repo
- credential
- the credential maps to one repo
- the uuid matches
- the name matches
- the repo name matches
- the resource is not disabled
What that buys you
- Hosts hold no encryption keys. The restic password comes back with the knock, is written to a private temporary file for the length of the run, and goes with it. There is nothing on the host to steal.
- A compromised host reaches one repository. Its own. Not the fleet's — and only while it is mid-transfer.
- The ingress is append-only. A machine that has been taken over cannot erase its own history to cover the tracks. Deleting anything is the appliance's job, on the appliance's schedule.
- Nothing is provisioned out of band. Each guest carries its own DR address and credential in its own config. No key distribution, no rotation across the estate.
Backups that never stop the guest.
A running machine is a moving target, so nothing is read from it. The backup reads a frozen clone instead.
- Snapshot
zfs snapshotA point-in-time snapshot of the guest, taken in milliseconds. - Clone
zfs cloneCloned to a temporary dataset and stamped as a copy, so nothing anywhere mistakes it for the guest or tries to start it. - Stream
restic backuprestic reads the clone and streams it through the door the knock opened. - Clean up
zfs destroyClone and snapshot are destroyed — including when the run failed partway.
Interrupted runs resume
A transfer that dies halfway leaves its clone in place, and the next run continues incrementally rather than starting the whole thing again. Over a slow link to another site, that is the difference between a backup that completes and one that never does.
Schedules build themselves
Enable DR on a guest and the scheduler grows a job for it — daily, weekly, monthly or yearly. There is no plan to regenerate and nothing to remember after adding a machine. Jobs run one at a time, so a fleet does not put a fleet of transfers on one host at once.
Replicas are skipped
A backup copy sitting on another host is not the machine. Backing it up would store the same data twice under two identities, so DR runs on primaries only.
The parts that touch your data are not ours.
DR Manager writes no cryptography and speaks no storage protocol. It runs restic and rclone — two of the most heavily exercised tools in their field — and its job is deciding who may run them, against what, and when.
restic
The repository. Everything about how your data is stored.
Content-defined chunking and deduplication, so the twentieth backup of a 40 GB guest is not the twentieth 40 GB. AES-256 encryption and authentication applied on the machine holding the data, before a byte leaves it — the appliance stores ciphertext it did not create and could not have created differently.
It runs on both sides, and the sides do not have the same powers. Hosts get init, backup and — under a separate short-lived grant — restore. Everything destructive or administrative, forget, prune, check, snapshots, ls, stats, only ever runs on the appliance.
rclone
The reach. Everything about where that storage physically is.
A repository does not have to live on the appliance's own disk. rclone mounts an S3 bucket or an SFTP directory as a filesystem, and repositories are created on it exactly as they would be locally — the ingress never learns the difference.
It also runs the archive tier: rclone sync mirrors a repository's already-encrypted files into a target that is never mounted and never hosts a live repository. rclone only ever runs on the appliance, which is the reason no host in your fleet holds an object-storage credential.
The repositories outlive us
They are ordinary restic repositories in restic's documented on-disk format. Point the restic binary at one with its password and you get your snapshots back, with no DR Manager involved and nothing of ours in the path. A backup system you cannot leave is not a backup system, and the exit here is a published CLI rather than a promise.
Versions are stated, not assumed
The appliance runs restic version and rclone version and prints what it found across the top of its own dashboard. When an operation fails, the log carries the tool's own output rather than a paraphrase of it — the thing you actually need at three in the morning.
A restore is a link, and it lands anywhere.
Authorisation is a short-lived capability URL issued for one snapshot of one resource — deliberately not tied to a destination, so you paste it into whichever machine has room.
$ hoster dr restore 'https://dr.example/restore/9f2c…#token=…' \
--parent-dataset zroot/vm-encrypted \
--name restore-drill --start
The token never reaches a server log
It rides in the URL fragment, which browsers and clients do not send. What is transmitted is the grant's id; the secret that redeems it stays client-side. Grants expire in an hour by default and can never be minted for longer than a day.
Invisible until it is real
The host claims the capability, restores into a hidden temporary dataset, validates that the expected configuration is present, and makes it visible with one atomic zfs rename. A half-restored guest never appears in inventory and nothing starts it by accident. A failed restore removes what it created.
Safe by default, exact on request
A restored guest is treated as a copy unless you say otherwise: new UUID, new addresses, regenerated cloud-init, and its DR schedule and replication settings dropped. That is what makes a restore drill safe to run against production repositories — it cannot collide with the machine it came from. Recovering the machine for real? Opt each piece of its identity back in, or take all of it at once with --preserve-identity.
Nine screens. Everything the appliance knows, and nothing it does not.
Posture, in the order you need it
How many resources are protected and how many of those are on an automated rotation rather than someone's memory. How much of your storage is remote-backed, because a DR copy in the same building is half a job. Then every operation that ran, and — kept separate on purpose — problems and warnings. A warning is something to look at this week; a problem means a restore would not work today.
What is protected, and what only looks protected
Every VM and microVM with DR enabled, with its size, the filesystem its repository lives on, and its retention shown as the counts actually in force rather than the tier's name alone. The split that matters is Automated against Manual: a resource nobody put on a schedule is the one that will be stale when you reach for it.
Three schedules per resource, each independently on
Retention, integrity check and cloud sync are separate jobs with their own intervals, so a repository can be pruned nightly, verified weekly and mirrored off-site monthly without any of those decisions implying the others. Applying a tier copies its counts here — the resource keeps them even if the tier is later edited.
Six tiers, and the freedom to ignore them
Scratch through Archival ship with the appliance, roughly doubling in reach at each step. They are ordinary templates: editable, extendable, and one of them is the default that new repositories are created with. The list shows how many resources are on each, which is how you notice that everything landed on Bronze.
Every snapshot, with restic's reason for keeping it
Pick a repository and read its history: short ID, time, the host that wrote it, the tags carrying the resource's name, type and UUID, and the size. Where a retention policy applies, each snapshot carries the reason it survived the last prune — daily, weekly, monthly, yearly — passed through from restic's own output rather than recomputed, so the policy is legible as a result rather than as a rule.
Look inside before you commit to a restore
A snapshot opens as a file listing, straight from restic ls — the guest's disk images and its configuration, with sizes and timestamps. Two numbers are shown because two numbers matter: what the restore will write, and what the snapshot actually costs after deduplication.
Who is reading a repository right now
Open grants and repository sessions on top, with the client address that claimed each one, who issued it and when it expires; completed restores underneath with the snapshot and how long it took. Every restore drill leaves a row here — which is also the record that proves the drills happened.
Where the repositories actually are
Local paths, rclone-mounted S3 and SFTP remotes, and archive targets that are never mounted, each with what it holds and what is left. Adding a remote is a form, not a config file: the appliance writes the rclone entry and mounts it, and new repositories can be created there immediately.
Nothing happens without a row
Sign-ins, retention runs, integrity checks, grants issued and claimed, filesystems added, users changed — with the actor, the outcome and the tool's own output attached. Scheduled work is recorded as the system actor, so an unattended prune is as accountable as a human one.
It is a compose stack. Where it runs is your call.
Run it on bare metal, in a virtual machine, or as a microVM on a Hoster node — the last of those ships ready-made. The only rule is that it does not live on the fleet it protects.
One port, one origin
The operator interface, the API and the restic ingress share one HTTPS endpoint — one origin to publish, and one to firewall.
Immutable tags only
Images are built and pushed under a timestamped tag that is never moved. Upgrading is a one-line change and rolling back is the same line with the previous value — which is what you want from the system you reach for during an incident.
Encrypted storage, and you mean it
The appliance holds the repository passwords, because that is what lets hosts hold none. Its own dataset is therefore the crown jewels, and it belongs on encrypted storage with its key database backed up somewhere that is not the backup system it unlocks.
Nothing dials in
Hosts reach out to the endpoint you publish. Nothing has to reach into a host's network to take a backup, which is what makes this work across sites and behind NAT.
Full deployment steps, the environment it takes, and what to back up are in the documentation.
Run Hoster on your hardware. Start with one server.
Start a contract
Tell us about your fleet and we will come back to you.