CEDX Backup · IT & Security
CEDX Backup tracks the jobs, but it scores the restores. Every asset carries a readiness score, every restore point is checked for infection, and the gaps board sizes what is not protected at all, in terabytes.
The demo's primary database has a point 6.0 hours old, and a restore test 45 days stale that failed. The product's advice, on screen: restore to an isolated cleanroom, not prod.
Runs on demo data: Northline is the software's sample estate, not a customer.
What it is
64 assets on the readiness model, 21 not ready at score ≥70. The heat grid names them (a finance file share at 98 whose last success is past the RPO window) and infected restore points feed the score at +15 weight each, so a poisoned backup makes you less ready, not more.
48 coverage gaps, 101 TB uncovered. Reasons are explicit: orphaned chain 40 days, no policy for 55 days, never backed up. Each row carries blast score, tier, days exposed and size. A legacy archive at 7.8 TB does not hide behind a percentage.
320 jobs in the demo corpus: 47 failed, 85 warning or failed, 85 past their RPO window. Age in hours is on the row: a database catalog job at 668 hours is a finding, not a footnote.
Product tour
Not a mockup and not a concept deck. This is what opens at /app/backup.
01 Overview
Job health is 62.8%, and the screen says the harder things too: 85 jobs past their RPO window, 13 high-blast assets unprotected, a 439 TB corpus. The analyst bar answers the question you actually have: can I restore this database to before Sunday?
02 Restore readiness
Top of the heat grid: a finance file share, a store endpoint, a cache host, all at 98, all past their RPO window. The infected-points table above it lists which restore points are quarantined, per asset.
03 Unprotected
The gap cards sort by blast: an orphaned payment-mail chain 29 days exposed at 98, an HR ledger with no policy for 55 days at 91, secrets infrastructure 18 days orphaned at 88. Gaps, not jobs: things nothing is even trying to back up.
04 Jobs
When you need the plumbing: every job with status, type, OK percentage and age. Warning rows outnumber failures. The point of the screen is that both are visible before the RPO breach tab fills up.
Who runs it
Roles, not references. We have no named customers yet, so nobody in these photographs is quoted, credited or claimed as one.
Owns the job stream and the RPO breaches: the 85 jobs past window are theirs to clear, oldest first.
RPO breach · 85
Works the gaps board: every uncovered asset gets a policy, a chain, or a decision, with the size of the exposure on the row.
uncovered · 101 TB
Runs the restore tests and the cleanroom restores. The 45-day-stale failed test on the primary database is the kind of finding they exist to close.
restores ok 30d · 90The shape of it
Every figure below is legible in the captures above. Nothing here is a projection of your estate. It is the state of the demo data.
How it runs
Assets bind to policies and chains, and the gaps board counts whatever did not, in terabytes, with the reason.
Jobs run, but readiness is the score that matters: last success inside the RPO window, restore test fresh, points free of infection.
Infected restore points are flagged and weighted into readiness at +15 each: a poisoned point is a liability, not a safety net.
When the day comes, the answer is specific: latest point 6.0 hours old, test 45 days stale, two points infected. Restore to an isolated cleanroom.
One record
An asset only appears on the gaps board because the estate knows it exists: the device, the owner and the control are the same record elsewhere.
The 344-asset estate Inventory IT keeps is what the gaps board reconciles against. Uncovered assets are a join away, not a discovery project.
CEDX EndpointEndpoint-class assets carry an exposure score; backup readiness sits next to it, so a device can be both exposed and unrestorable, and you can see it.
CEDX VaultThe secrets infrastructure on the gaps board (ops-secrets, 18 days orphaned) is the same namespace Vault ages. One record, two risks.
CEDX ComplianceBackup and recovery controls are rows in the controls library; the restore-test log is the evidence they point at.
Limits
Finding this out on the third call is worse for you than reading it here, and worse for us.
Start
Open it right now
Your assets, your policies
Backup with the rest of it
Questions
Yes. Every screenshot is a capture of the running build and you can open the same build at /app/backup. It runs on demo data: Northline is the sample estate.
A per-asset score built from signals you can read: last successful backup inside the RPO window, restore-test freshness, and infected restore points weighted in at +15 each. The heat grid shows the worst 12 and every cell opens its evidence.
Assets nothing is protecting: 48 rows, 101 TB, each with a reason (orphaned chain, no policy, never backed up, offline past RPO, partial only) plus days exposed and size. It exists so the uncovered 146 are a list with owners, not a surprise.
They are flagged, quarantined and fed into the readiness score. The Overview's point-in-time answer for the primary database is the honest version: latest point 6.0 hours old, but the restore test is 45 days stale and failed. Restore to an isolated cleanroom, not prod.
No certification has been issued. What we can evidence about hosting, encryption, tenant isolation and retention is written up on the security page.
Live build, demo data, no card. Then ask which of your assets is one restore test away from being a rumour.