A Guide to Backing Up an Access Control System, Including the 5 Things Almost Nobody Backs Up

Access Control: Back Up My What?

There’s a piece of standing advice in this industry that we’ve given for years, and that we’re going to revise in this article: back up your access control database when the clocks change, so you always have a copy less than six months old.

It’s not bad advice. It’s better than what most facilities do, which is nothing. But we’ve watched enough recoveries go badly to know that it’s the beginning of a backup strategy, not the whole of one — and that the twice-a-year cadence quietly encodes an assumption that turns out to be wrong for most buildings.

Why a 6-Month-Old Backup is a Security Problem, Not Just an Inconvenience

Think about what you’d actually be restoring.

If your organization adds or removes twenty cardholders a month, a six-month-old backup contains roughly 120 stale records. Restoring it doesn’t just cost you the new hires — it reactivates every credential you deliberately revoked in the last six months. Every termination. Every contractor whose project ended. Every lost badge you disabled.

That’s not a data loss event. That’s a self-inflicted access control breach, executed at the exact moment your team is stressed, improvising, and least likely to notice.

The IT world has vocabulary for this. Recovery Point Objective (RPO) is how much data you can afford to lose — how far back in time you’re willing to be thrown. Recovery Time Objective (RTO) is how long you can afford to be down. Most facilities have never set either for their access control system, because they’ve never thought of it as a system with data in it.

For a building with active cardholder churn, a realistic RPO is 24 hours, which means nightly automated backups — not a manual copy at the time change. The twice-a-year checkpoint still has a job, and we’ll get to it. It just isn’t the backup itself.

Your Doors Will Probably Keep Working. Your Ability to Change Anything Won't.

Here’s something that surprises people when the server goes down: nothing happens at the doors.

Nearly every modern access control panel stores its own copy of the cardholder list, access levels, and schedules, and makes its own decisions. The server pushes updates down to the panels; the panels don’t ask the server for permission on every badge read. So when the head-end dies — hard drive, ransomware, a failed Windows update — the building keeps granting and denying access exactly as it was configured at the moment of the last sync. Unlock schedules keep running on the panel’s clock. Most people in the building never notice.

That sounds reassuring, and it is, up to a point. But it means the actual emergency is quieter than a lockout, and it gets worse every day:

You can't revoke anyone. The badge of the employee terminated this morning works until the server is back.
You can't add anyone. New hires and contractors get propped doors and borrowed cards, which is its own problem.
Events pile up in the panel. Panels buffer badge reads and alarms in local memory while the server is unreachable, but that memory is finite. Depending on the panel and how busy the door is, it can hold days of events or hours. When it fills, the oldest events are typically overwritten — and there is a permanent hole in your audit trail.

That’s what your RTO should actually be measured against: not “how long until the doors work,” but “how long can we go without being able to revoke a credential” and “how long until the panels start dropping history.” For most facilities, the honest answers are a day or two, and less time than they’d guess.

Not every system behaves this way. Some older platforms are server-dependent, and don’t assume you can rebuild the server from the panels; most platforms can’t. Ask your integrator 1.) what do the panels do when they lose the server, and 2.) how long does their event buffer last at our read volume. Write the answers in the runbook.

What's Actually in an Access Control Database

This is the part that changes how people think about the problem. Most administrators picture “a list of who has a badge.” The database is considerably more than that, and each category has a different recovery cost.

Identity & Credential Data

Access Logic (the Expensive Part to Rebuild)

Hardware Configuration

History

Administration

Access Control Backup Case Study

Example: “Earlier this year, our team was contacted by [local company] for help with an access control system backup.”

5 Things a "Complete" Backup Usually Misses

This is the section worth printing out. Every one of these has produced a restore that technically succeeded and practically failed.

1. Badge Photos & Templates Stored Outside the Database

Many platforms store cardholder photos and badge layout templates as files in a folder on the server, not as rows in the database. Back up the SQL database only, and you restore a fully functional system that cannot print a single badge and has no photos for guard verification.

Find out where your platform puts these and confirm they’re in the backup scope. More on this in the table below:

Access Control Platform	Badge Photos / Layout Templates Storage Location	Built-In Backup Utility?
Access Control Platform Genetec Synergis	Badge Photos / Layout Templates Storage Location Stored on the file system in dedicated server folders (e.g., ...\Genetec Security Center\Web\Photos or local vault paths) rather than directly inside the core SQL tables.	Built-In Backup Utility? Yes. Configurable scheduled database backups via Server Admin, though external file folders (photos/badge templates) must be included in regular file-level server backups.
Access Control Platform Software House C•CURE 9000	Badge Photos / Layout Templates Storage Location Badge photos and graphic layouts are stored on disk as flat image files within dedicated system subdirectories on the application server.	Built-In Backup Utility? Yes. Native database maintenance and automated backup features built into the C•CURE 9000 Administration Workstation.
Access Control Platform LenelS2 OnGuard	Badge Photos / Layout Templates Storage Location Image files and card layout design templates are kept in specific file directories on the server (e.g., system \Images or \Templates folders).	Built-In Backup Utility? Yes. Built-in Database Backup utility provided via the License/System Manager tools.
Access Control Platform Avigilon Access Control Manager (ACM)	Badge Photos / Layout Templates Storage Location Appliance/Linux-based platform; photo files and templates are managed internally within the appliance file system structure.	Built-In Backup Utility? Yes. Built-in automated backup function via the web interface (supports scheduled push to remote FTP/SCP/SFTP servers).
Access Control Platform Kantech EntraPass	Badge Photos / Layout Templates Storage Location Cardholder pictures and badge layout files reside in dedicated system folders (e.g., ...\EntraPass\Images) on the server.	Built-In Backup Utility? Yes. Integrated automated backup scheduler for system configuration, cardholder data, and event logs.
Access Control Platform Feenics (Cloud)	Badge Photos / Layout Templates Storage Location Hosted securely in cloud storage containers managed automatically by the SaaS infrastructure.	Built-In Backup Utility? N/A (Managed Cloud). Vendor handles database/file backups automatically; manual CSV exports available for offline roster retention.

2. License & Activation Files

Software licenses, door-count licenses, and activation keys are frequently tied to a machine, a dongle, or a file that lives outside the database.

Restoring to new hardware without them means calling the manufacturer during an outage and proving entitlement — which takes as long as it takes.

3. Encryption Keys & OSDP Secure Channel Keys

If your readers run OSDP in secure channel mode, the keys matter. Losing them can mean physically re-pairing readers, door by door, on foot.

4. Integration Credentials

API keys, service account passwords, and directory sync configuration. These aren’t secret from you — they’re just undocumented, and the person who set them up may not be there.

5. The Knowledge that Never Lived in a Computer

Which panel serves which door. Which closet the head-end is in. What version and patch level you were running. Who your dealer is and what your support contract number is. Where the as-built drawings are. Nothing restores this but a written runbook, and it’s the single highest-value hour of documentation work available to a facility manager.

We’d suggest a one-page system recovery runbook, printed and stored somewhere that doesn’t depend on the network being up:

Software platform, version, patch level, and license/activation location
Server name, IP, OS version, and where database credentials are stored
Panel/controller IP scheme and physical locations
Backup location, schedule, and restore procedure
Dealer name, support contract number, and after-hours phone
Location of as-built drawings and riser diagrams
Manual override plan: how the building opens if the system is down

On Cloud Access Control? This Still Applies to You

A common and understandable assumption: we moved to a cloud platform, so backup is the vendor’s problem now.

Partly true. The vendor almost certainly handles database redundancy, replication, and infrastructure recovery better than a server in your electrical room ever did. That’s a genuine advantage and one of the better reasons to move.

But it changes what you’re responsible for rather than eliminating responsibility:

Your account access is still yours to protect. If the administrator who owns the account leaves — or their SSO identity is disabled — you need documented recovery. More than one organization has been locked out of its own access control platform by an HR offboarding.
Export your cardholder roster and access level configuration periodically. Most platforms support CSV export. Do it quarterly and store it outside the platform. This protects you against the scenarios cloud redundancy doesn't cover: a billing lapse, a vendor going out of business or being acquired, your own administrator deleting the wrong group, or a migration to a different platform.
Document your integrations and API keys. Same as on-prem.
Have an offline plan. Cloud access control depends on internet connectivity. Most controllers cache credentials locally and keep working, but you should know for a fact what your system does during an outage — how long the cache holds, whether new events queue, and how the building opens if it fails. Test it once. Ask your integrator to walk you through a simulated WAN outage.
Read the retention terms. How long does your vendor keep event history? If your insurer, regulator, or legal counsel expects three years of audit trail and your plan retains one, that gap is yours, not theirs.

The Ransomware Problem Nobody Plans For

On-premises access control servers have a specific and unflattering risk profile, and it’s worth being blunt about it.

They are often Windows machines that were commissioned years ago and never touched again. They sometimes run an operating system past end of support, because the access control software wasn’t validated on anything newer. They frequently run SQL Server Express. They are joined to the corporate domain. And — this is the important part — they are often missing from IT’s asset inventory entirely, because the system was bought by facilities or security, not IT, and nobody ever added it to the patch schedule.

That’s an appealing target. And if your backup writes to a share on the same server or the same domain, ransomware encrypts the backup along with everything else.

The standard countermeasure is the 3-2-1 rule: three copies of the data, on two different storage types, with one copy offsite. The modern extension is 3-2-1-1-0: one copy immutable or offline, and zero errors on verification.

Practically, for an access control server:

Automate the backup — nightly, not manual.
Write to at least one destination that isn't on the same machine or reachable with the same credentials.
Keep one copy immutable or air-gapped (see below for what that means in practice).
Encrypt backups both in transit and at rest — the older practice of encrypting only the offsite copy assumed on-network copies were safe, and that assumption no longer holds
Restrict who can access the backup location, and require MFA.
Get the server into IT's inventory and patch cycle, even if facilities owns the budget.

What Immutable Means When You Don't Have an IT Department

An immutable backup is one that can’t be changed or deleted for a set period — not by ransomware, not by a mistake, and not by an administrator with the password. That last part is the point. If your backup can be deleted by anyone who gets into your account, it isn’t immutable, it’s just stored somewhere else.

For a facility with a few dozen doors and no IT staff, there are three practical ways to get there, roughly in order of effort:

A cloud storage bucket with object lock turned on.

Most cloud storage providers offer a setting (usually called “object lock,” “immutability,” or “retention lock”) that prevents files from being deleted or overwritten for a period you choose — 30 days is a reasonable starting point. Point your nightly backup at it. For a database this size, storage costs are trivial, typically a few dollars a month. Most backup software made in the last several years can write to this kind of storage directly; if yours can’t, that’s worth knowing.

A rotated external drive that lives in a safe.

Two inexpensive USB drives. One is plugged in for the weekly backup; the other is in a fireproof safe, in a different building if possible. Swap them on a schedule. A drive that’s in a safe can’t be encrypted by malware that’s on your network — but a drive that stays plugged in all the time can. The disconnection is the protection.

A copy held by your integrator.

If a security integrator manages your system, ask whether they retain a copy of your database and how often it’s refreshed. This shouldn’t be your only copy, but it’s a reasonable third one.

Two things that do not count as immutable, even though they feel safe: a network share or NAS on the same network as the access control server, and a second folder on the same machine. If it’s reachable from the server with the server’s credentials, ransomware can reach it too.

A Backup You Have Never Restored is Not a Backup

This is the uncomfortable core of the whole subject. According to a Macrium Software survey, roughly 46% of organizations have never tested a restore — and the moment you discover a backup is corrupt, incomplete, or missing the badge photo folder is invariably the moment you need it.

Testing means running full restore tests to confirm the data comes back complete and operational, in an isolated environment where the test can’t disrupt the live system. For access control specifically, we’d suggest an annual drill:

1.) Restore last night's backup to a test VM or spare machine — not production.
2.) Confirm the software launches and reads the database.
3.) Spot-check ten cardholders, including one you know was revoked recently.
4.) Confirm access levels and time schedules are intact.
5.) Confirm badge photos and templates render.
6.) Confirm event history is present back to your retention requirement.
7.) Time it. Write down how long the whole thing took. That number is your real RTO, and it's usually two to three times what people guess.
8.) Write down everything that went wrong. Fix it. That's the point of the drill.

If your integrator manages your system, this is a reasonable thing to ask them to perform and document annually.

Don't Let Event History Quietly Break Your System

SQL Server Express has a 10 GB per-database limit on 2022 and earlier versions, which is what most access control installations are running. SQL Server 2025 Express raised it to 50 GB, but the pattern is the same; the ceiling is just further away.

Many small and mid-sized access control installations run on Express because it’s free and included. Event history accumulates every badge read, every door held open, every alarm — for years. When the database hits the ceiling, the system stops writing. Depending on the platform, that can mean logging silently stops, backups fail, or the application refuses new records.

Nothing announces this. The doors keep working. You find out during an investigation, when you discover your audit trail ends fourteen months ago.

Check Your Database Size This Quarter

If you’re above roughly 7 GB on Express, you need a plan: an archiving/purge policy, or a move to a licensed SQL edition. And set that purge policy deliberately — see the next section, because deleting history has its own consequences.

Retention, Privacy, & the Part to Run Past Your Counsel

Two things people underestimate:

Your Event History May Be a Record You're Required to Keep

Depending on your industry, audit trails can be subject to retention obligations. This includes healthcare, pharmacy and controlled substances, critical infrastructure, cardholder data environments, child care and education, and anything covered by a specific insurance rider. For example, HIPAA requires security documentation to be retained for six years, and PCI DSS requires audit log history to be kept for at least 12 months with the most recent three months immediately available.

Before you configure automatic purging to solve a database size problem, confirm the retention period with whoever owns compliance in your organization.

Your Backups Contain Personal Information

Names, employee IDs, photographs, sometimes biometric templates. A stolen backup file is a data breach in exactly the way a stolen laptop is, and it may trigger state notification obligations. Encrypt them, restrict access, and include them in whatever data inventory your organization maintains. If you handle biometrics, get specific legal guidance — biometric data is treated distinctly under a growing number of state laws — Illinois, Texas, and Washington each have a dedicated biometric statute.

We’re a security integrator, not a law firm; treat the above as a prompt to ask the right question, not as legal advice.

A Realistic Backup Schedule

Here’s what a realistic backup schedule looks like:

Frequency	Task
Nightly (automated)	Full or incremental database backup to a destination not on the access control server
Weekly (automated)	Backup of external assets: badge photos, templates, license files, config exports
Monthly (5 min)	Confirm backups are actually running and completing without errors. Check the log, not the schedule.
Quarterly (30 min)	Export cardholder roster and access levels to CSV, stored offline. Check database size against limits. Reconcile active cardholders against your current employee roster.
Twice a year — the time change (1 hr)	Review the recovery runbook and update anything stale: versions, contacts, IP changes, personnel changes. Verify offsite/immutable copy exists and is readable.
Annually (half a day)	Full restore test to an isolated environment. Time it. Document failures.

The time-change checkpoint survives — but its job is now reviewing the runbook and verifying the offsite copy, not being your only backup. That’s a much better use of a reminder that everyone already has.

One practical note: anchor these to a recurring calendar reminder rather than to the clock change itself. The House passed a bill to make daylight saving time permanent in July 2026, and a maintenance schedule that depends on the clock change is a schedule with an expiration date.

Frequently Asked Questions (FAQs)

Here are some of the most commonly asked questions that we get about access control backups:

How often should I back up my access control system?

Nightly, automated, for any system with regular cardholder changes. Twice-yearly manual backups are a floor, not a target — a six-month-old restore reactivates every credential you revoked in that window.

We're on a cloud access control platform. Do I still need backups?

The vendor handles infrastructure redundancy. You still own account recovery, periodic roster and configuration exports, integration credentials, retention terms, and an offline contingency plan. Export quarterly and store it outside the platform.

What's the most commonly missed item in an access control backup?

Badge photos and templates, because many platforms store them as files outside the database. Close behind: license and activation files.

How long does it take to rebuild an access control database from scratch?

It depends entirely on size and complexity, but for a mid-sized system with several dozen doors and a few hundred cardholders, plan on days rather than hours — and note you may not be able to recover event history at all.

How do I know my backup actually works?

Restore it to an isolated test environment and verify cardholders, access levels, schedules, badge photos, and event history. If you haven't done that, you have a backup file, not a backup.

Should my access control server be managed by IT or facilities?

Facilities usually owns the budget and the operational need; IT owns patching, backup infrastructure, and network security. The failure mode is when neither believes they own it. Name an owner in writing.

Reach Out for Commercial Access Control Solutions

Lappen Security Products has been proudly serving our community since we first opened our doors in 1953. If your business needs commercial access control services, please don’t hesitate to reach out to our team today to talk about cloud-based management, mobile entry, integrated security, and more.

About the Author

With [X] years in the security industry, Certified Registered Locksmith Matthew Bent provides tailored access control and key management solutions for municipal, healthcare, industrial, and commercial facilities throughout the Fox Valley.

He is backed by Lappen Security Products—an authorized Medeco dealer servicing Green Bay, Appleton, Neenah, Little Chute, and the greater region.