Every Access developer has a backup strategy. Most of them are wrong.

The typical approach is to copy the .accdb file to another folder, maybe a USB drive, maybe a network share. That works — until it doesn’t. And it usually stops working at the worst possible time: right after a corruption event, right after someone accidentally deletes a table, right after an update breaks something that was working fine yesterday.

Here is how to back up an Access database properly.

Why “Just Copy the File” Is Not Enough

Copying an Access database file while it is open is dangerous. Access uses a locking file (.laccdb) to manage multi-user access, and the database may be in the middle of a write operation when you copy it. The result can be a backup file that is already corrupted before you ever need it.

You also have the problem of split databases. If your application is properly split — a back-end .accdb with the data tables and a front-end .accdb with forms, reports, and queries — copying just one file gives you half a backup. Miss the back-end and you have forms with no data. Miss the front-end and you have data with no way to use it.

Step 1: Get Everyone Out

Before backing up, make sure no one is using the database. Check the .laccdb file — if it exists and has content, someone has the database open. You can also check for connections using the Access UI under Database Tools > Database Connections (in newer versions).

If you cannot get everyone out during business hours, schedule backups for off-hours. An automated script that runs at 2 AM when nobody is connected is far more reliable than a manual copy during lunch.

Step 2: Compact Before You Back Up

Access databases accumulate bloat over time. Deleted records leave empty space in the file. Temporary objects come and go. The file grows and grows even if the actual data has not changed much.

Compacting the database before backing it up does two things: it reduces the file size (sometimes dramatically), and it rewrites the internal structure, which can fix minor corruption before it becomes major corruption.

In Access: Database Tools > Compact and Repair Database.

From the command line or a script, you can use the JetComp.exe utility or automate it with VBA or PowerShell.

Important: Never compact a database while users are connected. This is a single-user operation.

Step 3: Back Up Both Pieces of a Split Database

If your database is split (and it should be if more than one person uses it), you need to back up:

Back up both files. Store them together. Label them clearly with the date and time.

Step 4: Test Your Backups

A backup you have never tested is not a backup — it is a hope. At least once a month, take your most recent backup, copy it to a test location, open it, and verify that:

This takes five minutes and will save you from the nightmare of discovering your backups are corrupt when you actually need them.

Step 5: Keep Multiple Versions

Do not overwrite the same backup file every time. Keep at least a week’s worth of daily backups, plus monthly backups going back several months. Corruption sometimes goes unnoticed for days or weeks. If your only backup is from yesterday and the corruption started three days ago, your backup is also corrupt.

A simple naming convention works: MyDatabase_2026-06-23.accdb, MyDatabase_2026-06-22.accdb, and so on. Automate this with a script so you do not forget.

Step 6: Store Backups in a Different Location

A backup on the same hard drive as the original is not a backup — it is a second copy that dies in the same hardware failure. At minimum, keep backups on a different physical drive. Better: a different machine. Best: offsite or cloud storage.

For small Access databases (under 500 MB), cloud sync services like OneDrive, Google Drive, or Dropbox can work for backup storage. Just make sure you are copying the backup file there, not trying to run the live database from a cloud-synced folder. Running Access from OneDrive or Dropbox is a recipe for corruption.

Automating the Whole Thing

The best backup is one that happens automatically. Here is a basic approach using Windows Task Scheduler and a PowerShell script:

  1. Create a PowerShell script that checks for active connections, compacts the database, copies it to the backup location with a date-stamped filename, and deletes backups older than 30 days.
  2. Schedule it to run daily during off-hours using Windows Task Scheduler.
  3. Set up email notifications so you know if the backup fails.

This removes human error from the equation. You do not have to remember to back up. You do not have to remember to test. The script does it every night.

When Backups Are Not Enough

If your Access database is critical to your business and data loss is unacceptable, backups are a safety net — not a solution. Server databases like SQL Server, MySQL, and PostgreSQL offer point-in-time recovery, transaction logs, automated backup scheduling, and replication. They are designed for the scenario where losing even one hour of data is too much.

If you find yourself worrying about backups constantly, it may be time to move the data to a database that was built for reliability from the start.