Very long indexing and bigger than expected backup size

I have UrBackup running on my Linux home server (OMV6) as a Docker container
Client that I have problem with: My desktop PC running Windows 11 Pro

It looks like there is some problem with symlinks in Win11 as I did not have problems when I was running Win10 on the same machine.

I am trying to set back up of my “C:\Users\myusername” folder. Folder size is approx. 4 GB.

image

When I start full file backup, indexing takes ~15 mins and web ui shows that backup size is 345 GB.

When I started investigating this problem, I noticed that there is issue with handling some folders. Those folders are not actually folders but symlinks to other folders. It seems to me, that something somewhere (sorry, I am amateur user :slight_smile:) does not handle symlinks properly. And it seems, that this issue occurs since I installed Win11.

Please see attached error log (I started backup and after indexing was done, terminated backup process)

error.log (417.4 KB)

I do not know what to do, I tried to play with directory flags, restarted server, client, reinstalled client.
I also installed Link Shell Extension hoping that it could help the situation but it did not.
I really hope that there is some solution as I really dont want to rollback to Win10. I also liked UrBackup very much on Win10 :slight_smile:

I assume that this is happening, because program gets access denied as it is secured system object:

I also have to mention, that backup proccess ignores “dont follow symlinks” rule on any sort of symlinks.

For example, I tried backing up my “Documents” folder. It started backing up all my pictures from default “Pictures” folder because there are some pictures inside. This happens because “Pictures” symlink/shortcut is located in “Documents” folder, hidden though. This is not a behavior that someone actually expects. Documents are documents and pictures are pictures :slight_smile:

Just a comparison of a backup on Win10 vs Win11

On Win10 “Application Data” is marked as not a directory but a symlink thus empty

image

Versus Win11, where “Application Data” is treated as folder, which is then duplicated inwards until something stops this loop.

etsvlone wrote,
I also have to mention, that backup proccess ignores “dont follow symlinks” rule on any sort of symlinks.

I have had the same issue on win7, Win10 and Win11.
Yes “dont follow symlinks” appears to have no effect on soft links, hard links and/or junctions.
The only solution that I have found is setting “Default directories to backup:” to something like, C:|C_0/one_filesystem,share_hashes;H:\Butch
C: says to do file backup of the C: drive.
| is the name separator.
C_0 is the name I gave to the C: drive’s file backups.
/ is the command separator.
The crucial command is “one_filesystem” which tells the server, do not follow junctions that leave the C: drive, no matter what.
The command “share_hashes” keeps the server from duplicating identical files from other clients.
H:\Butch says to backup that folder which is linked by a junction named “My Music” stored in the “C:\Users\butch\Music” standard windows user folder which points to “H:\Butch\MyMusic”.
Also in the “C:\Users\butch\Music” standard windows user folder is another junction named “Music Library” which points to “H:\Music” which cannot be backed up due to limited space on the backup drive.
That’s why “H:\Butch” is added to the “Default directories to backup:” setting to backup “H:\Butch\MyMusic” but the “one_filesystem” directive stops the server from following the other junction to the “H:\Music” folder.
If everything is on the C: drive then I have no solution for you.
The “one_filesystem” directive keeps the server from following junctions to locations off of the C: drive only, unless a folder is specifically added to the “Default directories to backup:” setting.

All for now