UrBackup Server 2.0.30 RC/Client 2.0.29 RC

The major changes are described in the blog: http://blog.urbackup.org/223/new-in-urbackup-2-0-x

The portable Linux client is now build with glibc with a fallback to a ellcc (musl libc) binary which doesn’t have C+±exception support (yet). In my tests everything was functional and since most will be using the glibc binary, I hope this does not cause many problems.

Clients are now signed for Windows and OS X (or should I call that macOS now?).

Changes with server 2.0.30

  • Handle client address changes during re-authentication and initial authentication
  • Sync filesystem before setting file backup to done, not to complete
  • Server: Retry sqlite3 prepares 5x on Linux/FreeBSD
  • Client specific locks when creating/deleting directory symlinks
  • Do not switch over to next file if in accumulation state and file size is zero in block differences file transfer

Changes with client 2.0.29

  • Truncate file before writing to in on Linux when writing to e.g. server_idents.txt
  • Do not delete shadow copy for image backup during simultaneous file backup started by same server

Compatibility with prior versions

  • 2.x server with 1.4.x client full compatibility (please report issues)
  • 2.x client with 1.4.x server works only in local network mode (not via internet mode)
  • Older client/server combinations may work but were not tested
  • 1.x restore does not work with 2.x servers (improved login method)

Upgrade process

As always: Replace the executables (via the installers) and the database of the server/client will be updated on first running it. As always downgrading the database version after upgrading it is not possible, so you should backup the old database files especially since this is a beta.

Because of the improved file de-duplication and statistics calculation the largest server table has to be completely rebuild. This may take a few hours depending on how many file entries you have. It will show the progress on the web interface but is not usable during the upgrade process.

Linux notes:

  • The wrapper scripts start_urbackup_server and start_urbackup_client have been removed. Please use the executable directly
  • The executable has been renamed to urbackupsrv (from urbackup_srv), the client to urbackupclientbackend (from urbackup_client)
  • There is a new command line interface for the client urbackupclientctl
  • All the plugins are now statically linked into one executable. This simplifies the compilation, debugging and packaging on Linux

Run the UrBackup server on Linux with e.g. urbackupsrv run --loglevel debug



I’m bumping a question that was unresolved on server 2.0.27 thread, and that’s unresolved on latest versions:

I’m seeing some strange behaviour related with quotas. I have a 370Gb partition for testing with a few computers. The filesystem is btrfs.
Urbackup tells me that there are 540Gb of backups, that could be ok due to the deduplication urbackup does, but if I enforce the quota of one of the users, I receive warnings like this:

Quota enforcement report for client "David" (id=1)
Client uses 406.189 GB and has a quota of 150 GB
This requires enforcement of the quota.
Error. Target space is negative

Also I think there should be some clarification about space usage and quotas: maybe we should know the real usage (without taking into account deduplication) and have the option of setting the quota based on real space usage.

Since upgrade from 2.0.29 to 2.0.30 server and 2.0.27-cbt to 2.0.29-cbt yesterday, all CBT clients this morning have errors in backup logs :

CBT status on all clients seems to be OK :


After rebooting one client, it works again,
I’ve notice that the CBT version have changed (from v1.0 to v2.0) :

Do we need to restart all clients ?

I did a fresh install on arch linux, using the urbackup2-server package.
removed /usr/share/urbackup, /var/log/urbackup.log, emptied /var/urbackup.

After installing the package and starting it, the log looks like this: https://gist.github.com/cfstras/ee2dab023e40e2583ffbf62586d36faf

going on server:55414, I see: Sorry. File not found.

Did I miss a file to clean up?

Found it. The installer sets wrong permissions for /usr/share/urbackup/www. to fix:
chmod a+x /usr/share/urbackup/www/{css,fonts,js,images,}

Well I just saw this issue too, i’ll update the package

1 Like

Improving quotas is too big an issue and will unfortunately have to wait till the next version. Having a second space usage without dedup is a good idea, yes. In your case it has to free more space than the client actually uses which causes the error message.

Yes. That is the fix. See the CBT change log I uploaded.

Thanks for the answer. It’s there any workaround or solution to this issue?

I’m unable to compile UrBackup server anymore with gcc 6.1.1. This is the error I get:

urbackupserver/filedownload.cpp: In member function ‘void FileDownload::filedownload(std::__cxx11::string, std::__cxx11::string, int, int, SQueueStatus)’:
urbackupserver/filedownload.cpp:116:71: error: cannot convert ‘bool’ to ‘IFile*’ for argument ‘7’ to ‘bool build_chunk_hashs(IFile*, IFile*, INotEnoughSpaceCallback*, IFsFile*, bool, int64*, IFile*, bool, IHashFunc*, IExtentIterator*)’
build_chunk_hashs(dstfile, hashfile, NULL, NULL, false, NULL, false);
make[2]: *** [Makefile:4157: urbackupserver/urbackupsrv-filedownload.o] Error 1
make[2]: Leaving directory ‘/usr/local/src/urbackup-server-2.0.30’
make[1]: *** [Makefile:5941: all-recursive] Error 1
make[1]: Leaving directory ‘/usr/local/src/urbackup-server-2.0.30’
make: *** [Makefile:1259: all] Error 2

Thank you.

Just testing the client on arch – several small path issues:
starting the settings dialog from the gui fails with

execvp(/usr/binurbackupclientgui, settings) failed with error 2!

(note the missing / after bin)

The systemd file points to /usr/local/sbin/urbackupclientbackend, but the binary is in /usr/bin/.
And a very tiny note: the gui doesn’t mention it wants to be root, you only get “failed to read password file” when trying to start backups etc.

Thanks for the packaging work though, I just love that the AUR has so much goodness like this!

Thanks for reporting. This is a missing slash in the code.

It should be able to read pw.txt without root and require root to read pw_change.txt. So this might be a path permission issue again.

Is this even the correct place to report AUR packaging issues? :slight_smile:
I just noticed there should be a dependency on gksu and lsb-release…

Hi today I had this strange backup on a pc with last release of UrBackup. What this means? Thanks

`UrBackup just did an incremental file backup of “MONICA-PC”.

( 4 infos, 0 warnings, 5 errors )

2016-07-05 09:00:33(info): Starting incremental file backup…
2016-07-05 09:02:55(info): Scanning for changed hard links on volume of “Archivio Dati”…
2016-07-05 09:02:55(info): Cannot open file \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6\users\appdata\local\microsoft\windows live mail\sent items\00294823-0000001E.eml to read the file attributes
2016-07-05 09:02:55(info): Cannot open file \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6\users\appdata\local\microsoft\windows live mail\sent items\00294823-00000025.eml to read the file attributes
2016-07-05 09:02:55(error): Cannot access path to backup: “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6” Errorcode: 3 - Impossibile trovare il percorso specificato.
2016-07-05 09:02:55(error): backupcom->DeleteSnapshots(dir->ref->ssetid, VSS_OBJECT_SNAPSHOT, TRUE, &dels, &ndels) failed .VSS error code VSS_E_OBJECT_NOT_FOUND
2016-07-05 09:02:55(error): Deleting shadowcopy failed.
2016-07-05 09:02:55(error): Constructing of filelist of “MONICA-PC” failed: error - index error
2016-07-05 09:03:03(error): Backup had an early error. Deleting partial backup.`

On Windows 2012 R2 clients, VSS shadow copies are not deleted after backups, and we have these kind of messages in backups logs :

2016-07-11 22:04:38(info): Starting incremental file backup...
2016-07-11 22:05:11(info): Not restarting/using existing shadow copy of C:\ because it was not created for image backups/file backups (for_imagebackup=false)
2016-07-11 22:05:11(info): Not restarting/using existing shadow copy of C:\ because it was not created for image backups/file backups (for_imagebackup=false)
2016-07-11 22:05:11(info): Scanning for changed hard links on volume of "EIC"...
2016-07-11 22:05:11(info): Indexing of "EIC" done. 4 filesystem lookups 38 db lookups and 3 db updates
2016-07-11 22:05:11(info): SV316: Loading file list...
2016-07-11 22:05:25(info): SV316: Calculating file tree differences...
2016-07-11 22:05:26(info): SV316: Creating snapshot...
2016-07-11 22:05:37(info): SV316: Deleting files in snapshot... (8)
2016-07-11 22:05:38(info): SV316: Deleting files in hash snapshot...
2016-07-11 22:05:40(info): SV316: Calculating tree difference size...
2016-07-11 22:05:40(info): SV316: Linking unchanged and loading new files...
2016-07-11 22:08:09(info): Waiting for file transfers...
2016-07-11 22:08:30(info): Waiting for file hashing and copying threads...
2016-07-11 22:08:31(info): Saving file metadata...
2016-07-11 22:08:36(info): Writing new file list...
2016-07-11 22:08:36(info): All metadata was present
2016-07-11 22:08:36(info): Number of re-added file entries is 243
2016-07-11 22:09:07(info): Transferred 132.854 KB - Average speed: 5.872 KBit/s
2016-07-11 22:09:07(info): (Before compression: 280.684 KB ratio: 2.11271)
2016-07-11 22:09:07(info): 1 MB of files were already present on the server and did not need to be transferred
2016-07-11 22:09:09(info): Time taken for backing up client SV316: 4m 30s
2016-07-11 22:09:09(info): Backup succeeded

Is it the expected behaviour, because backups are made from old snapshots, right ?


This was to fix simultaneous file and image backups. I’ll see what I can do in the case where there is no simultaneous file and image backup.