The WSL file that was supersizing my UrBackup incremental backups

I was doing a backup of my data from my Windows 11 desktop to an UrBackup server on my new NAS.

I was getting ~200GB incremental backups on a desktop with about 500GB in total use. I was 100% sure I was not making 200GB of changes on the system – not over the course of a few hours barely touching the computer.

I also knew from past experience it was a WSL problem, but my $searchEngine incantations were failing me. I am a Linux sysadmin who occasionally uses Windows with power user (but not system administrator) proficiency – or, more to the point, I was out of my depth on this. I did some poking and thought I could maybe save someone else some trouble by sharing my conclusion.

I figured out the filesystem is seemingly saved as a vhdx file in my AppData. I’ve adjusted this a bit for anonymity of the underlying path but the following is the pattern:

C:\path\to\Users\my_username\AppData\Local\Packages\MyOSName\LocalState\ext4.vhdx

This would seem to be because the local state of the WSL filesystem is (from the point of view of Windows) saved as this single giant file, which is then backed up via UrBackup every single time any change of any kind is made within WSL. This is not ideal for incremental backups.

The fix at that point was simple – in the UrBackup client settings, I excluded the relevant path (actually decided for some more reasons to exclude all the AppData, but you could just do the LocalState directory at the local-most level). That reduced the next incremental backup to a few tens of megabytes, much more tractable and plausible for the actual changes. That’s a decrease of four orders of magnitude, nothing to sneeze at.

I’ve got some rsync backups of the WSL content I care about now. All set, hope this is helpful.