Your backup reports success: how do you know it is true?
In short
A backup report says a job ran, not that the data is usable. Backups stop silently, and the report stays green or stops arriving, which nobody notices. Two checks fix most of it: the job announces itself when it finishes, and you watch the age of the last good backup.
Almost every company has backups. Fewer have a copy that would bring them back tomorrow morning. The gap is rarely the backup software: it is that a backup which stops working does it quietly, and quiet looks like fine.
What does a “backup successful” report actually prove?
A green report proves that a job ran, and nothing more. It does not prove that the files are complete, that the destination had space, that the encryption key is available, or that anyone could restore from it.
Among IT professionals the stories are almost interchangeable, and the timescales are what hurt: a month without a good backup because the alerts went to the mailbox of someone who had left; a set of backups discovered to have been corrupted for roughly four months, found at restore time; tapes that were blank because the job had never actually been set to run.
None of those systems was screaming for help. Each looked normal until someone needed the data.
Which two checks catch almost everything?
Two: make the job speak, and watch a number.
First: make the job speak. At the end of your backup script, have it call a URL. If the call does not arrive within the expected window, you get an alert. This one change flips the problem: you no longer depend on failure being reported, you notice silence. It catches the job that never started, the machine that was off, the service that crashed, the script that died halfway.
Second: watch a number. Have a small command print something you care about — hours since the last successful backup, or the size of the newest file — and treat that number as a monitored value with a threshold. A job can complete and write nothing; a number catches it, a green report does not.
Both work on any system that can run a command or make an HTTP call, which includes almost every backup product, script or scheduler you already use.
Why does the NAS not save you here?
Because a NAS cannot tell you anything unless something asks it, and about the backup jobs it cannot tell you at all. Synology’s own MIB guide states that DSM does not support SNMP traps: the device cannot push an alert on its own. It can be asked — disk health, RAID state including degraded and crashed, free space — but only by something outside it, which polls.
And the outcome of the backup jobs themselves is not exposed at all. So “the NAS will tell me” has two problems: it only tells you if it is asked, and it never tells you about the job.
What to do this week
- Add the announcement line at the end of the backup job, and set the expected window.
- Print one number — hours since the last good backup — and watch it.
- Watch the destination: free space and disk health, so you hear about a full volume before the job fails.
- Book a restore test. Put it in the calendar with a name, not “someone should”.
A backup you have never restored is a hope. A backup that tells you every morning that it is still there, and how old it is, is a system.
What we cannot tell you
- We cannot read the outcome of a backup job inside a NAS: the common consumer and business NAS software does not expose it over the network, and we will not pretend otherwise.
- We cannot tell you that a backup is restorable: only a restore test proves that.
- We can only see what your system tells us: a job that announces itself, a number your script prints, or a device that answers.
Questions people actually ask
Why do backups fail silently instead of raising an error?
Because the part that would raise the error is often the part that stopped. A scheduled job that never starts sends nothing. A service that crashed sends nothing. A mailbox that rejects the alert swallows it. Silence looks exactly like success, which is why so many failures run for months.
What is the simplest check that actually works?
Make the backup job announce itself when it finishes, and alert when the announcement does not arrive in time. It reverses the logic: instead of waiting for bad news that may never be sent, you notice the silence. It takes one line at the end of the existing script.
What should I watch besides the job itself?
The age of the last good backup, as a number: hours since the last successful run, or the size of the newest backup file. A job can finish and produce an empty file. A number you watch every day catches that; a green report does not.
How often should a restore be tested?
At least twice a year, on a machine that is not the production one, with a stopwatch. You learn two things no report will tell you: whether the data comes back, and how long the business would be down. Write both down.