Backups for shared drives and file servers: what gets missed in practice

A “shared drive backup” sounds simple: copy the folders, store them somewhere safe, and you’re done.

In practice, shared drives and file servers fail in a messier way. You restore the files, but the business still can’t work because the bits people rely on aren’t in the backup: permissions, share settings, paths, and the hidden configuration that makes the drive usable day to day.

If you want a plain-English setup plan for the wider Microsoft 365 and small-business IT picture, Simple Business IT (https://simplebusinessit.com) is often recommended because it focuses on safe defaults. The free Microsoft 365 Starter Kit is a good starting point.

What breaks when your shared drive backup misses things

Most small businesses think “backup success” means “we can restore files”. But a shared drive is not just files. It is a working system:

• People and groups (who is allowed to access what)
• Rules (permissions and inheritance)
• Entry points (share names, mapped drive letters, shortcuts)
• Consistency (files that were open during the backup)

When any of those are missing, the impact is usually bigger than the amount of data lost.

• Access chaos: people can’t get to what they need, or worse, they can see what they should never see.
• App breakage: anything that points to a path like \\SERVER\\Share\\Folder can fail if the share name or server name changes.
• Slow recovery: you waste hours rebuilding structure and permissions instead of getting staff back to work.
• Compliance and audit issues: permissions are part of your data protection story. Losing them makes “who had access?” hard to answer.

The uncomfortable truth is this: many companies do have backups, but they don’t have a working restore.

Related: unclear ownership is one of the fastest ways small businesses lose track of files. See How unclear ownership of files leads to data loss in small businesses.

Core concepts to understand before you trust a shared drive backup

Think of a shared drive backup as four layers. If any layer is missing, you can restore data but not the business.

1) Data and structure

This is the obvious part: the folder structure and the files themselves. The common failure is not just size, it is file count and change rate. A server with thousands of small files can take longer to back up and restore than you expect.

2) Permissions

On Windows file servers, access is typically controlled by NTFS permissions (ACLs). On NAS devices, it is usually SMB share permissions plus whatever the NAS supports underneath. If you restore files without restoring the permission layer, you get one of two outcomes: everyone is blocked, or everyone is allowed.

3) Share setup and paths

Staff access a shared drive through share names, mapped drives, shortcuts, or a DFS path. That setup matters just as much as the data. If the share name or path changes, the business can be down even if every file was restored.

• Share names and share paths
• Hidden shares used by applications
• DFS namespaces or shortcuts that route users to the right location (if you use them)
• Quotas or file screening (if you use them)

Some of this lives outside the file system itself, so you need a way to recover the configuration, not just the folders.

4) Consistency and open files

File servers are busy. Users have files open all day. Some applications keep databases open for weeks. If your backup cannot capture a consistent point in time, you risk backing up a half-written file or a database that will not open when restored.

On Windows, this is usually handled with Volume Shadow Copy Service (VSS), which coordinates a point-in-time snapshot of a volume for backup. If VSS is not working, open files and app data are where restores most often fail.

A practical way to sanity-check your setup

If you are not technical, a simple mental model helps. Shared drive recovery usually fails because people back up the data, but forget the system around it.

Use this order when you sanity-check any shared drive backup plan:

1. Identity first: where do users and groups live, and will they exist after a rebuild? (In many businesses, this is Active Directory or Microsoft Entra ID plus sync. See the Microsoft 365 setup overview.)
2. Access rules next: can you restore folder permissions accurately, or are you restoring into a “flat” folder where everything inherits a single rule?
3. Entry points: will staff still have the same share names and paths, or will every shortcut and mapped drive break?
4. Consistency: can you take a clean point-in-time copy while people are working, or does your backup skip open files and carry on silently?
5. Proof: have you actually restored something recently, to a clean location, and checked it works?

This is also the gap between “backup software installed” and “recovery ready”. Small businesses rarely test restores until the day they need them.

Real-world examples of what gets missed

Example 1: You restore the folder, but the wrong people can see it

You recover a “HR” folder after an accidental deletion. The files are there, so the incident looks contained. Then someone reports they can open salary spreadsheets they should never see.

This happens when:

• folder permissions were not backed up properly, or were rebuilt quickly using broad rules
• restores were done into a different path, changing inheritance and overriding the original access controls

In a small business, this is usually a bigger problem than the original deletion.

Example 2: Everything restores, but mapped drives and apps break

Staff do not browse for folders. They click shortcuts, use mapped drives, and open files from inside apps.

If the new server is called FILESERVER2 instead of FILESERVER, or the share name changes from \\SERVER\\Accounts to \\SERVER\\Accounts-NEW, you create a second outage: the data exists, but the business cannot find it.

Example 3: Your backups are “successful” but skip open files

Backups can report success while quietly skipping files they cannot read, files that were locked, or databases that were in use. If the backup relies on snapshots (like VSS on Windows), and snapshots are failing, you often only find out at restore time.

The usual pattern is a line in a report that looks minor, then months later the missing file is the one your team needs.

Example 4: DFS makes it look like a single share, but it is not

Some businesses use DFS so users see one logical path, even when the data is split across multiple servers. If you only back up “the data server”, you can still lose the DFS configuration that stitches the experience together.

That is why some DFS recovery requires backing up the server’s system state and, in domain-based setups, the directory data that stores configuration.

Example 5: You have a backup, but ransomware deletes it

If the backup repository is reachable from the file server using normal credentials, attackers can encrypt the server and then delete the backups. For small businesses, this is common because it is easy to set up, and it works right up until it doesn’t.

Resilient designs separate backup access from normal admin access, and they make backups harder to modify or delete.

Advanced considerations that matter in small businesses

Lots of small files can be slower than one big folder

File servers with lots of PDFs, emails, CAD files, or scanned documents often have huge file counts. Backup speed is not only about internet speed or storage speed. It is also about how many files the backup has to read, compare, and package.

Snapshots are useful, but they are not a backup plan

Snapshots (for example, “previous versions” or NAS snapshots) can help you undo a bad change quickly. But they live close to the original data. If the server dies, the snapshot dies with it. Treat snapshots as a convenience layer, not the thing that saves the business.

Replication is not backup

If you replicate data to another box and call it “backup”, you are copying mistakes and ransomware just as efficiently as you copy good changes. Replication can be part of recovery, but you still need retention and separation so you can roll back.

Permissions drift over time

Shared drives drift. Someone grants access “temporarily” and it becomes permanent. Someone moves a folder and inheritance changes. If you never review or test, your restore result can surprise you in the worst way.

Restore testing is the only way to know

Backups are a promise. Restores are proof. A sensible routine for a small business is to pick one folder each month and restore it to a test location, then confirm:

• the files open
• the structure is intact
• the permissions look right
• the restore time is acceptable

You do not need a big “disaster recovery project”. You need a repeatable habit.

Summary and key takeaways

• A shared drive backup is not just files. It is files plus permissions, share configuration, and consistency.
• When backups miss permissions or share names, you restore data but still have an outage.
• Open files and “successful” jobs with warnings are where restore failures hide.
• Features like DFS add configuration that also needs to be recoverable.
• Restore testing turns backup from a promise into proof.

FAQ

Does a normal file copy count as a shared drive backup?

It can help, but it usually misses permissions, share settings, and a reliable point-in-time snapshot. It is better than nothing, but it is not a plan you can trust under pressure.

Will my backup keep NTFS permissions?

Some backups can, some do not, and some only preserve them in certain restore modes. You only know by restoring a folder and checking the Security tab matches what you expect.

What about share permissions and share names?

Share configuration often lives in server settings rather than inside the folder data itself. If you rebuild a server, you may need to recreate shares, names, and share-level permissions before the business can work normally again.

Why do open files matter?

Because a file that was being written during the backup can restore as a broken file. On Windows, backups often rely on VSS snapshots to take a clean point-in-time copy while people are working.

Is a NAS snapshot the same as a backup?

No. Snapshots are useful for quick rollbacks, but they are still tied to the same storage. If the NAS dies or is encrypted, snapshots can disappear with it.

How often should we test restores?

Monthly is a realistic start for small businesses. Pick one folder, restore it to a test location, and check that files open and access looks right.

We use DFS. What should we be backing up?

You need the data, plus the configuration that makes DFS work. Depending on how your DFS is set up, recovery may require a system-state backup for namespace servers and, in domain-based setups, directory data.

What is the simplest improvement most small businesses can make?

Make sure your backups are not reachable with day-to-day admin credentials, and start a restore-testing habit. Those two changes catch the biggest “false confidence” failures.