The portable Linux client doesn’t have C+±exception support (yet). In my tests everything was functional but this is something that must be resolved before releasing a non-beta version.
Changes with server 2.0.24 beta
Renamed ERR_FILE_DOESNT_EXIST to ERR_CANNOT_OPEN_FILE. Do not stop backup if this error occurs during patch file download
Reset channel if session identity changes to keep the current session identity refreshed
Adler32 does not work well with small strings. Use md5 instead. Fix bug where the modulo was calculated on a negative number
Do not try to trim beyond drive size if drive size is not aligned to ntfs block size
Fix dead lock in connection with directory sym-linking
Changes with server 2.0.23 beta
Make hash file match incremental VHD file content as well
Make synthetic full VHD files mountable with the build-in VHD driver on Windows
Fix crash with VHD file backup
Fix remove_unknown and cleanup crash
Log error before assertions
Prevent race condition that can cause more than configured max simultaneous backups
Changes with server 2.0.22 beta
Do not do passive WAL checkpoints during database backup as this can cause corrupted database backups
Fixed settings reader locking/threading issues
Made the image hash file match the btrfs cow-raw file contents to avoid subtle errors
Fix resetting file sparse extent iterator while patching
Log existing file info on hash collision/wrong entry with debug log level
Improve symbolic link creation error on status page. Show symlink error only if file backups are enabled
Put file index creation into transaction to avoid reads/locks
Fix bug where scheduled backup was run instead of manually started one
Handle current block being greater than total number of blocks during image backup
Write basic meta-data also if link source cannot be opened or does not exist
Improve Windows service shutdown
copy_file_entries_sparse_modulo should be at least one
Changes with client 2.0.20 beta
For debugging: Ability to create md5sum file for image backup
Fix file server thread getting stuck after read error on Windows causing infinite meta-data transfer
Reuse existing status process instead of starting new one on image backup resume
Improve Windows service shutdown
Exclude datto cow file and device mapper overlay files on Linux
Made Windows updater more robust with regards to file overwrite failures
Remove confusing group from path configuration
Kill service with KillProc for good measure
Todo
UEFI/GPT testing
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 upgraded server from 2.0.21 to 2.0.22. Then, I upgraded one client from 1.4.11 to 2.0.20. If I click on the taskbar icon and select Status, I get a pop-up error that says, “There was an error. Currently nothing can be backed up.”
I upgraded my Ubuntu 64-bit Xenial server from 2.0.21 to 2.0.22. I’ve seen approx. 5 clients run their incremental backups, and I currently have one running the initial full backup. All of my clients were on 2.0.19, Windows 7 Pro.
On a fresh install on Ubuntu the default backup path is set to C:\urbackup, even though it asked me for a backup path during package install and I entered a valid Linux path.
EDIT: The folder I set it to during setup got chowned and backup folders were created for the clients, but no backups were made and I got a “Unable to write to C:\urbackup” error when I first logged on to the webui.
Test the Windows Firewall. May be after update client on Windows, this added new incoming firewall rule. And this rule blocked incoming urbackup traffic.
getting a crash for remove-unknown and cleanup on debian
ignore the libssl errors… thats fine…
(gdb) run
Starting program: /usr/sbin/urbackupsrv cleanup -a 100%
/usr/sbin/urbackupsrv: /usr/StorMan/ssl/lib/libssl.so.1.0.0: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
/usr/sbin/urbackupsrv: /usr/StorMan/ssl/lib/libssl.so.1.0.0: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
/usr/sbin/urbackupsrv: /usr/StorMan/ssl/lib/libcrypto.so.1.0.0: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff29fd700 (LWP 27858)]
2016-05-27 14:22:53: Shutting down all database instances...
2016-05-27 14:22:53: Opening urbackup server database...
[New Thread 0x7ffff0ffb700 (LWP 27859)]
[New Thread 0x7fffebfff700 (LWP 27860)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffebfff700 (LWP 27860)]
0x0000000000731099 in WalCheckpointThread::waitAndLockForBackup() ()
(gdb) bt
#0 0x0000000000731099 in WalCheckpointThread::waitAndLockForBackup() ()
#1 0x0000000000732b70 in WalCheckpointThread::operator()() ()
#2 0x000000000041ae16 in thread_helper_f(void*) ()
#3 0x00007ffff6ddf0a4 in start_thread (arg=0x7fffebfff700) at pthread_create.c:309
#4 0x00007ffff6b1487d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)
Okay, thanks. I just noticed that none of my servers are backing up anymore. I have just the one client on 2.0.20 and the rest are still 1.4.11. Even when I try to do a manual image backup, it doesn’t finish or get far. So, I’ll try the new version when you release it.
My UrBackup Server is on Windows 2008 R2. Ever since I upgrade from 2.0.5 beta to 2.0.22, none of my backups will run. When I manually do an incremental image, the SYSVOL completes, but when it gets to the main drive, it just sits at 0% and eventually dies. I also tried to do a full image backup, and it does the same thing. After a few minutes of sitting at 0%, the server portal website says something like “website closing due to inactivity” and then when I click okay, the server portal website goes back to login screen and it is like the backup job never existed. There are no logs that it started or failed or anything.
@uroni - I just updated to 2.0.23. My backups appear to be running now. But “max simultaneous backups” is ignored. I have it set =2, but all seven servers started at once.
That seemed to have fixed the crashing issue. I have been up for a few hours on the beta test now.
For what it is worth, if you were to introduce a feature where we could select where to save our log files to, I would be more than happy to save my log files to a Google Drive or other option that would automatically share the log files with you without intervention. Not sure how much work that would be, or how helpful it would be for you, but I would be happy to do so if you gave us the option.
If I haven’t had any good incremental image backups for about 3 days now, do I need to run a full image backup? I just ran an incremental image backup and got this error:
UrBackup just did an incremental image backup of “TESTINGSERVER”.
Report:
( 4 infos, 0 warnings, 2 errors )
2016-05-29 02:27:05(info): Starting incremental image backup…
2016-05-29 02:28:48(info): Basing image backup on last full image backup
2016-05-29 05:22:06(error): Error setting unused area (from byte 53578559488 to byte 53578563584). The operation completed successfully. (code: 0)
2016-05-29 05:22:18(info): Transferred 11.6834 GB - Average speed: 9.65737 MBit/s
2016-05-29 05:22:18(info): Time taken for backing up client TESTINGSERVER: 2h 55m 12s
2016-05-29 05:22:18(error): Backup failed
Can you have a look at the log file at /var/log/urbackup.log before the line Error setting unused area there should be another error message. Can you post that? Thanks!
If there is no message, how big is the volume you are backing up?
