Playbook ~10 min read By The Compiler Whisperer · September 2026

Backing Up Microsoft Access: What Actually Works

There is a file on a machine in your company that your entire business reads from and writes to. It has a name like company.accdb, or maybe system.mdb, and it has not changed since 2011. When the boss asks "is the data safe," the honest answer is almost always: we copy the file sometimes.

That is not a backup. That is a file with good intentions. This is what an actual backup of an Access database looks like — and how to find out, right now, whether the one you have will survive contact with the day it is needed.

I have spent thirty years building and retiring exactly these systems, and the Access database is the one I have the most scar tissue around. It is the smallest failure surface that can destroy the largest part of a small business. Read this once, run the checklist at the end, and stop pretending the copy on the USB drive counts.

Why an Access file is the most fragile thing in your company

An Access database is a single binary file — one file holding your data, your tables, your macros, and (in the older .mdb days) much of the app logic. That is beautiful and it is the whole problem. A SQL Server instance or a SaaS tool is a system: a process, a log, a journal, a recovery mechanism. An Access file is a lump — and a single-file system has single-file failure modes.

The three ways these die, in the order I see them most:

• Unclean shutdown while it was open. Power loss, a forced reboot, a "blue screen" on the one machine that runs it. The JET engine is resilient, but it is not magic. A file that was mid-write when the machine died can be internally inconsistent in ways that don't show until a specific table is opened — or until the day you actually need to restore it.
• A bad USB drive, a bad network share, a bad disk sector. The file is sitting on media that has a failure mode, and the database is the one file that cannot be "regenerated." When the media fails, the file does not degrade gracefully. It goes from "fine" to "Access encountered an unreadable database" in one moment, and the moment is the worst one.
• A copy made while it was open. This is the one that surprises people, because Windows lets you copy the file even when Access has it open. The copy is not the database. It is a snapshot of whatever pages happened to be flushed at that instant. You have a file now that may not open, may be internally inconsistent, or may be silently missing the last hour of work. And because it is mostly right, you trust it until you don't.

If your current backup is "we copy the .mdb to a USB drive" or "it's on the network share and that counts," you have the third failure mode, and you are one bad week from discovering the first two.

What a real Access backup actually is

A real backup of an Access database has to be three things, and if it misses any one, it is not a backup:

• Closed. Made while Access is not running against the file, or made from a consistent snapshot the engine has given you. Never "copied while it was open."
• Verified. Opened at least once — ideally restored to a separate location and used read-only — so you know it will survive the day it is actually needed.
• Offsite, at least one copy. On a different physical machine, or in a location that cannot be hit by the same fire, flood, theft, or ransomware as the original. Same-building, same-rack copies are not offsite.

Most small-business Access "backups" miss at least two of these three. That is not a criticism of the person doing the copying — the Access UI does not make this easy, and nobody was ever handed a runbook. So here is the runbook.

The correct way to back up an Access database

1. Close every copy of Access, then compact and repair

The single highest-leverage step is the one almost nobody does: Compact and Repair Database. It forces the JET engine to re-validate the entire file, defragment it, and flush the page tables. If the file is already corrupt, this is the moment you will find out — and finding out on a Tuesday during backup is infinitely better than finding out during a restore at 7 a.m. on the day the machine dies.

In modern Access: open the database (read-only if you can), Database Tools → Compact and Repair Database. In the older 2003-era UI it is Tools → Database Utilities → Compact and Repair Database. If Access is running the app, you close the app first. If the file is open on a network share, you find and close every machine that has it open. There is no remote way around this in a local .mdb, and that is one of the reasons the file-based model is fragile in the first place.

2. Copy the compacted file, timestamped, to at least two locations

After compact-and-repair, the file is in its cleanest possible state. Copy it — with a timestamp in the name — to at least two locations, one of which is off the original machine. A timestamped name means you can roll back to "yesterday's good state" when you discover that this morning's copy is the one that's missing data.

A batch file is a legitimate tool here, and better than "remember to do it." This is the shape of it:

Two caveats about the batch approach. First, it does not replace compact-and-repair — if the file is open when the copy runs, you are back to failure mode three, and the copy is no better than a snapshot. Second, forfiles retention keeps you from running out of disk, but it also means you can lose the last several good copies if the file was bad for a week before you noticed. A human should glance at the log at least weekly for the first month after you set this up.

3. The offsite copy is the one that matters

The local copy is for "the drive died today, we need last night." The offsite copy is for "the building is gone" and, more commonly in the last decade, "ransomware encrypted everything on the LAN before the backup job ran." The offsite copy has to be on a different physical medium, ideally versioned, ideally immutable — meaning it cannot be overwritten or deleted by the same process that is currently attacking you.

For a small business, "offsite" has three realistic shapes, and the right one depends on where the file lives today:

• File lives on a desktop in an office. Offsite = a second machine, or a cloud storage service with versioning (OneDrive, Google Drive, a managed backup service). The versioning is the part most people skip, and it is the part that saves you when the bad write was three days ago, not last night.
• File lives on a local server. Offsite = the same, but scheduled from the server, and the retention policy should be at least daily for a month, weekly for a year, monthly for a few years — the shape of an audit trail, not just "last night."
• File lives on a managed host. If you have moved to a managed Windows host (the "contain" path I describe in the VB6 retirement playbook), the host's snapshot system is usually the cleanest offsite story — snapshots are taken at the hypervisor level, on the host's schedule, and are not affected by what is running on the guest. A Cloudways-managed instance ↗ gives you this for a database that needs to keep running, with backups handled at the infrastructure level instead of relying on a batch file on a machine in the corner. Affiliate link — I may earn a commission if you sign up; you pay the same price either way.

How to know if your backup will actually work

The single most valuable thing you can do with a backup is test it before you need it. This takes twenty minutes and it is the difference between "we have a backup" and "we have a recovery."

1. Restore to a different folder, not the original location. Copy the backup out to a test directory — a USB drive, a different share, anywhere that is not the production path. If you test-restore on top of the live file, you have just used the backup as a write, and you have learned nothing about whether the backup itself is good.
2. Open it. Run a report. Open the restored file in Access. Open every table you care about. Run the report that the boss looks at. Count rows. Sum the money columns. If the report you trust in production opens and shows numbers that look right, the backup is real. If it opens and one table is missing a column, you have just saved the business — the discovery was free.
3. Write down what you did. The exact steps, in the order you did them, in a file that is not on the same machine as the database. The next person to need this will be working under pressure, not planning calmly, and they will not remember that you tested with a different report than the one the boss wants.

If you can complete steps one and two without a phone call to anyone, you have a backup. If you cannot, you have a file, and it will let you down in the one month of the year when letting you down is most expensive.

The five mistakes I see in small-business Access backups

1. Copying while it was open. The file is a snapshot, not a backup. Close it, compact and repair, then copy. Every time. This is the mistake that turns a good backup into a bad one, and it is the one that is invisible until it matters.
2. Backing up to the same drive. A USB drive in the same drawer is not offsite. The same machine is not offsite. The same building is, depending on what you are afraid of, barely offsite. The copy that saves you is the one that cannot be destroyed by the same event as the original.
3. No versioning, or versioning that keeps too few. Overwriting "yesterday" with "today" means one bad write and you have lost the last good state. Keep at least 30 daily copies. For a business where the numbers feed a bank or a client, keep weekly copies for a year.
4. Testing only when it breaks. The first real test of a backup is the restore, and the restore is the day the machine is on fire. Test monthly. The test is free, and it is the only thing standing between "we have a backup" and "we have a story about a backup."
5. No runbook, and the knowledge is in one person's head. The person who set the backup up is the person who is about to retire, or has already retired, or is on a two-week holiday the week the drive dies. The steps, in writing, in a place the next person can find them, are the backup of the backup.

The red flags that mean your backup is not a backup

• "We copy the .mdb to a USB drive sometimes" — sometimes is a schedule you will forget in the busiest month of the year
• The backup is on the same machine as the database
• The backup is on the same building as the database and you have never thought about what "same building" means for a fire
• You have never opened the backup and run a report from it
• The only person who knows where the backup is, or how to restore it, is leaving — or has left
• A new hire asks "what if the file gets corrupt" and the answer is a shrug
• Any two of the above: fix this month. All of them: fix this week, before the month-end close.

A 15-minute checklist you can run today

1. Close every copy of Access on every machine. Yes, all of them. Including the one on the sales director's laptop that "just happens" to have the file open.
2. Open the file, Compact and Repair, let it finish, close it. If it fails, stop — the file is already in trouble and you need to talk to the person who built it before you do anything else.
3. Copy the compacted file, with a date-stamped name, to two locations — one local, one offsite. If you do not have an offsite location, set that up before you do anything else in this article; the rest of it is worthless without it.
4. Restore the offsite copy to a test folder. Open it. Run the report the boss trusts. Count the rows. Close it.
5. Write the steps down. Five lines is enough. Put the file where the next person will actually find it, not in a folder called "misc."

That is the whole thing. It is not glamorous. It will not show up on a slide. But it is the difference between a company that survives the day the machine dies and a company that spends the next three months reconstructing a ledger from bank statements and email threads.