> ## Documentation Index
> Fetch the complete documentation index at: https://3to1go.docs.thesteau.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Unusual backups

> How Edge spots backups that look nothing like a job's history, such as ransomware damage, and holds them for review.

Each job builds up a picture of what its backups normally look like. When a new backup looks very different, such as a folder that suddenly emptied or files that ransomware encrypted, Edge holds it instead of uploading it. Your good snapshots on Central stay safe from retention until you decide.

```mermaid theme={null}
flowchart LR
    A[Archive built] --> C{Looks like<br/>this job's history?}
    C -->|Yes| U[Upload]
    C -->|No| H[Hold and alert]
    H -->|Upload anyway| U
    H -->|Clear staged backup| X[Discard]
    U --> L[Becomes part of<br/>the job's history]
```

Detection only uses file paths, sizes, file types, and how well the archive compresses. It never reads your files' contents.

## What Edge checks

| Check | Flags | Needs |
| - | - | - |
| **File count and size** | A folder that's less than half or more than double its usual size or file count | 5 earlier backups |
| **Compression** | An archive that stopped compressing. Encrypted files look random, so ransomware pushes the archive to about 100% of the original size. | 3 earlier backups over 1 MB |
| **Changed files** | Most files renamed or rewritten while the file count barely moved | 1 earlier backup, 20+ files |
| **File types** | One file type suddenly taking over, such as `.locked` going from 0% to most of the folder | 1 earlier backup, 20+ files |

Each job keeps its last 20 uploaded backups as its "normal". Photo and video folders that never compress well aren't flagged by the compression check, and adding lots of new files only trips the count check, not the changed-files check.

<Note>
  Behind the scenes, sizes and counts use a robust z-score (median and median absolute deviation) on a log scale, changed files are estimated with MinHash, and the file-type mix is compared with the Jensen-Shannon divergence. All of it is plain statistics that runs in milliseconds, with no model to download.
</Note>

## When a backup is held

The job shows **held for review** with the reasons, for example:

> The archive barely compresses (100% of the original size, usually 41%), which is typical of encrypted files. Files ending in .locked went from 0% to 100% of the folder.

Edge also sends a high-priority [ntfy](/edge/notifications) alert if notifications are set up. Then either:

* **The change is expected**, such as a reorganized folder: click **Upload anyway**. The backup uploads and becomes part of the job's normal, so the same pattern won't be flagged again.
* **Something is wrong**: click **Clear staged backup** to discard it, then fix the folder, for example by [restoring](/edge/restore) the last good snapshot.

A held job stays held on later cycles while its files stay the same. If the files return to their last uploaded state, the hold clears by itself.

## Settings

Choose **Unusual backups** in **Edit Edge Settings**, or set `ANOMALY_MODE` in `.env`:

| Mode | Value | Does |
| - | - | - |
| Hold for review and alert | `hold` (default) | Keeps the archive staged and alerts |
| Alert only | `alert` | Uploads as normal and alerts |
| Off | `off` | No checks. History is still recorded, so turning it back on works right away. |

**Force Upload** always uploads without checking, since it's an explicit request.

Central runs its own, simpler check on archive sizes as a second line of defense. See [Unusual sizes](/central/snapshots#unusual-sizes).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.