A backup report says Success. The job ran on time, nothing errored, and the result is green. It also says the backup wrote 38 GB, where every night for the past month it wrote around 400.
Status alone says nothing is wrong. The size says something changed. A backup that does what it was told is only as good as what it was told to do, and a sudden drop in size is often the first sign that what it was told to do no longer matches the data that needs protecting.
Why a smaller backup can still be a success
Backup software reports on the job it was given. If the selection no longer includes a folder, the job does not fail: it backs up what is selected, faithfully, and reports success. A few ways that happens, all possible and none of them rare enough to rule out:
- An exclusion was added. Someone excluded a large folder to get a slow job under its window, or to work around a locked file, and it was never put back.
- The data moved. A file share was migrated to a new volume, a database moved to a new disk, a virtual machine was moved to a different datastore or host. The job still points at the old location, which is now nearly empty.
- The selection broke. A virtual machine was renamed and the job selected it by name. A mailbox was converted to a shared mailbox and dropped out of a user-based selection. A drive letter changed.
- The source is unreadable. Some products skip what they cannot read, a share whose credentials expired or a volume that did not mount, and log it as a note rather than a failure.
- The source was damaged. Ransomware does not always make a backup smaller; encrypted data often makes incremental backups larger. But it can: when the originals are deleted after encryption, or when the job selects files by type and the encrypted copies get a new extension that the filter no longer matches.
None of these produce a failure email. All of them show up in the size.
Which size to watch
Most products report more than one figure, and they behave very differently.
- The protected or source size is how much data the job covers. It grows slowly and drops only when something leaves the selection. This is the figure that tells you about coverage.
- The transferred or written size of an incremental backup is how much changed since the last run. It swings naturally: a quiet bank holiday writes little, month-end writes a lot. A drop here often means nothing.
If your product reports both, watch the protected size. If it reports only what was written, compare like with like: full backups against full backups, and expect more noise.
Baseline with a median, not an average
To say a backup is "much smaller than usual", you need a usual. The obvious choice is the average of recent runs, and it is the wrong one.
Take seven nightly runs of 400, 410, 405, 1,600, 398, 402 and 407 GB. The 1,600 is a monthly full, or a one-off copy of a large folder. The average of those seven is about 575 GB, so a perfectly normal 400 GB night looks 30% smaller than usual. The median, the middle value once they are sorted, is 405 GB, and it ignores the outlier entirely.
The same protects you in the other direction. One tiny run, from a job that was cancelled halfway, drags an average down and makes the next small run look normal. The median barely moves.
Two more choices matter:
- How many runs. A short window, around a week of runs for a daily job, follows real growth without remembering last quarter. A long one is steadier but slow to adapt.
- Only successful runs with a size. A failed run that wrote nothing is not a data point about how big the backup should be.
Thresholds and minimum history
How much smaller is suspicious? A tight threshold such as 10% catches more and is wrong more often, because real data does shrink a little: logs rotate, temporary files are cleaned up. A loose one such as 50% only fires on drops that are hard to explain innocently. For a check that someone has to look at by hand, starting loose is sensible. You can always tighten it once you know how noisy your jobs are.
A few guards keep the check from crying wolf:
- Minimum history. A new job has no usual yet. Wait for a few runs before comparing.
- Minimum baseline size. A configuration backup of a few kilobytes can halve because one file changed. Below a certain size, percentage changes mean nothing.
- Recency. A drop from three weeks ago that nobody acted on is either understood or forgotten. Only look at recent runs, so the list reflects what is happening now.
Is it an alert?
A failed backup needs someone now. A smaller backup needs someone to look, today, and quite often the answer is "yes, that was expected". It is a question rather than an outage, so it belongs in the queue people work through, not in a channel that wakes someone at 3 a.m.
When one turns up, a short routine covers most of it:
- Compare the job's selection with what it was last month, if the product keeps a history of changes.
- Read the job log for skipped items, excluded paths or unreadable sources.
- Check the size of the source itself. If the share is still 400 GB and the backup is 38, the selection is wrong.
- Restore one file from a folder you expect to be included. If it is not there, you have your answer.
- Ask the client whether anything moved. Migrations are often done by someone else.
Expected drops
Plenty of drops are real and intended: a client archived ten years of old projects, a large mailbox was exported and removed, a server was decommissioned, one big job was split into two. When that happens:
- Mark it as expected so it stops asking for attention, and note why in the ticket or the client record.
- Check that the data went somewhere. If old projects moved to an archive share, is that share backed up? A drop that is expected on one job can be a gap overall.
- Expect the baseline to catch up. A median over the last week of runs needs several runs at the new size before the new size becomes normal. Until then, the next runs may look like drops too.
How BackupSentinel checks for small backups
BackupSentinel compares the newest OK or warning run that has a size with the median size of up to 7 sized OK or warning runs before it. It needs at least 3 earlier runs and a baseline of at least 1 MiB, and it flags the run when it is 50% of the baseline or less, as long as that newest run is from the last 14 days. The result is a Backup shrank N% item in Needs attention. It is never sent to alert channels: it waits in the queue for someone to look.
On the item, Expected hides that drop, for when the smaller backup is intended. Any later drop shows again, so if the next few runs are just as small, they can be flagged until most of the runs in the baseline are at the new size.
The check needs a size in the report. The built-in rules for Veeam Backup & Replication and for Proxmox VE / PBS vzdump read one; for other products, a custom rule with a size pattern does, as does size_bytes sent to the Report API. Writing a parsing rule shows how to choose the right figure. More on the queue is in Needs attention and on the Needs attention feature page.