UrBackup Server 2.0.29 RC/Client 2.0.28 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.29

  • Now built without runtime assertions
  • Uploaded the Debian package where everything (except glibc) is statically linked

Changes with client 2.0.28

  • Now built without runtime assertions

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




Thanks for the statically linked version, it seems to work with Ubuntu 16.04. I’ve been running it since this morning without any noticeable issues.



I’m bumping a question that was unresolved on server 2.0.27 thread, and that I’ve just confirmed on 2.0.29 with client 2.0.28:

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.


Cleanup of old backups is working but i have a strange behaviour in the “activities” section.
Deleted images backups first appears correctly and after few seconds / minutes disappear from the activities pages :

Any ideas ?



Yesterday I upgraded server version to 2.0.29RC.
The client OS is Windows XP and the Urbackup client version is 1.4.11.

I tried to restore files from server but there isn’t Restore Button.
The “Created, Last modified, Last accessed” fields are empty.
The Full Image restore with the Restore CD(version: 2.0.1 beta) works.

Should I downgrade the client version?

Thank you,
Best Regards.


Having an issue upgrading from 1.4.14 to 2.0.29 here is the error. Any suggestions?

2016-06-17 08:38:50: WARNING: Upgrading…
2016-06-17 08:38:50: WARNING: Converting database to delete journal mode…
2016-06-17 08:38:50: WARNING: Upgrading database to version 36
2016-06-17 15:06:59: WARNING: SQLite: table files already exists errorcode: 1
2016-06-17 15:06:59: ERROR: Error preparing Query [CREATE TABLE files_db.files (id INTEGER PRIMARY KEY,backupid INTEGER,fullpath TEXT,shahash BLOB,filesize INTEGER,created INTEGER DEFAULT (CAST(strftime(’%s’,‘now’) as INTEGER)),rsize INTEGER, clientid INTEGER, incremental INTEGER, hashpath TEXT, next_entry INTEGER, prev_entry INTEGER, pointed_to INTEGER)]: table files already exists
2016-06-17 15:06:59: ERROR: Upgrading database failed. Shutting down server.


Is that directly on the first try, or was it previously interrupted?


The boss decided to crash my server the first time…

This is the second try.


Sorry, theoretically it should cope with being interrupted. The best option would be to retry with an pre-update database backup. Otherwise it needs some database doctoring with the sqlite command line utitlity or SQLite Browser. With that, what does

sqlite3 backup_server.db

SELECT COUNT(*) files;



sqlite> SELECT COUNT(*) files;


What does

sqlite3 backup_server_files.db

SELECT * FROM files_incoming_stat;



sqlite> SELECT * FROM files_incoming_stat;
Error: no such table: files_incoming_stat
sqlite> SELECT COUNT(*) FROM files;


Then it’ll probably work if you delete backup_server_files.db (or just the files table in backup_server_files.db with DROP TABLE files). If you did any file backups the question is where your file entries have gone, though.


Getting this now

2016-06-20 13:02:20: WARNING: Upgrading…
2016-06-20 13:02:20: WARNING: Converting database to delete journal mode…
2016-06-20 13:02:20: WARNING: Upgrading database to version 36
2016-06-20 13:02:20: WARNING: SQLite: no such index: files_idx errorcode: 1
2016-06-20 13:02:20: ERROR: Error preparing Query [DROP INDEX files_idx]: no such index: files_idx
2016-06-20 13:02:20: ERROR: Upgrading database failed. Shutting down server.

Do I just need to create the table so it sees it?


BTW right before doing the update I canned all the backup files and ran update unknowns.


It previously got further. So something is seriously broken. It does roll back the changes on errors.


Any way to export just the client configs and start over? These are all internet clients with passwords assigned to them.


Only with more db manipulation. I think you need to import and export the contents of the clients table in backup_server.db and the backup_server_settings.db file. The SQLite CLI can import/export: https://www.sqlite.org/cli.html#section_8


We’ll see what happends. Thanks for the help.


After failing a few times at trying to import the data I decided to start fresh and just reinstall all the clients. Everything went smooth except one machine. I keep getting this error after installing the client.

Faulting application UrBackupClient.exe, version, time stamp 0x5761a96b, faulting module api-ms-win-crt-runtime-l1-1-0.d, version 6.0.6001.18538, time stamp 0x4cb73957, exception code 0xc0000135, fault offset 0x00000000000b1b48, process id 0x26f0, application start time 0x01d1ce12c4b9b695.

I tried to remove and reinstall the C++ runtime for every version I could find in x64 and x86 to no avail. Any suggestions?
The old version 1.4 client runs fine on the server. I would just use that but I get a auth/password wrong error but the password in the client matches the web interface.