The value of a security system is not in the hardware. It is in the configuration: the cardholders, the access levels, the schedules, the door behaviour, the alarm routing, the camera settings and the years of accumulated exceptions that make it fit the building.
Hardware can be bought again in days. Configuration built up over a decade cannot be recreated at all, because the reasoning behind most of it was never written down and the people who knew it have moved on.
That is the actual exposure, and it is why a backup strategy for a security platform is a different exercise from a backup strategy for a file server. What follows is what has to be captured, why jobs that report success still fail, and how to prove the thing works.
What a complete backup actually contains
Backing up the application database is necessary and, on its own, insufficient. Each of these lives somewhere the database backup does not reach.
The application database
- The configuration database, taken with the engine-aware method rather than by copying files from under a running service.
- The event or journal database, if it is separate, and a stated retention for it.
- Any audit database, which is often separate and often forgotten.
Assets stored outside the database
- Cardholder photographs, where the platform stores them on the file system.
- Badge templates, layouts and any imported artwork or fonts they depend on.
- Custom report definitions and saved queries.
- Maps, floor plans and graphic interface files.
Licences and identity
- Licence files and entitlement details, including the machine binding if the licence is tied to hardware.
- Certificates and their private keys, with expiry dates recorded.
- Service accounts, what each runs, and where the password is held securely.
- The version of every component, because a backup you cannot match to a version is difficult to restore.
Device-resident configuration
- Controller firmware versions and the configuration downloaded to each panel.
- Camera-side settings, which on most platforms live on the camera and not in the video management software: exposure, focus, privacy masking, stream profiles, overlays.
- Switch and storage controller configuration where security infrastructure depends on it.
- Intercom, elevator and intrusion panel configuration touched by the integration.
Integration and server context
- Integration configuration files and connection settings that live on disk rather than in the application.
- Scheduled tasks, including the backup job itself.
- Registry or configuration entries changed during commissioning.
- The as-built notes: panel address map, door schedule, IP schedule held as a document, not in someone’s memory.
Ways a backup reports success and is worthless
It was written to the same array as the source. The array is what fails. A backup that shares a failure domain with the thing it protects is a copy, not a backup.
The job ran but the database was skipped, because a file-level agent could not read a file held open by a running service. The job reports success because every file it could read, it read.
The job has been failing for months and the notification goes to a mailbox nobody monitors, or to a service account whose password expired and which now fails authentication before it reaches the notification step.
The backup is complete and cannot be restored, because the licence file was never captured, or nobody recorded which software version produced it, or the media is a format for which no reader remains on site.
The retention is shorter than the time it takes to notice corruption. If the only copies are from the last seven days and a configuration error was introduced three weeks ago, every copy contains it.
A workable backup discipline
- 01 Back up before and after every change — Not only on schedule. The copy taken immediately before a firmware update or a configuration change is the one that gets used.
- 02 Keep three copies, on two kinds of media, one off site — The old rule survives because the failure modes it addresses have not changed. On site and off site is the part most commonly missing.
- 03 Hold at least one copy yourself — If the only backups are with a service provider, your ability to recover depends on a commercial relationship. Written into the agreement, this is straightforward to arrange.
- 04 Alert on the absence of success, not only on failure — A job that stops running produces no failure message. Monitor for a fresh backup file of a plausible size, and alert when one does not appear.
- 05 Record the version alongside every copy — A single text file next to the backup naming the application version, database engine version and OS removes an hour of guesswork during a recovery.
- 06 Rehearse a restore annually — To an isolated instance, from the actual backups, following the written procedure. Time it. Fix whatever the rehearsal reveals, because it always reveals something.
- 07 Keep a change log — Date, who, what changed and why. Restoring to the right point requires knowing what happened between the points.
The special case of panel-resident data
Access controllers hold a working copy of what they need to make decisions without the head end: cardholders, access levels, schedules and door configuration. That is a resilience feature and it is often mistaken for a backup.
It is not one, and the direction matters. Normally the head end is authoritative and the panels are downstream, so a replaced panel is re-downloaded and back in service in minutes. But if the head-end database is lost and no restorable backup exists, the panels are suddenly holding the only surviving copy of the configuration, in a form that is not designed to be read back out. Recovery in that situation ranges from partial to impossible depending on the platform, and it is invariably slower and more expensive than the backup would have been.
The related trap is a panel replaced without confirming the download completed afterwards. It shows online. It is not enforcing what you think it is enforcing. Verify with a real credential at a real door rather than with a status indicator, as covered in common causes of offline access-control panels.
Where this fits
Backup verification belongs in whatever is watching the rest of the server layer, alongside array health and volume free space, because all three fail quietly and all three are only expensive at the moment of need. See why security servers and storage should be monitored.
Custody of backups, and your right to hold and restore your own configuration without depending on a provider, belongs in the service agreement rather than in an informal arrangement. See what to include in a security-system service agreement.
Prove the backup before you need it
A restore rehearsal to an isolated instance establishes whether you can actually rebuild, and how long it takes.