Veeam, Synology, rsync: why no two backup reports look alike

Pick any two backup tools and look at the emails they send. A Veeam job report and a Synology notification don’t just look different — they disagree on what “done” even means. One writes a status word in the subject line. The other buries it three paragraphs down. A homemade script sends nothing but an exit code.

The people I work with who run MSPs hit this the same way every time: a filter tuned for one tool quietly stops working the moment a second tool enters the picture. It doesn’t fail loudly. It just starts missing things.

Three tools, three ideas of “success” #

Here’s the same event — a backup that finished but skipped a few files — as three different tools would report it.

• Veeam puts a status in the subject (Success, Warning, Failed) and a structured summary in an HTML body. A partial job usually lands as Warning, not Failed — the word you’re filtering for isn’t there.
• Synology (Hyper Backup / Active Backup) sends short notification emails, often triggered per-event, with wording that shifts between DSM versions.
• rsync (or any homemade cron script) sends whatever you told it to print. Frequently that’s plain text, no fixed structure, and an exit code that means “the transfer ran,” not “the backup is usable.”

Three tools. Three vocabularies. Three places to look for the one line that matters. Add a fourth vendor and it’s a fourth.

Why the keyword filter breaks at tool number two #

A subject-line rule like “flag anything containing FAILED or ERROR” feels reasonable. It even works — for exactly one tool, for a while. Then reality shows up:

• Veeam’s partial failures say Warning, so they sail straight through a FAILED filter.
• A Synology DSM update changes the notification wording, and your rule silently goes stale.
• Your rsync script prints completed on the line above rsync error: some files vanished — and the happy word wins.

Each tool needs its own set of rules, its own thresholds, its own idea of where to look. Maintain that across several tools and a dozen clients and you’re not monitoring backups anymore — you’re maintaining a filter library that drifts out of date every time a vendor ships an update. This is the same trap the pillar article describes in detail: why backup monitoring fails silently .

Why this is exactly what people search for #

Notice how specific the frustration gets. People don’t search “backup monitoring best practices.” They search:

• “Veeam backup report not showing warnings”
• “Synology Hyper Backup notification success but failed”
• “rsync cron exit code 0 but backup incomplete”

Every one of those is the same underlying problem: the tool’s own report format hid a state you needed to see. The fix isn’t a better filter for that one tool. It’s giving up on per-tool keyword rules entirely.

Read the meaning, not the keyword #

The approach that actually holds up across tools is to stop matching words and start reading the report the way a person would. Feed the raw report — subject, body, plain text, whatever the tool sent — to a language model and let it classify the outcome: success, warning, or failure. It handles Veeam’s Warning, Synology’s shifting phrasing, and your rsync script’s exit-code quirks without a separate rule for each. When a vendor changes their wording next month, there’s nothing to rewrite.

That’s the mechanism behind BackupMonitor.cloud : you forward the report emails to a dedicated address, each one gets classified within minutes, and an alert only goes out when something looks off — no dashboard, no agent, no per-tool filter to maintain.

If you’re managing more than a couple of backup tools across clients, the 7-day trial on BackupMonitor.cloud doesn’t require a credit card.