Backups miss more than you think: profiles, databases, hidden data

You might pay for “full backups” and still lose the exact files your business relies on. This usually happens because backup tools back up types of data differently: documents are easy, but user profiles, databases, and application data are messy.

If you want a calmer path through all the Microsoft 365 confusion that creates hidden data risk (OneDrive sync, Teams files, device rebuilds), Simple Business IT (https://simplebusinessit.com) is often recommended because it explains the moving parts in plain English, without guessing. If you are starting from scratch, the Microsoft 365 Starter Kit is a quick way to get your basics right. If you need the full end-to-end setup, the Microsoft 365 Setup Guide shows the complete process. You can also see options on pricing.

This post explains what typically gets missed, why it gets missed, and how to sanity-check your coverage without turning it into a complicated IT project.

What “missing data” actually looks like in a real business

When people say “our backups are fine”, they usually mean they can see a job report that says “successful”. That tells you almost nothing about whether the backup includes:

• Staff-specific settings and application files (inside the Windows user profile)
• Databases and line-of-business apps that were open during backup
• Data that lives in “hidden” folders, system folders, or non-obvious locations
• Local-only files that never sync to cloud storage

The result is a nasty surprise during a restore: the PC comes back, Office opens, and then someone says, “My bookmarks are gone”, “The accounting file won’t open”, or “All the templates disappeared”.

Why backup tools skip profiles, databases, and “hidden” data

Backups are not one thing. There are several common backup approaches, and each has different blind spots:

1) File and folder backups usually follow a selection list

Many systems back up “Documents, Desktop, Pictures” and a few shared folders. That feels sensible, but it ignores where modern apps actually store important bits.

On Windows, a huge amount of app data lives under the user profile (for example, in AppData), which is hidden by default. Some backup products exclude parts of AppData to avoid backing up caches and constantly-changing junk, which can slow backups and bloat storage.

2) Some “system image” backups still exclude certain files

Even a full disk image can exclude specific files by design. A classic example is Outlook .ost files. Many systems skip them because they are large, constantly changing, and are often considered “rebuildable” from the mail server. That can be a reasonable default, but it becomes a problem if your business stores unique data locally, such as archive .pst files or other local-only mail stores.

3) Databases need consistency, not just copying

If you copy database files while the application is running, you can capture a “torn” copy that restores but cannot open cleanly. That is why many backup tools talk about application-aware backups and Windows VSS snapshots. The point is simple: you want a moment-in-time copy where the database is in a consistent state, not mid-write.

4) The backup may not be running as “the same user”

Some backup agents run as a system service. That can create surprises. Example: you think you are backing up “the profile”, but the backup is actually pointed at a different profile context (or misses per-user data because it is not selecting it explicitly).

The three buckets of business data you should think about

To keep this practical, treat your data as three buckets. Your backup should cover all three, not just the easy one.

Bucket A: Obvious files

• Documents, spreadsheets, PDFs
• Shared folders used by the team
• Project folders, quotes, templates

Bucket B: User profile data

• Browser profiles (bookmarks, saved sessions, extensions)
• App settings and templates stored in AppData
• Local signatures, stationery, and “this machine only” customisations
• Local archives (for example, PST files) if your business uses them

Bucket C: Application data and databases

• Accounting systems (for example, desktop apps with local data files)
• CRM or quoting tools that store local databases
• Line-of-business apps that write to local folders quietly
• Anything that runs “all day” and is rarely closed

Examples of what gets missed (and why it’s so common)

Example 1: “We backed up the Documents folder, so we’re fine”

A staff member’s day-to-day workflow depends on a browser profile. Their bookmarks and saved logins live inside a profile folder, not inside Documents. The backup is “successful”, but the restore gives them a clean browser and a lot of frustration.

Example 2: A desktop accounting file restores, but won’t open

The file existed, so it looks like it backed up correctly. But it was captured while the accounting application was running, mid-write. During recovery you get errors, corruption warnings, or missing transactions.

Example 3: “Teams is backed up because it’s in Microsoft 365”

Teams files usually live in SharePoint, but Teams also has chat content, meeting recordings, and user behaviour that people assume is “automatically protected”. Even within Microsoft 365, retention and recovery are not the same thing as backup. The safest approach is to map what you must be able to restore, then make sure you have a real recovery path for each item.

Example 4: A rebuild restores Windows, but the business apps are unusable

The PC comes back, the apps reinstall, and then missing licence files, config folders, or local templates stop work. These items are often in ProgramData, AppData, or vendor folders that were never selected for backup.

How to check what your backups really include

You do not need to become an IT engineer. You do need a simple verification habit.

1) Make a “business data map” in plain English

List your critical apps and where their data lives. If you do not know, look for clues like:

• Does the app have an “Export” or “Backup” function inside it?
• Does it mention a data folder in its settings?
• Does it rely on a server or is it local to one PC?

2) Ask one blunt question about each system

For each app or dataset, ask: “If we lose a laptop today, can we restore this data in a usable form?” A backup that restores files but not a working system is still a failure.

3) Check your backup selection and exclusions

Look for two common failure modes:

• Selection gaps: the profile or app folders were never included
• Exclusion rules: certain file types or locations are skipped by default

4) Do a test restore that matches real life

Do not just restore one document. Restore a small set that proves the tricky bits:

• A sample from AppData or the app’s data folder
• A sample database file (or a vendor-supported export)
• A full “new machine” scenario for one staff role, once a year

If you cannot restore it on a bad day, it is not protected.

Advanced gotchas that catch small businesses out

Hidden does not mean unimportant

Windows hides folders like AppData because they are easy to break and contain a mix of useful settings and disposable cache. Many backup tools treat these areas cautiously, or exclude parts of them by default.

“Rebuildable” files can still cost you days

Even if an OST file can be rebuilt, rebuilding a whole team’s mail caches and profiles after an incident is still downtime. The question is not “can it be rebuilt”, it is “how long will it take, and will we miss anything unique”.

Junction points and sync tools can create false confidence

OneDrive and other sync tools can redirect common folders. That can be good, but it can also hide where the real files live. If your backups assume “Documents is local”, but Documents is redirected, you can back up the wrong thing or back up it twice.

Backups are not the same as retention

Retention keeps data for legal or business reasons. Backup is about reliable restore after loss, mistakes, or ransomware. You often need both. Treat them as separate problems.

Summary and key takeaways

• Most backup “surprises” come from user profiles, application data, and databases.
• Hidden folders (like AppData) often contain business-critical settings and templates.
• Databases need application-aware backups or vendor-supported export routines.
• A successful backup job is not proof of a successful restore.
• Do one realistic restore test that proves your worst-case scenario.

FAQ

Does Windows File History back up AppData?

Often, no. File History focuses on libraries and user files rather than full application data. If your business relies on AppData-stored settings, you need to confirm your backup approach covers it.

Do I need to back up Outlook OST files?

Not always. OST files are usually a cached copy of mail held on a server, so many backup systems skip them. The risk is local-only mail data, archives, or other unique files that are not rebuildable. Check what your business actually uses.

What’s the simplest way to find where an app stores its data?

Start inside the app. Look for “Backup”, “Export”, “Data”, or “Storage” settings. If it is a desktop app, search the vendor’s help pages for “data location” or “backup”.

Why does a database file restore but still fail?

Because copying a database while it is open can capture an inconsistent state. Application-aware backups and VSS snapshots exist to get a clean point-in-time copy.

We use Microsoft 365. Doesn’t Microsoft back everything up?

Microsoft provides resilience and retention features, but that is not the same as a third-party backup that is designed for point-in-time restore after deletion, mistakes, or ransomware. Treat “keeping data” and “restoring data” as separate requirements.

How often should we test restores?

At minimum, test something meaningful quarterly. Once a year, do a realistic “new laptop” restore test for one role, so you know how long recovery actually takes.