Backup infrastructure sees the whole estate every night, which makes it an unusually good vantage point for noticing that something has changed. Most organizations use it only to answer whether jobs succeeded. The more useful question is whether the shape of the data changed, because encryption, mass deletion and exfiltration all leave a signature in backup and storage telemetry before anyone notices them elsewhere.
The signals are already being produced. Turning them into detection is mostly a matter of establishing what normal looks like and alerting on departures from it, rather than deploying anything new.
Why the backup path is a good place to watch
Three properties make it valuable. It covers everything that is protected, which is usually broader coverage than any security tool has. It operates on a regular cadence, so comparisons against a baseline are straightforward. And it observes data at rest across the whole estate rather than events on individual hosts.
The limitation is latency. A nightly backup detects a change up to 24 hours after it happened, which is slower than endpoint detection and considerably better than nothing. In practice the backup signal is a corroborating and sometimes a first indicator, particularly for slow moving activity that stays below the threshold of tools watching for rapid behavior.
It is also the signal that matters most for the recovery question, because it speaks directly to whether the protected copies still represent the data the organization expects.
The signals worth watching
Most of these are derived from figures backup and storage platforms already report. The value comes from trending them per protected system rather than looking at estate totals.
| Signal | What a departure can indicate | Common benign cause |
|---|---|---|
| Change rate rising sharply | Bulk encryption or mass modification | A migration, a large software deployment |
| Deduplication ratio falling | Encrypted data no longer deduplicates | New workload with different data |
| Compression ratio falling | Encrypted content does not compress | Already compressed media added |
| Backup window lengthening | More changed data than usual | Growth, or a slower network path |
| File count dropping sharply | Mass deletion before encryption | An archive or cleanup project |
| File extensions changing en masse | Ransomware renaming as it encrypts | An application upgrade changing formats |
| Delete or overwrite requests on the repository | An attempt to remove protected copies | Expiry housekeeping, if it looks the same |
| Authentication failures against the repository | Credential guessing or a reused stolen key | An expired credential after a change |
| Access from unexpected addresses or times | Use of stolen repository credentials | A new backup proxy or a schedule change |
The deduplication and compression signals are the most distinctive, because encrypted data is close to random and stops compressing or deduplicating almost entirely. A sudden collapse in either ratio for a system whose content has not otherwise changed is a strong indicator and it is straightforward to trend.
Baselines and thresholds
Every signal here needs a baseline, and the baseline has to be per system. A file server with a 2 percent daily change rate and a database with a 30 percent rate are both normal, and a single estate wide threshold produces either constant noise or no detection at all.
Two or three weeks of history is usually enough to establish a per system normal range. Alerting on a departure of a few multiples rather than on a fixed value keeps the rate manageable, and a rule requiring the departure to persist for two consecutive runs removes most of the noise from one-off events.
Correlation across systems is what turns an observation into a signal worth escalating. One server with an unusual change rate is likely operational. Fifteen servers across three departments with the same pattern on the same night is not.
Storage side signals the backup software does not see
The repository itself produces telemetry that sits outside the backup application's view, and it is the layer where an attack on the copies would appear. Requests to delete objects, attempts to modify retention or lock settings, authentication failures, and access from unfamiliar sources all belong in monitoring alongside the content signals.
Any attempt to delete or alter a locked object deserves particular attention, because in normal operation there is no reason for one to occur. A denied deletion is the control working, and it is also evidence that something tried, which is exactly the kind of event that belongs in front of a security team rather than in a log nobody reads. The same applies to changes in configuration, along the lines of watching for retention changes as a first class event.
Where Scality fits in the signal set
Scality RING and ARTESCA record S3 access at the object level, so requests reaching the repository can be examined for the storage side signals above: deletion attempts against locked objects, authentication failures, and access from sources outside the expected set. Forwarding those records into existing monitoring puts them in the same place as the rest of the estate's telemetry rather than in a separate console.
Object Lock provides the corresponding control. It ensures that an attempt to remove protected copies fails rather than succeeding quietly, which means the signal and the protection work together: the attempt is denied, and the denial is the alert. That combination is more dependable than detection alone, because it does not require anyone to react quickly enough.
Route the alerts where someone will act
These signals are of limited use inside a backup console that the infrastructure team reviews weekly. Their value comes from reaching the same monitoring that security alerts reach, with enough context that the person receiving one can tell an operational change from a genuine anomaly.
Start with two or three signals rather than all of them. Deduplication ratio collapse, sharp change rate increases and denied deletions against the repository cover a large share of the risk and generate few false positives once baselines exist. Adding more is easy once the first ones have proved they are worth responding to.