About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Plenty of small businesses depend on a Microsoft Access database: a quoting tool, a stock register, a job book built years ago. It often sits in a shared folder on a file server, and the folder is included in a nightly backup. That feels safe. But an Access database is a live, multi-user file, and Microsoft's own guidance treats backing it up as something done with users out of it.
This guide is for owners and administrators who look after one of these databases. It explains what Microsoft recommends, why copying an open file is a risk, how a split database changes what you back up, and how to check and rehearse a restore without touching the live file.
Why it matters
Microsoft's backup page is blunt about the stakes: "Without a backup copy, you cannot restore corrupted or missing objects or any changes to the database design." It adds that "Creating backups on a regular basis is especially important when you have several users updating a database."
Some mistakes cannot be undone inside Access. Microsoft gives an example: "when you use an action query to delete records or to change data, any values that were updated by the query cannot be restored by using Undo ." Its tip is to back up before running such a query.
Corruption is also a known risk. The compact and repair page says that database files "can also occasionally become corrupt or damaged." It explains one cause: "When a user starts to change data and the change is interrupted — for example, because of network service loss — Access marks the database file as corrupted." A file share adds network paths to every user's edits, so this is relevant to shared databases (our reading).
Why copying an open database is a risk
Microsoft's guidance assumes the database is closed when it is backed up: "If your database has several users, before you perform a backup make sure that all users close their databases so that all changes to the data are saved."
A file-level backup of the shared folder at 2 am does not check this. If someone left Access open overnight, or a scheduled task is writing, the copy may capture a file mid-change (our understanding). Access stores tables, queries, forms and code in a single file, so a damaged copy may affect more than one table (our reading).
Two practical points follow (our recommendation):
- Schedule a controlled pause, confirm users and every other writer are out, and obtain the exclusive access required by the chosen backup method. A closing reminder alone does not establish that condition. Check that each run completed a current capture; alert on skipped files or incomplete jobs.
- Keep several generations and record the recovery point for each successful capture. Restore the exact protected copy into an isolated test and compare it with a report or synthetic fixture representing that recovery point, rather than today's changing live database.
Do not use the presence or absence of a neighbouring lock file as proof of exclusive access. Confirm the database state through the supported backup method and its result. Do not delete a lock file to try to obtain exclusivity.
Split databases: what to back up
Microsoft recommends splitting shared databases. The split article describes the result: "a back-end database that contains the data tables, and a front-end database that contains all the other database objects". It adds that "Each user interacts with the data by using a local copy of the front-end database."
Microsoft lists reliability as a reason: "if a user encounters a problem and the database closes unexpectedly, any database file corruption is usually limited to the copy of the front-end database that the user had open." And, "Because the user only accesses data in the back-end database by using linked tables, the back-end database file is much less likely to become corrupted."
This changes the backup plan. The backup page says: "Because the back-end database contains the data, it is more important to make regular backups of the back-end database. Make a backup of the front-end database when you change its design." It also notes that "Individual users of the front-end database can make arbitrary design changes, so consider requiring the users to make their own backup copies of the front-end database."
For the back end, Microsoft expects exclusive access: "Notify users before you start the backup process because running the backup process requires exclusive access to the database file, and users might be unable to use the back-end database while the backup process is running."
So a sound plan for a split database has three parts (our recommendation):
| Part | Where it usually lives | When to back up |
|---|---|---|
Back end (_be file with the tables) |
Shared network folder | Regularly, with users out |
| Master front end (the version you hand out) | Wherever you keep the master copy | After every design change |
| Users' own front-end changes | Each user's computer | Only if those changes matter; Microsoft suggests users keep their own copies |
The split wizard keeps the original name and, in Microsoft's words, indicates the back end "by inserting _be into the name, just before the file name extension". That helps identify which file holds the data (our reading).
Linked tables and the restore location
Restoring a split database to a different path has a catch. Microsoft warns: "If other databases or programs have links to objects in the database that you are restoring, it is critical that you restore the database to the correct location. If you do not, links to the database objects will not work and will have to be updated." The split article notes that "You can use the Linked Table Manager to change the back-end database that you use."
Record the back end's full network path in your recovery notes, so a restore can return it to the same place or so the links can be updated deliberately (our recommendation).
If linked tables point to another program, Microsoft says to "create backups by using any available backup features in the program that contains the linked tables."
Compact and repair needs its own backup
Compact and repair is routine maintenance, and it is also how Access tries to recover a damaged file. Microsoft's guidance is clear on preparation.
- Back up first. "During the repair process, Access may truncate some data from tables that are damaged. It is sometimes possible to recover this data from a backup." And: "In addition to your regular backup strategy, you should make a backup immediately before you use the Compact and Repair Database command."
- Get exclusive access. "A compact and repair operation requires exclusive access to the database file, because the operation may disrupt other users."
- Check partial repairs. "If Access is only partially successful, it keeps track of database objects that it could not repair in a system table named MSysCompactErrors ."
Microsoft offers a Compact on Close option, but cautions: "In multiuser databases, you might not want to set this option, because it can momentarily disrupt database availability."
A pre-repair copy matters most when the file is already damaged: it is the evidence of what existed before Access truncated anything (our reading).
How Microsoft's own backup command works
Access has a built-in Back Up Database command. Microsoft explains that "Access saves and closes objects that are open in Design view and saves a copy of the database file by using a name and location that you specify." The default name "captures both the name of the original database file and the date that you make the backup", and Microsoft calls keeping it "good practice".
For a back end, Microsoft's steps open it with Open Exclusive before choosing Back Up Database. This is a manual process; for unattended copies, the file-level backup with users out is the usual route (our understanding).
Filesystem and SMB inspection
The following PowerShell listings inspect files and SMB handles without opening the Access database. Run them on Windows with the documented modules and sufficient permissions. Opening or relinking an Access copy is a separate test below, not a guaranteed no-write check.
List Access files and lock files in the share, with sizes and times:
Get-ChildItem -Path '\\server\share\AppFolder' -File |
Where-Object { $_.Extension -in '.accdb','.laccdb','.mdb','.ldb' } |
Select-Object Name, Length, LastWriteTime
Treat this as a file inventory only. Names, sizes, timestamps and lock-file presence do not establish a consistent backup or exclusive access.
See who has files open on the server (run on the file server itself, as an administrator):
Get-SmbOpenFile | Where-Object { $_.Path -match '\.(accdb|mdb)$' } |
Select-Object ClientComputerName, ClientUserName, Path
Microsoft documents Get-SmbOpenFile as information about files opened on behalf of SMB clients. It does not enumerate every possible local process writing on the file server, and permissions or scope can limit the view. An empty result is not proof of exclusivity. Do not close sessions as part of this inspection. The first listing uses the documented Get-ChildItem filesystem command.
Compare backup copies with the live file: in your backup tool, list the generations held for the back-end file and note their sizes and times. A sudden drop in size, or copies taken while users were active, deserve a closer look (our reading).
Find the expected back-end path: first use existing deployment or recovery records. If Access must be opened to inspect links, use the isolated-copy procedure below. A copied front end can retain live links and run startup code; putting it in a different folder does not stop that access.
These checks identify files and visible handles. Filesystem modification times are not proof of backup capture time; use successful job records for that. Neither listing proves that a protected copy opens cleanly.
Safe restore rehearsal
Rehearse on a disposable test computer with production shares, database endpoints and other production network paths blocked before opening any Access front end. Use synthetic test data or an appropriately protected authorised test copy. A separate folder that users cannot reach is insufficient isolation. Never overwrite the live file or the only backup (our recommendation).
- Select a successful, dated back-end backup and its matching master front end. Record the job identity and expected records at that recovery point; keep the protected originals unchanged.
- Restore working copies into the isolated test environment. Confirm it cannot reach production or send business messages before launching Access.
- Control startup content. Microsoft's AutoExec documentation describes holding Shift while opening to bypass AutoExec and other startup options. Have the application maintainer confirm that the documented method is effective for this database; if it cannot be safely bypassed, stop and obtain a reviewed test copy. Network isolation remains required even with a bypass.
- Inspect and relink every linked table to test data using the Linked Table Manager. Review startup macros, forms and external connections with the maintainer before enabling normal application behaviour. Relinking changes the working front end; it is not a read-only operation.
- Check record counts against the saved recovery-point baseline, then test the main forms and reports only against test data. A current production report can legitimately differ from an older recovery point.
- Rehearse maintenance only on a further disposable copy. Preserve a pre-repair copy before a qualified maintainer tests Compact and Repair; check for MSysCompactErrors and compare records afterwards. This article supplies no production repair procedure or lab-validated result.
- Record elapsed time, missing dependencies and any paths or credentials that delayed recovery, without putting secrets in the report.
Diagnosing what you find
- The restored copy will not open or reports damage: it was copied while someone had it open; the file was already damaged before the backup; or the copy was interrupted.
- Forms open but show no data or a link error: the front end still points at the old path; the test back end has a different name; or the user lacks rights on the test folder.
- Recent records are missing: the newest backup was skipped because the file was in use; the backup ran before the day's work ended; or users work in local copies of a single-file database rather than a shared back end.
- Compact and repair reports errors: the copy holds damaged tables; data was truncated, so compare with an older generation; or an older file format is involved.
Worked example (illustrative)
The following is invented. A plumbing business runs its job book on an Access back end on the office server, and the server's folder is backed up each night. After a power cut, the back end will not open.
In an isolated rehearsal, the team selects what looks like last night's backup set. Its job record shows that the in-use database was skipped, so the available database file actually comes from the previous successful capture two nights earlier. It opens, but later jobs are missing. The team measures that data gap against dated job records and plans how to re-enter the missing work. For future runs, a closing reminder is followed by verified writer shutdown and exclusive access, a completed current backup check and alerts for skips. They retain seven generations and test the exact protected copy against a recovery-point baseline. The number of generations alone does not prove freshness.
Risks and limits
- Data in SharePoint lists or a database server needs that system's own backup.
- Backup tools vary in how they handle files in use; check yours.
- Lock-file presence and SMB listings do not prove that all writers are stopped. Opening a front end can execute code and follow links; isolate before opening.
- No command was run in a lab. Test first in an isolated environment.
Sources
All accessed 14 November 2026.
- Microsoft Support, Protect your data with backup and restore processes: https://support.microsoft.com/en-us/access/protect-your-data-with-backup-and-restore-processes
- Microsoft Support, Compact and repair a database: https://support.microsoft.com/en-us/access/compact-and-repair-a-database
- Microsoft Support, Split an Access database: https://support.microsoft.com/en-us/access/split-an-access-database
- Microsoft Support, Ways to share an Access desktop database: https://support.microsoft.com/en-us/access/ways-to-share-an-access-desktop-database
- Microsoft Support, Deploy an Access application: https://support.microsoft.com/en-us/access/deploy-an-access-application
-
Microsoft Support, Help Access run faster: https://support.microsoft.com/en-us/access/help-access-run-faster
-
Microsoft Support, Create a macro that runs when you open a database: https://support.microsoft.com/en-us/access/create-a-macro-that-runs-when-you-open-a-database
- Microsoft Learn, Get-SmbOpenFile: https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbopenfile?view=windowsserver2025-ps
- Microsoft Learn, Get-ChildItem: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-7.5
Related future topics
- Moving an Access back end to SQL Server
- Backing up files in use on Windows file servers
- Recording file share paths and permissions for recovery
This article was originally published on .