The disaster recovery platform
Our DR product is three pieces: an agent on each protected host, a control plane that schedules and stores, and an operator console that will not tell you a comfortable lie about either.
The dashboard opens on what could stop a recovery — RPO breaches, failed jobs, agents that have gone quiet — before it shows you anything reassuring. Screens on this page are the built-in demo dataset, which is why they are labelled as such: the console will not render sample data into a real session.
The agent
One binary per host, installed as a service. It holds the credentials for the databases, filesystems and devices it protects, runs the work locally, and uploads the result in chunks over a mutually authenticated channel. An agent also reaches the network gear assigned to it, so a switch or firewall never needs to be reachable from outside your network.
It dials outward. There is no inbound port to open, no listener to expose, and no firewall exception to defend in a review — which is usually the difference between a rollout that happens this quarter and one that does not.
The control plane
Written in Go on top of ScyllaDB, and split into runtime modes — api, grpc and worker — so the component that serves the console is not the component that schedules the work. That separation is visible in the console rather than hidden by it: a node running api alone will serve you a dashboard while scheduling nothing, and the dashboard says so.
State is durable, migrations are versioned, and a half-applied schema refuses to serve rather than serving inconsistently.
Targets
A target is the thing being read.
| Kind | Covers |
|---|---|
| Database | PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ScyllaDB |
| Server | Linux and Windows hosts — filesystems, volumes, configuration and state directories |
| Network & security device | Cisco, Juniper, Palo Alto, Fortinet |
| Service | NGINX |
Registering a target does not protect it. Attaching it to a policy does — and the difference between those two states is exactly what the coverage figure measures.
Network and security devices
The firewall and the core switch are usually the least-backed-up things in an estate and the most painful to rebuild from memory. They are first-class targets here, on the same policies, schedules and retention as everything else.
Each device is registered with its hostname and address and assigned to an agent — the agent on your network is what reaches it, so nothing has to be exposed outward. When the agent connects it records what it actually found: product, version, whether the device answered, when, and which agent looked. A device with no agent assigned is reported as exactly that rather than silently sitting in the inventory looking protected.
Because a captured configuration is just a file in a recovery point, Inspection — below — works on it the same way it works on anything else: open Tuesday's config and Thursday's side by side and see precisely which lines moved. For a firewall ruleset, that is usually the question — not do we have a backup, but what changed since the last time this worked.
Protected assets and coverage
A protected asset is a target with a policy and a criticality. The console tracks two things about it that most tools collapse into one:
- Protection status — what you declared. This asset should be protected, at this level.
- Protection state — what actually happened. The last run succeeded, failed, or has not happened inside the window the policy promised.
Coverage is computed across the estate and excludes what you explicitly excluded, so an asset you deliberately left out does not quietly depress the number and train you to ignore it.
Every asset carries its criticality, the policy governing it, where its recovery points land, and how old the newest one is.
Policies
A policy declares three things:
- Cadence — how often a run starts, from hourly to monthly.
- Retention — how long recovery points survive.
- Immutability — whether a stored point can be altered before its retention expires.
Levels carry defaults, so declaring an asset critical yields an hourly, thirty-day, immutable policy rather than an empty form. Change the level later and the schedule re-bases unless you supplied one yourself. Deleting a policy that assets still reference is refused — an orphaned asset is an unprotected asset that still looks configured.
Cadence, retention, immutability and the RPO/RTO the policy commits to, on one row per policy.
Recovery points
Every successful run lands as a recovery point: an archive of what the agent uploaded, addressed by the asset it came from and the moment it was taken.
Restoring is a job, with its own progress, outcome and audit entry. It is not a button that returns to an idle screen and leaves you wondering.
Storage
Recovery points land where you tell them to — Amazon S3, Azure Blob, Google Cloud Storage, NFS, or local disk. Your bucket, your region, your lifecycle rules. The platform holds the index; it does not hold your data hostage.
Inspection
The layer that makes the rest of it checkable. Inspection reads into an archive rather than reading a status column: it reassembles the uploaded chunks, walks one level into the filesystem archive inside, and rebuilds absolute paths so the file you select is the same file across two points taken weeks apart.
From there you can list what a recovery point contains, read a file out of it, and compare that file against another point. Change detection is backed by content hashes — and when a hash is not available, the console says it fell back to size and modification time rather than presenting the weaker check as the same answer.
Pick two recovery points and the console tells you what actually differs between them — changed, modified, added, removed — then shows any file's contents side by side.