Understanding how/what Urbackup decides to backup for File Backups



Before I start trying to help with the project, I want to make sure I understand correctly the concept of what/how UrBackup decides to backup in regards to files. There’s are some inconsistencies with the server and client interfaces and would like to help with getting a more consistent interface/document some extra stuff.

Can you correct me if I get this wrong, but what I understand is:

  1. Default directories to backup: (Server interface) is the same as Add/Remove Backup Paths in Win/Mac clients.
  2. In server and client if Include in backup (with wildcards) exists it will override Default directories to backup:
  3. Based on above if in server and/or client Exclude from backup (with wildcards) has paths those will be excluded from the backup set.

When installing the client there’s a dialog of:


Where in the source code is the logic that creates the Default directories to backup: for the client depending on what you select (both Mac and Windows if different locations)?

Where in the source code is the logic that the server settings | General | File Backups is configured and controlled?


Added: https://docs.google.com/document/d/1sycoYeRT0I0jyjSU_hbCka2MYOcZm-nVMe2AKUaYaJA/edit?usp=sharing as a final summary document because forums aren’t good for that (publicly editable if you can help make better please do).



I dont know the code behind, but for my personnal usage and the posts i’ve seen on the forums (you never see the peoples without problems, so maybe it s not problematic for everyone). This ability to setup things client and server side and the way settings can override/complete each others. It ends up being kind of a mess.

The current issue with paths is that :

  • As a quick start, peoples often use client side setting for paths to backup when doing their first installs.
    Then as time pass, they use group and server side settings, client setting takes precedence
    Then paths they thought were backed up aren’t (you d need to login on each client to check that).

  • A user edit the client conf (allowed by default), and put some path, then the important path sets by the admin aren’t backed up.

On the other side you have peoples who provide backup as a service, and thus must allow users to set their backup paths and settings.

My personal opinion of how it would work in a perfect word is:

  • Servers side setting are mandatory and can not be overwritten.
  • Maybe add an unchecked checkbox to allow client setting to overwrite server settings, but that’s the current behavior and it s source of troubles.
  • Allow the client to add backup path, but still show the server side path as greyed out, uneditable.
  • Also server side, show the client side settings.
  • Still allow to forbid to set client side settings (you can already do that).

As i said, for the code side, i have no idea.

Haa, for the useful; but i guess annoying stuff on the code side:
You can have more than one local/internet server with different settings.
The server side settings must combine with the client settings.

If you feels like coding, sorry to push my own requests forward. But i think there s a few enhancement on the web ui that would be a lot easier to implement. Because things can not break the current users settings, filtering for backup tab is asked a lot.
Packaging for various linux distributions could also be improved.


Maybe the easiest, what i did was a linux script.
It create files in a predictable way, some with odd properties, like : their owner doesn’t exists.
Then it backup them and restore them, and check if the restore is the same than expected.

Urbackup shouldn’t crash on anything, not should any other program.
if it does, then just report that.
And restored files should be like you backed them up (urbackup restore symlink as file for example).

If you know well osx or windows, you can try rewritting that for it. For example there has been issues with osx sparse files, and not enough users test their restores.


Do you know how to does the client/server settings take priority based on which is implemented first?

  • Server has x settings
  • Client has y settings at the end of the installer and you choose something out of the last setup dialog

Which settings win (understanding that if you enable the “Settings | Permissions | Uncheck "Allow client-side changing of settings”) then obviously client settings are completely over-written by the server settings.


At least for paths, client win.
But i guess that s true for other settings as well.


I’ve been hoping @uroni might be able to point me in the right direction. I’ve searched:


Using this as an example of “what’s commonly part of the excluded list”

:\System Volume Information\MountPointManagerRemoteDatabase
:\System Volume Information\*{3808876B-C176-4e48-B7AE-04046E6CC752}
:\System Volume Information\:.{7cc467ef-6865-4831-853f-2a4817fd1bca}DB
:\System Volume Information\:.{7cc467ef-6865-4831-853f-2a4817fd1bca}ALT
:\System Volume Information\FVE.{e40ad34d-dae9-4bc7-95bd-b16218c10f72}.:
:\System Volume Information\FVE.{c9ca54a3-6983-46b7-8684-a7e5e23499e3}
:\System Volume Information\FVE.{9ef82dfa-1239-4a30-83e6-3b3e9b8fed08}
C:\Users\:\AppData\Local\Microsoft\Windows\Temporary Internet Files
C:\Users\:\AppData\Local\Google\Chrome\User Data\Default\Cache
C:\Users\:\AppData\Local\Google\Chrome\User Data\Default\Media Cache
:\System Volume Information
C:\ProgramData\Microsoft\Windows Defender\Scans\mpcache-*
C:\Program Files
C:\Program Files (x86)

Searching for Pagefile.sys resulted in nothing. I’m wondering:

  1. This looks like a partially dynamically created list.
  2. If there is support for environment variables in the exclusion list I’d like to work on cleaning this up and reducing/optimizing.
  3. Why are some of these paths missing drive letter? I’m wondering if there are multiple places in the codebase that the exclusion list is built from, based on options selected during setup?
  4. Didn’t see any notation in: http://urbackup1.davidthegeek.com:55414/help.htm#exclude_files what the : is supposed to do