How do you find out the recorder's disk is dead before you need the footage?
In short
A recorder keeps its error to itself: most of these devices cannot send an alert, they can only answer questions. So a dead disk, a degraded array or a volume that filled up sits there for weeks with every light green. Something outside the box has to ask, every few minutes, and tell you when the answer changes.
The disk in a recorder is the part that does the actual work, it is written to continuously, and it is the part nobody looks at. When it fails, the cameras stay on, the interface still loads, the live view still moves. Nothing switches off. That is the whole problem.
What does the device never tell you on its own?
That a disk has failed, that the array is degraded, that the volume is full: many storage devices and recorders cannot raise their hand at all. Synology states in its MIB guide that DSM does not support SNMP traps: the NAS will answer questions about disk health, array state — including degraded and crashed — free space and temperature, but only when something asks. Left alone, it says nothing.
Recorders behave the same way. The error goes into an event log or onto a status page inside the device’s own interface, and that interface is opened when there is already a problem, which is the one moment when the answer is useless.
So the failure is not that the device hides the fault. It is that the fault is only visible to whoever goes looking, and nobody goes looking during a normal month.
How do people find out today?
Too late: among IT professionals the sentence is almost a genre, and the moment the client and the police are waiting for footage is when you find out the recorder’s disk died a month ago. The footage of the month before does not exist, and no amount of good intentions brings it back.
The version with a NAS is quieter and more expensive. The array goes degraded, everything keeps working, the email that would have said so was never sent because the device cannot send it, and the second disk fails three weeks later. At that point it is not a monitoring problem any more, it is a restore problem.
What should you ask the device, and how often?
Every few minutes, a probe inside your network should ask for the handful of numbers the device already publishes:
- Free space, as a number and as a trend. Not “is it nearly full” once a quarter, but a value you keep, so the answer becomes “full in about eleven days” instead of “quite full”.
- Disk health and the state of the array, where the manufacturer exposes them: healthy, degraded, crashed. A degraded array should reach you the same day, not the same quarter.
- Temperature, because a disk that runs hot in a cabinet in July fails earlier than the same disk in a rack.
- How long the device has been up, so a silent restart is visible.
- Whether it answers at all, which is the floor: a recorder that stopped responding is a problem you should hear about in minutes.
None of this needs new equipment inside the recorder. It needs something patient on the same network asking the same questions all day, and comparing today’s answer with yesterday’s.
Warned is not the same as down
A degraded array is not an outage. The system works; it is simply one failure away from not working. Treating those two states as the same thing produces either panic or, worse, the habit of ignoring the alert.
Keep them apart: an amber state that says “still working, needs attention this week” and a red one that says “not working now”. The amber ones are where the cheap saves live — the disk replaced before the second failure, the volume emptied before it filled, the recorder restarted on purpose instead of at 3 a.m. on a Sunday.
What to do this week
- Write down which recorder, which disks, which array. If nobody can answer that, it is the first finding of the exercise.
- Ask the manufacturer’s documentation what the device publishes — free space, health, array state, temperature — and watch those values from inside your network.
- Set the amber threshold where it is still cheap: a degraded array today, a volume at 80 per cent, a forecast of two weeks.
- Open the device’s own event log once. Whatever has been sitting in there unread is your baseline.
A disk that fails loudly costs a disk. A disk that fails quietly costs the month of footage that was supposed to be on it.
What we cannot tell you
- We cannot read a disk that the device does not publish: if a recorder exposes nothing over SNMP or SSH, all we can honestly see is that it answers on the network.
- We cannot predict a disk that dies without warning: we read the health the device reports and the space it has left, which catches most cases, not all of them.
- We cannot tell you that the recordings on that disk exist or play back: that is your own playback test, and nothing over the network replaces it.
Questions people actually ask
Why does the recorder not tell me the disk has failed?
Because most of these devices are built to answer, not to speak. Synology's own documentation states that DSM does not support SNMP traps, so the NAS cannot push an alert by itself even when the array is degraded. Many recorders are the same: the error is written on a page inside their web interface, which nobody opens between one incident and the next.
I have RAID. Is that not enough?
RAID survives a disk failing. It does not survive nobody noticing. A degraded array is a countdown: it works exactly as before until the second disk goes, and then it does not work at all. The value of RAID is entirely in the days between the first failure and the replacement, and those days only exist if someone is told.
What can actually be read from a recorder or a NAS over the network?
It depends on the model, and the honest answer is: what its manufacturer chose to publish. Commonly free space, disk health, the state of the array, temperature and how long the device has been running. Axis publishes an entry for storage disruption, Hikvision one for disk status, Synology documents its OIDs one by one. A probe inside your network asks for those values and follows them over time.
How much warning do I get before a volume is full?
Where the device exposes usage, we follow the trend every night and turn it into a date: full in about N days, with a heads-up at 14 days and again at 7. A disk that fills up is the most boring failure in this whole family, and also the easiest one to avoid entirely.
Does a silent reboot show up?
Yes, where the device reports how long it has been running: a counter that goes back to zero means the box restarted while you were not looking. On its own it is not a fault, but a recorder that restarts every few days is telling you something before it stops for good.