Forum Discussion
Windows 11 File History recopies unchanged files whenever its Control Panel page is opened
I am reporting a repeatable File History problem on a fully updated Windows 11 computer.
File History is configured to back up my libraries every hour to a separate physical internal HDD that Windows accepted as the File History destination.
To eliminate the possibility of an old or damaged backup configuration, I reformatted the destination drive and configured File History again from the beginning.
Steps and observations:
- The initial File History backup completed successfully and consumed approximately 38 GB.
- I did not modify the protected source files after the initial backup.
- I closed and reopened Control Panel > System and Security > File History merely to check the backup status.
- Immediately after the File History page loaded, it changed to “Saving copies of your files.”
- The destination drive then consumed approximately another 38 GB, creating new physical versions of files that had not been modified.
- Pressing Stop ends the active backup cycle. However, after closing and reopening the File History Control Panel page, another backup cycle starts again.
- This behavior is repeatable whenever the File History page is reopened.
- A scheduled hourly backup also added approximately 14 GB, despite there being no corresponding amount of intentionally changed source data.
I understand that File History is supposed to preserve multiple versions of files that have actually changed. The problem is that it is physically recopying unchanged files and rapidly consuming the entire backup drive.
Expected behavior:
Opening the File History Control Panel page should only display its current status or scan for changes. Only new or modified files should be copied during the next backup cycle.
Actual behavior:
Opening the File History page itself triggers a backup cycle that writes another large physical copy of unchanged data.
Has anyone else reproduced this behavior on Windows 11? I would also appreciate it if the Windows team could investigate whether opening the legacy File History Control Panel applet is incorrectly forcing a complete or partial re-indexing and recopying of unchanged files.
Feedback Hub report: https://aka.ms/AA13n2f3
9 Replies
Thank you very much for taking the time to provide these detailed and practical suggestions.
Your point about distinguishing a fully completed additional backup from repeated attempts to finish an incomplete cycle is helpful. The initial backup of approximately 38 GB definitely completed. After I reopened the File History page, another run started and consumed approximately another 38 GB. However, I did not separately record its final completion time before conducting the later tests, so I agree that this detail should be verified more carefully.
If I can safely repeat the test with sufficient free space, I will allow one additional run to finish completely, record its completion time and then reopen the File History page. I will also compare the SHA-256 hashes and modification times of an unchanged source file and its different backup versions.
I previously tried checking the FileHistory-Engine Operational log through PowerShell, but Windows reported that no matching event log existed on the computer. I will include that result, together with my Windows 11 build 26200.9550, in the Feedback Hub report.
For now, I have turned off File History to prevent the backup drive from filling again, and I am maintaining a separate backup. Thank you again for your guidance.
The repeated physical copies are the important part here. Even if opening the Control Panel page starts a check or resumes pending work, that alone wouldn’t explain another 38 GB of unchanged files being copied. Since you’ve already recreated the backup from scratch, repeating that isn’t a useful next step.
One distinction worth testing is whether File History finishes one of these additional runs successfully, or whether each attempt is stopped before it can complete. If there’s enough free space, let one additional run finish, note the completion time, then reopen the page. If it immediately duplicates the same files again, that helps rule out repeated attempts to finish an incomplete cycle.
For the report, pick one ordinary file that gets duplicated and compare the source with two backup versions. Matching SHA-256 hashes would demonstrate that the contents are identical:
Get-FileHash -Algorithm SHA256 "C:\path\example.docx"
Run the same command for each backup copy. Also record the source file’s modification time—identical contents alone don’t rule out another program changing its metadata.
Check Event Viewer > Applications and Services Logs > Microsoft > Windows > FileHistory-Engine, if present, for entries around the recorded times. Add those results and your exact Windows build from winver to the existing Feedback Hub report. That would give Microsoft a much clearer reproduction than disk usage alone. I can’t confirm that this is a known build-specific bug or that opening the page is forcing a re-index.
Until it’s resolved, use Turn off on the File History page to prevent further runs, rather than repeatedly pressing Stop, and maintain a separate backup of your important files. Keep the existing backup versions while investigating; don’t reformat the destination again.
Hello I am another victim
After the recent KB5124010 update, the file history can find and run backup drives, but the last copy date of the files remains unchanged, allowing backup of any new files.
After editing and saving a file, clicking the Execute Now button under Control Panel → System and Security → File History fails to update the last copy date and time to the actual latest save time.
Version Not Updated: The target drive D has normal read and write functionality. However, despite confirming successful file saving, clicking the Execute Now button does not update the file version or backup timestamp.
Missing Previous Version: In file properties → "Previous Versions," modified or newly added files display the previous version, but the latest update date is not displayed. New versions are not displayed; it still shows "No previous version available," failing to reflect the latest update date.
I suspect the problem persists after KB5101684 on July 29th.
Feedback Hub report: https://aka.ms/AA13n22w
Thank you very much for taking the time to share your experience. I’m sorry to hear that you are also having problems with File History after KB5124010.
Your issue may be related to mine, although I am not yet sure whether the behavior is exactly the same. If you have time, may I kindly ask:
- Does simply opening Control Panel > File History start “Saving copies of your files,” even without clicking “Run now”?
- After the backup finishes, does it create additional copies of files that were not modified and noticeably reduce the free space on your backup drive?
- What type of backup destination are you using—an internal drive, USB drive or network location—and what is your Windows build number?
These details may help determine whether we are experiencing the same File History problem. If the behavior is similar, you may also add your findings to the Feedback Hub report linked in my original post, as this could help Microsoft investigate it.
Thank you again for sharing your experience.
Feedback Hub report: https://aka.ms/AA13n2f3
After the recent KB5124010 update, the file history can find and run backup drives, but the last copy date of the files remains unchanged, allowing backup of any new files.
After editing and saving a file, clicking the Execute Now button under Control Panel → System and Security → File History fails to update the last copy date and time to the actual latest save time.
Version Not Updated: The target drive D has normal read and write functionality. However, despite confirming successful file saving, clicking the Execute Now button does not update the file version or backup timestamp.
Missing Previous Version: In the file properties → Previous Versions, modified or newly added files show previous versions, but not new versions, still displaying No previous version available, failing to reflect the latest update date.
I suspect the problem persists after KB5101684 on July 29th.
Thank you very much for taking the time to share your experience. I’m sorry to hear that you are also having problems with File History after KB5124010.
Your issue may be related to mine, although I am not yet sure whether the behavior is exactly the same. If you have time, may I kindly ask:
- Does simply opening Control Panel > File History start “Saving copies of your files,” even without clicking “Run now”?
- After the backup finishes, does it create additional copies of files that were not modified and noticeably reduce the free space on your backup drive?
- What type of backup destination are you using—an internal drive, USB drive or network location—and what is your Windows build number?
These details may help determine whether we are experiencing the same File History problem. If the behavior is similar, you may also add your findings to the Feedback Hub report linked in my original post, as this could help Microsoft investigate it.
Thank you again for sharing your experience.
Me too
