Veeam, Synology and Proxmox cover a large share of what a small IT team or an MSP looks after: Veeam on the Windows and VMware estates, a Synology NAS in the comms cupboard, Proxmox on the hosts that replaced the old hypervisor. All three can email a report after every backup. None of them can tell you that a report did not arrive.
Monitoring them by email across many clients comes down to three decisions: where each report is sent, how a report is tied to the right job, and how you prove the setup works before you rely on it. This guide walks through each, product by product, and ends with the mistakes that most often make a setup look fine while it quietly is not.
What each product sends
Veeam Backup & Replication sends one email per job session. The default subject starts with the result in square brackets, then the job name: [Success] Nightly File Servers (4 machines). The body repeats the job name on a "Backup job:" line and lists the size and duration. Notifications are set once for the server under Options → E-mail Settings, or per job under the job's Storage → Advanced → Notifications tab.
Synology DSM sends Hyper Backup results as ordinary DSM notifications, with subjects such as Network backup - BKP to HDD2 successful on NAS01. The subject names the task. On DSM 7.2 or later, a notification rule (Control Panel → Notification → Rules) lets you choose exactly which events go to which recipient, so the backup results can go to one address while disk health, updates and sign-in notices go elsewhere.
Proxmox VE sends a "vzdump backup status" email after each backup job, with the result, the guests it covered, the total size and the running time. From version 8.1 the email goes through the notification system (Datacenter → Notifications, with a target and a matcher); earlier versions use the "Send email to" field on the job itself. Proxmox Backup Server has its own notification settings for datastore jobs.
One address per client or one per job
The address a report is sent to tells the receiving end which client it belongs to. The question is whether it also has to tell it which job.
That depends on whether the report names the job in a way that can be read reliably:
- Veeam names the job in the subject and the body. One address per client is enough: every job on that client's server can send to it, and each report is sorted by its job name.
- Synology names the Hyper Backup task in the subject. One address per client covers every task on the NAS, and several NAS units at the same client if their task names differ.
- Proxmox titles its report by host ("vzdump backup status (pve01)"), not by job, so there is no job name to match on. If a client has one backup job, one address per client works, because every report that arrives belongs to that job. If a client has several, give each job its own address, set as the job's recipient where your version allows it.
A per-client address is the simpler default. It survives new jobs being added: a Veeam job created next month starts reporting to an address that already exists, and its first report shows up as something new to monitor rather than vanishing. Per-job addresses are for the products that leave you no choice.
Naming conventions that keep reports matched
When matching is by name, the name in the report and the name in your monitoring have to agree. A few habits keep it that way:
- Copy the name, do not retype it. Take the job or task name from the first report, character for character. "Nightly - SQL" and "Nightly – SQL" are different names.
- Rename in both places, or not at all. Renaming a Veeam job to tidy up the console is the most common reason a job that was healthy for a year turns up as unmatched.
- Keep names unique within a client. Two Hyper Backup tasks called "Daily" on two NAS units at the same site cannot be told apart. Add the device: "NAS01 Daily", "NAS02 Daily".
- For Proxmox, name the monitored job after what it covers. The email will not carry the name, so the name is for people: "pve01 nightly, all guests" says what to check when it goes quiet.
- Leave the subject templates alone. Veeam's default subject,
[%JobResult%] %JobName% (%ObjectCount% machines) %Issues%, is what most parsers expect. Customising it to add a client prefix usually makes reports harder to read, not easier.
Set each product to report every result
Every product should send successes as well as failures. A job that only reports failures is indistinguishable from a job that has stopped, as described in A backup can fail by saying nothing.
- In Veeam, tick Notify on success, Notify on warning and Notify on failure. Keep "Suppress notifications until the last retry" ticked, so a job that succeeds on its second attempt does not send a failure first.
- In DSM, tick the Hyper Backup events that say how a backup ended: completed, partially completed, failed, canceled, suspended. Leave LUN, restoration and announcement events out, because every email that reaches the address is read as a backup result.
- In Proxmox, set the job's email to always rather than on failure only. On 8.1 or later, check that the job's notification mode uses the notification system, or the matcher you set up is never consulted.
Verify the first report
A setup is not finished until a real report has arrived and been read correctly. For each new job:
- Run the job once rather than waiting for the schedule. In Veeam, start the job; in Hyper Backup, Back up now; in Proxmox, Run now on the backup job.
- Check where the report landed. It should sit under the right client and the right job. If it did not match, the name or the address is wrong, and now is the time to fix it.
- Check what was read. The result should match what the backup software says. Where the size and duration are read, check them against the job's own log once.
- Wait for the next scheduled run and check that it arrives too. The first manual run proves the email path; the second proves the schedule.
- Set the expected interval so that a run that does not happen is noticed. A daily job should be expected daily; a weekly one, weekly. RPO, grace windows and when a backup is really late covers the edge cases.
Repeat this whenever a job is added, renamed or moved to another server.
Common mistakes
Treating the test email as proof. Veeam, DSM and Proxmox can all send a test message. It proves the SMTP settings work. It says nothing about whether backup results will be sent, to which recipient, or with which events ticked. Only a real backup result proves that.
Failure-only notifications. A job set to email on failure looks perfect on every good day, and also on every day after it stopped running. Look at Proxmox's "on failure only" setting, and at Veeam jobs whose own notification settings override the global ones.
Forwarding that rewrites the subject. Reports sent to a technician's mailbox and forwarded on often arrive with FW: or Fwd: in front of the subject, a changed sender, or the original attached rather than inline. Parsers that look for the result at the start of the subject, as with Veeam's [Success], can miss it. Send reports straight from the backup software to the monitoring address. Where forwarding is unavoidable, use a server-side rule that redirects the message unchanged.
A rule that sends too much. A DSM recipient that gets every notification mixes backup results with disk health, restore notices and update announcements, and each of those arrives looking like a backup report.
Shared names across devices. Two tasks with the same name at the same client will update the same job, so one of them can stop without anyone seeing it.
Jobs added without monitoring. A new job that reports to the client address but has no matching job to update is easy to overlook. Check unmatched reports regularly, not only failures.
How BackupSentinel handles it
BackupSentinel has built-in parsing rules for all three products. The Veeam rule reads the job name from the "Backup job:" line, with the size and duration; the Synology rule reads the task name and duration; the Proxmox VE and PBS rule reads the result, size and duration but no job name. So a client address such as harbour-it-northwind-dental-3f9a1c2b7d4e8f60@ingest.backupsentinel.io covers all of a client's Veeam jobs or Hyper Backup tasks, and each backup also has its own per-job address in the job drawer for Proxmox and anything else that cannot be told apart.
A report whose job name matches no backup, or a test email, waits in the Inbox, where you can assign it, ignore it or start monitoring from it. For Synology, starting from a task's first email suggests the task name. Integrity-check reports never count as a backup run, and a failed check opens its own alert.
The step-by-step guides are in Veeam setup, Synology setup and Proxmox setup. How addresses work is in Client addresses, and how reports are matched is in Parsing rules.