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.
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.
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!
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 ?
