The backup that notices you're being encrypted.
Encrypting data raises its entropy toward 8 bits per byte and collapses how well it compresses and dedupes. Every TillArk backup measures both, so a source being encrypted shows up in its next backup, and TillArk makes sure you can’t restore from the encrypted copy by mistake.
Two measurements, moving together
Neither measurement is proof on its own: media and already-compressed files are high-entropy by nature. The alarm needs both, judged against this source’s own recent healthy backups.
A normal database backup An encrypted (ransomware) backup
────────────────────────────── ──────────────────────────────
entropy ~4–6 bits/byte (structured) entropy ~7.9 bits/byte (ciphertext)
dedup 2–4× (compresses) dedup ~1.0× (incompressible)
│ │
└ within this source's history └ rise + collapse, together
└▶ alarmSigned on the way out, judged on the way in
- Measured by the agent. A database dump is measured over every byte as it streams to storage. File, WAL-G and pgBackRest backups are measured over a bounded sample of their files, and clickhouse-backup backups over everything but the column files ClickHouse already compresses.
- Signed into the manifest. The entropy and dedup ratio sit in the signed manifest, so nobody can lower them after the fact without breaking the signature. The control plane judges only readings whose signature it has verified.
- Judged against a baseline. The last healthy backups of the same source form the baseline. Until a source has three, nothing is judged, so a new source never raises a false alarm.
Watch or alarm, with the reason
| Verdict | When | What happens |
|---|---|---|
| alarm | Entropy rises (or is ciphertext-grade) and dedup collapses in the same backup. | The backup is quarantined, the event opens, and you are notified. With pause on alarm, the source is paused too. |
| watch | One strong signal without the other: an entropy spike, or a dedup collapse. | The event opens for you to look at. Nothing is quarantined. |
| normal | Within the baseline. | Nothing is recorded. |
Each event carries its reasons (combined_encryption_signature, entropy_spike, entropy_absolute_high, dedup_collapse) and the reading next to the baseline, so you can see why it fired.
Quarantine, pause, triage
- Quarantine. A quarantined backup can’t be restored, verified or cloned, and never counts toward the recovery point. You don’t recover from ransomware. A differential or incremental backup built on it holds its data, so it is quarantined with it, and no new one builds on it.
- Pause on alarm. Turn it on per policy (the Pause the source on a ransomware alarm box on the Policies page, or
--pause-on-alarm) and an alarm also pauses the source, so no more encrypted backups pile up and push good ones out of retention. It is off by default because pausing backups is an incident decision. - Triage. Acknowledge, confirm or dismiss an event on the TillArk overview or from the CLI. Dismissing it as a false positive needs an owner or admin and releases the backup from quarantine, with the backups built on it. One that also builds on another quarantined backup stays quarantined through that one. A paused source stays paused until you resume it; the overview offers to, and the CLI prints the command.
tilldev ark canary ls # open events, with the reading vs the baseline
tilldev ark canary ack <event-id> # seen
tilldev ark canary confirm <event-id> # a real incident; the backup stays quarantined
tilldev ark canary dismiss <event-id> # a false positive; clears the quarantine (admin)
# Pause the source automatically on an alarm:
tilldev ark policies update <policy-id> --pause-on-alarmEvery alarm, quarantine, pause and triage step is written to the audit trail.
See Security for the signed manifests the canary relies on. Back to the TillArk overview.