Improper updating on file deletion

client
1

Possible bug report here.

I deleted a rather large file and made an incremental backup. The file’s removal was not reflected in the incremental backup generated on the server; the server just made a symbolic link to the .directory_pool, mirroring the directory from the last incremental backup. Ran another incremental backup which generated another incorrect symbolic link.

I tried adding a dummy file in the same directory and made another incremental backup. This time it made a non-symlinked directory, now without the old previously-removed file and with the new added dummy file (i.e. a correct backup).

I ran it again without changing the directory and it generated a symlinked directory from the last backup (again, a correct backup).

Finally, I deleted the dummy file and ran yet another incremental backup; this simply symlinked the directory from the last backup, still including the dummy file. This was no longer a correct backup because that file had been deleted on the client.

My conclusion is that the client properly recognizes added files, but not deleted files. Any directory with files strictly deleted may be considered the same as a previous directory and symlinked from the last file backup. This means the backups are less reliable than I was hoping, since it’s not an accurate snapshot of the files on the computer at that time. Can this be fixed?

This is on Windows 10 client 2.2.5, with server 2.2.8 running on a pretty-much-fresh Xubuntu 17.10 install. This part probably isn’t relevant, but the backup storage path is mounted via SMB off a FreeNAS box. The computers are communicating via a LAN connection, and “Local incremental file backup transfer mode” is set to Hashed. The directory in question is a user Desktop directory; this is included in the backup set as part of C:/Users/[username], but isn’t specified explicitly.

I only read afterwards that you want log files, so I didn’t generate any, but if this isn’t a known bug and log files would be helpful, let me know and I’ll go do this all again with debug logging enabled :slight_smile:

Let me know if there’s any further information I can give to help you troubleshoot this.

2

Not a known bug. If you want to help track this down e.g. checking if this is a client bug or server bug would be helpful by checking if "C:\Program Files\UrBackup\urbackup\data\filelist.ub" has the file removed after you remove it and run a backup. Then checking if the symlinking causes it by disabling it (temporarily).

3

filelist.ub does not currently show the file that I removed, even though the last incremental backup still has the file in the tree.

Disabling symlinking on the server makes the file vanish in the next incremental backup, so, yep, sounds like a symlinking issue. I’ll leave it off for now unless there’s a major reason not to.

Happy to do some more tests if some would be helpful!

4

This should be fixed with server 2.2.11 now. Thanks for the help!

1 Like