Backup Anomaly Detection

Catch backups that report success but are not actually usable.

A backup job can finish without an error and still be worthless — a database dump truncated to a few kilobytes, an archive that never reached storage, a credential change that silently reduced what got exported. Anomaly detection exists to catch exactly that class of failure: the backup that looks fine.

What gets checked

After each run, SimpleBackups evaluates the backup against several independent checks:

Check	What it detects
Size deviation	The backup's size is far outside its own historical norm — a sudden shrink or spike
Empty backup	The resulting file is essentially empty (a few kilobytes or less)
Database	A database dump is disproportionately small relative to the reported database size
File existence	The backup file cannot be found in your storage, or its size there does not match what was recorded
Storage presence	A weekly sweep confirming previously stored backups are still present at their destination
Warning in success	The backup succeeded, but its output contains warning signals such as permission denied, connection reset, or out of memory

Checks that do not apply to a given backup are skipped rather than failed — a schema-only dump is not flagged for being small, and storage-to-storage sync backups are exempt from the size checks.

How size deviation works

Size deviation is the check that needs the most explanation, because "unusual size" depends entirely on what is normal for your backup.

SimpleBackups builds a baseline from up to the 50 most recent successful runs of the same backup, using the median size rather than a simple average — a median is not dragged around by one anomalous run the way an average is.

The baseline is also cluster-aware. If your backup legitimately alternates between two size ranges, the sizes are split into groups and the baseline is drawn from the group nearest the current run, rather than averaging across a gap that was never really the norm.

A run is flagged when its size is:

• less than 25% of the baseline, or
• more than double the baseline

iWhy the thresholds are wide

These bounds are deliberately loose. Backups fluctuate — a busy week, a bulk import, a purge. Flagging every 20% wobble would produce noise you would learn to ignore, which is worse than no checking at all. The thresholds are set to catch the failures that matter: the dump that collapsed, the archive that ballooned unexpectedly.

The thresholds are not user-configurable.

When it stays quiet

Size deviation needs history before it can judge anything:

• Fewer than 5 prior samples — no baseline yet, the check is skipped. A new backup will not be flagged on its first few runs.
• Genuinely unpredictable backups — if a third or more of the historical samples are themselves outliers, the backup is treated as inherently variable and the check stands down rather than crying wolf every run.

Enabling anomaly detection

Anomaly detection is off by default and can be enabled per backup:

1. Open the backup and go to the Configuration tab
2. Find Additional Settings
3. Enable Anomaly Detection

A team-wide default is also available from the Auto-Diagnosis & Recovery section of the Getting Started dashboard. The per-backup setting overrides the team default in both directions (except for storage presence, which only runs when team anomaly detection is on), so you can enable it broadly and switch it off for the one backup you know is erratic.

!Anomaly results are being rolled out progressively

Anomaly detection currently runs in a monitoring capacity: checks execute and results are recorded, and our team reviews them while the thresholds are validated against real-world backup patterns. Customer-facing anomaly alerts are not yet enabled.

Do not treat anomaly detection as your failure alarm. Configure notification channels on the On Error event — that is what tells you when a backup fails today.

FAQs

What should I do if a backup is flagged?

Compare the reported run against recent runs of the same backup in the Logs tab, then check whether the change was intentional. A deliberate data purge, a new exclusion rule, or a migration will all move the size legitimately. If nothing explains it, inspect the run's log output and confirm the file in your storage is complete and restorable.

Can I adjust the sensitivity?

No. The thresholds are fixed, on the basis that presets which work for the large majority beat per-user tuning that mostly goes unconfigured.

Does anomaly detection cost extra, or require a specific plan?

No. It is available on all plans.

Does a flagged backup get retried or paused?

No. Anomaly detection observes and records; it never modifies, retries, or pauses a backup. Stalled-job recovery is a separate mechanism, controlled by the Self-Healing setting on each backup.

NotificationsSet up the channels that alert you when a backup actually fails.›Backup Recovery & Compliance BoardReview backup coverage and recovery readiness across a project.›