The files Windows leaves out of a backup on purpose: FilesNotToBackup and FilesNotToSnapshot

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.

A restore finishes without an error, and a folder is empty that should not be. The backup log shows no failure. The file was never meant to be there: a registry entry on the original server told the backup to leave it out.

Windows has two registry lists for this purpose, FilesNotToBackup and FilesNotToSnapshot, and the Volume Shadow Copy Service (VSS) writers that applications register can add exclusions of their own. Most entries are sensible. The risk lies in the few that are not, especially when no one reviews them before something is missing.

This guide explains each mechanism from Microsoft's documentation, which tools honour it and when, and how to audit a server before you depend on its backups.

Why it matters

(our reading) Backup testing usually checks that a job completed and that a sample file restores. Those checks can miss an exclusion: the job completes because the files were deliberately skipped, and the sample may not be an excluded file. An exclusion may remain unnoticed until restore, although a registry-to-data-map audit can expose it earlier.

Three things make this worth an hour of audit:

• Any installed application, or an administrator following an old forum post, can add an entry. Microsoft's guidance that applications should exclude only their own files is a recommendation, not an enforced rule.
• Entries support wildcards and recursion, so a single line can remove a whole directory tree.
• Different backup methods honour the lists at different moments. A block-level backup may hold the file and then delete it during the restore, so a backup image that looks complete can still restore without it.

How it works

FilesNotToBackup

Microsoft describes this key as specifying "the names of the files and directories that backup applications should not backup or restore". It lives at:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup

Each entry is a REG_MULTI_SZ value. Its format is [Drive][Path]\FileName [/s]:

• The drive is optional. A leading backslash with no drive letter means all drives.
• The path is optional and "cannot contain wildcard characters".
• The file name is required and "can contain wildcard characters".
• /s means that "all subdirectories of the specified path are to be included".
• Environment variables such as %Systemroot% can stand in for part or all of the string.

Microsoft's table of typical entries shows the intent: the page file (\Pagefile.sys), the hibernation file (\hiberfil.sys), the Microsoft Distributed Transaction Coordinator log, the Offline Files cache (%Systemroot%\CSC\* /s) and temporary files (%TEMP%\* /s). These are files that are large, rebuilt automatically or meaningless on another machine.

FilesNotToSnapshot

This second key works at a different layer. VSS supports it so that "Applications and services can use this key to specify files to be deleted from newly created shadow copies". It sits beside the first key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot

Each value belongs to one application and lists fully qualified paths, which "can contain the * wildcard". Two variables widen the reach: $UserProfile$ applies the path "to all user profiles on the computer", and $AllVolumes$ applies it "to all shadow copies on the computer". Appending /s makes a path recursive.

Microsoft sets narrow conditions for using it. A file should be excluded from shadow copies "only if it is large, undergoes significant change between one shadow copy and the next, and does not need to be backed up", and "You should only exclude files that belong to your application." The key "is intended to be used only by applications", and deletion from the shadow copy happens "on a best-effort basis. This means that they are not guaranteed to be deleted."

The two keys are independent. Microsoft notes that FilesNotToBackup "does not exclude those files from shadow copies". Snapshot context also matters: when VSS_VOLSNAP_ATTR_NO_AUTORECOVERY is set, auto-recovery is disabled and no files can be excluded from the shadow copy, according to Microsoft's exclusion documentation.

Writer exclusions

Applications that ship a VSS writer have a third route. A writer describes the components a backup should capture, and the AddExcludeFiles method "is used to explicitly exclude a file set (a specified file or files) that might otherwise be implicitly included when a component of the current writer is backed up". Microsoft's own example is to define a component that includes a whole directory, then exclude "some files (for instance, temporary files)". A related method, AddExcludeFilesFromSnapshot, lets a writer report files to remove from the shadow copy itself.

These exclusions live in the writer's metadata, not in the two registry lists, so (our reading) auditing the registry alone does not show them.

Who honours what, and when

This is the part most likely to surprise. Microsoft's documentation says:

Microsoft adds one exception for block-level restores: Single Instance Storage common store files "must not be deleted at restore time".

A companion key, KeysNotToRestore, lists registry subkeys and values that backup applications should not restore. Microsoft says "It is not necessary to honor" it on current Windows, while System State Backup does honour it.

Three consequences follow (our reading):

1. A complete image does not mean a complete restore. With a block-level backup, the excluded files can sit inside the backup and still disappear when it is restored with a tool that applies the list at restore time.
2. The list that applies may be the one on the restored system. For a restore-time deletion, the tool needs a list to act on. Which machine's registry it reads is a product detail the pages read do not settle. If you restore an old server's volume onto a new build, check with the backup vendor which list applies.
3. Third-party products vary. The registry keys are a convention that backup applications "should" follow. How a given product honours them, ignores them or lets you override them is in its documentation, not Microsoft's.

How to audit a server

The commands below only read the registry; they change nothing. reg query "Returns a list of the next tier of subkeys and entries that are located under a specified subkey in the registry".

reg query "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup"
reg query "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot"
reg query "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\KeysNotToRestore"
vssadmin list writers

(our recommendation) For each server you back up:

1. Export the three lists and keep the output with the server's backup records. You will want it later to explain a missing file.
2. Read each entry against the data map. For every value, ask which application added it and whether the path could match business data. Watch for drive-less entries (all drives), $AllVolumes$, $UserProfile$, wildcards in the file name and /s.
3. Expand the wildcards. An entry such as *.tmp /s at the root of a data volume excludes every .tmp file below it. Some applications use extensions that look temporary for files that matter. List the files that actually match before deciding.
4. List the writers with vssadmin list writers, which "Lists subscribed volume shadow copy writers". For any application writer that protects data you care about, read the vendor's documentation for what its components include and exclude. DiskShadow's list command also "Lists writers"; its detailed output describes writer components (our understanding; check the output format on your server).
5. Find out what your backup product does with the lists: honour at backup, honour at restore, ignore, or a setting. Record the answer.
6. Include an excluded path in a restore test. Pick a file that matches an entry you have decided is acceptable and confirm the restore treats it the way you expect. That proves the behaviour instead of assuming it.

Do not delete entries to "fix" an exclusion without understanding them. Removing the page file entry, for example, makes backups larger for no benefit. Where an entry wrongly covers business data, the safer change is usually to correct the application's configuration or ask its vendor, and to record the change.

Questions to put to your backup vendor

(our recommendation) The Microsoft pages describe a convention; the product decides how to apply it. Ask, and keep the answers in writing:

• Does the product read FilesNotToBackup, FilesNotToSnapshot and KeysNotToRestore? At backup time, at restore time, or both?
• For image or block-level backups, are listed files removed when a whole volume is restored, when single files are restored, or never?
• Whose list is used during a restore to new hardware: the one captured with the backup, or the one on the target system?
• Can an administrator see, in the backup catalogue or a report, which paths were skipped because of a list entry?
• Can the lists be overridden for a particular job, and is that override recorded?
• How does the product treat writer exclusions reported through AddExcludeFiles?

A clear answer to the fourth question is the most useful. (our reading) An exclusion that appears in a report can be reviewed; one absent from the report may remain unnoticed until restore. Comparing registry entries and writer exclusions against the data map is another way to find it.

What usually belongs on the list

(our reading, from Microsoft's typical entries) Good candidates share three properties: the operating system or application recreates them, their contents are meaningless after a restore, and they are large or change constantly. The page file and hibernation file are the clearest cases. Temporary folders, caches that rebuild themselves and trace logs usually qualify too.

Poor candidates include anything a person created, anything an application cannot rebuild without a long reindex, and anything whose loss would need someone to re-enter data. If an entry covers a cache that takes days to rebuild, its exclusion may be acceptable for space but should be recorded as a recovery-time cost.

A worked example (illustrative)

The following is invented for illustration; no system was inspected.

A practice-management application stores scanned documents under D:\AppData\Scans\ with a .tmp extension while they are being indexed, and renames them when indexing finishes. A large backlog means some files keep the .tmp name for days. An earlier administrator, troubleshooting slow shadow copies, added a FilesNotToSnapshot value of $AllVolumes$\AppData\*.tmp /s.

The nightly file-level backup reads a shadow copy from which those files were removed. The job reports success. Months later the D: volume fails, and a few hundred scans waiting in the backlog are not in any backup.

An audit in step 2 would have flagged the entry: a wildcard, recursive, on a data path, added by a person rather than by the application.

Risks and limits

• This article relies on Microsoft's documentation for Windows itself. It does not describe any particular third-party backup product, and their behaviour may differ.
• The documentation describes typical entries, not a complete list. A fresh server's lists depend on its version and installed roles.
• FilesNotToSnapshot deletions are best effort, so (our reading) an excluded file may sometimes appear in a backup and sometimes not. Do not rely on the list as a privacy or security control.
• Changes affect the backup and restore paths that honour the relevant key. System Restore and System State Backup do not honour FilesNotToBackup on the documented current versions; the source identifies Windows XP as a separate legacy exception. Do not treat FilesNotToBackup, FilesNotToSnapshot and KeysNotToRestore as interchangeable. Make any change through change control and test it.
• The audit steps are a recommended practice from the documentation, not a tested procedure.

Sources

• Microsoft Learn, Registry Keys and Values for Backup and Restore, https://learn.microsoft.com/en-us/windows/win32/backup/registry-keys-for-backup-and-restore (last updated 2 November 2026; accessed 14 November 2026)
• Microsoft Learn, Excluding Files from Shadow Copies, https://learn.microsoft.com/en-us/windows/win32/vss/excluding-files-from-shadow-copies (last updated 7 January 2021; accessed 14 November 2026)
• Microsoft Learn, IVssCreateWriterMetadata::AddExcludeFiles, https://learn.microsoft.com/en-us/windows/win32/api/vswriter/nf-vswriter-ivsscreatewritermetadata-addexcludefiles (accessed 14 November 2026)
• Microsoft Learn, Shadow Copies and Shadow Copy Sets, https://learn.microsoft.com/en-us/windows/win32/vss/shadow-copies-and-shadow-copy-sets (accessed 14 November 2026)
• Microsoft Learn, reg query, https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/reg-query (accessed 14 November 2026)
• Microsoft Learn, vssadmin list writers, https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/vssadmin-list-writers (accessed 14 November 2026)
• Microsoft Learn, Diskshadow, https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/diskshadow (accessed 14 November 2026)

Related future topics

• Diagnosing failed VSS writers (existing article: vss-writer-failed-diagnose-windows-shadow-copy-errors)
• Alternate data streams, reparse points and long paths in Windows file backups

This article was originally published on 14 November 2026.