ROOTKey vs backup: what is the difference?
Short answer
A backup keeps copies of your systems and data so you can get them back after a failure, a deletion or an attack. ROOTKey seals a fingerprint of every version of your files, tables and records in an independent public registry, shows what changed - who, when and where - and restores only what was altered to the last version proven valid, cryptographically verified. Backup restores systems; ROOTKey proves whether the restored data can be trusted. They are complementary, not competing.
- Fingerprint
- SHA-256for every version, with a timestamp
- Detection
- Continuouswhat, who, when and where
- Scope
- File · table · rowonly what was altered
- RTO
- < 4 hoursContractual on Enterprise, a target on platform plans
Side by side: backup and ROOTKey
A restore that completes without errors proves that the copy came back. It does not prove that the copy was right. The table sets out what each one does.
| Backup | ROOTKey | |
|---|---|---|
| What it answers | Can we get our systems and data back after a failure, a deletion or an attack? | Can the data we have, or have just restored, be trusted - and what exactly changed? |
| What it records | Copies of systems and data, taken at points in time | A SHA-256 fingerprint of every version of every file, table or record, sealed with a timestamp in an independent public registry |
| Third-party proofintegrity proven to others | A completed restore shows that the copy came back as it was stored, not that what was stored was correct | Every critical action produces an independent proof that external auditors can verify without access to the original data |
| Change detailwhat, who, when and where | Not its purpose: it keeps earlier states, and comparing them is a separate task | Yes: every change is caught and explained - row, cell or field, before and after - with who, when and where |
| Selective restoreonly what was altered | Restores a system, a volume or a set of files to a point in time; how fine-grained depends on the tool | Yes: the last version proven valid, down to one file or one row |
| Independent verification | Checks rely on the backup system's own records, such as the checksums of the copy | The reference fingerprint is sealed in an independent public registry |
| Existing storageworks with what you use | Copies data to its own backup target | Works on top of the tools you already use: direct connectors to SharePoint, OneDrive, Amazon S3 and Cloudflare R2, the REST API and webhooks |
| Regulatory evidence | Supports the backup and recovery measures in NIS2 Article 21 and DORA Article 12 | A cryptographic audit trail, integrity reports and evidence packs for NIS2 (Art. 21, 23), DORA (Art. 9, 17) and GDPR (Art. 32) |
When you need each
- Backup
- To get systems and data back after a hardware failure, an accidental deletion, ransomware or a disaster. Regulation expects it too: DORA devotes Article 12 to backup, restoration and recovery, and NIS2 Article 21 includes business continuity, notably backup management and disaster recovery.
- ROOTKey
- When the question is whether the data can be trusted: a silent change to a supplier's IBAN or a clinical record, data altered before the last copies were taken, or an auditor, a regulator or an insurer asking how you know the restored data is correct.
If you need to get data back and to prove that it is right, you need both: they answer different questions.
How they work together
ROOTKey adds to your recovery process the piece that is usually missing: an independent reference for the correct state.
Anchor
Every version of every file, table or record gets a unique fingerprint, sealed in an independent public registry with a timestamp.
Detect
ROOTKey continuously compares your data with the sealed record, so you know which files, versions or rows diverge from the sealed state and which are still intact.
Recover and check
Restore only what was altered to the last version proven valid, down to one file or one row. Whatever comes back is compared with the sealed record: a match shows that the content has not changed since it was sealed. Integrity verification reports confirm whether any data was lost or tampered with, ready for insurers or regulators.
Recovery with ROOTKey, step by step: Data recovery.
Frequently asked questions
Is ROOTKey a backup solution?
No. Backup restores systems. ROOTKey proves whether the restored data can be trusted - they are complementary, not competing.
Does a successful restore prove the data is correct?
It proves that the copy came back as it was stored. If the data was already altered, corrupted or incomplete when the copy was made, the restore reproduces that state. ROOTKey compares the data with its sealed fingerprints: an exact match shows that the content has not changed since it was sealed.
Can ROOTKey restore a single file or row?
Yes. ROOTKey restores the last version proven valid, down to one file or one row: only what was altered returns to the sealed original, cryptographically verified. One-click recovery restores the exact state of your data, from any snapshot, in under 4 hours (contractual on the Enterprise tiers, a target on the platform plans).
Does ROOTKey keep copies of our data?
On the SaaS platform, ROOTKey hosts your data in the EU. With a private cloud or on-premise deployment, your data stays wherever you decide. For recovery, encrypted snapshots are stored according to your configuration.