Use reflinks on file systems that do not have snapshot/subvolume support (only XFS for now)
Run backup storage checks asynchronously from status screen
Allow client renames in some cases
Preparations for special Hyper-V client with disk images instead of volume images
Allow client to restore its own image backups (image restore with normal client)
Changes with server 2.3.2 beta
Load all lua modules per default
Do not strip debug information (line numbers) when compiling lua script
Comment to disable lua code compilation
Changes with server 2.3.1 beta
Functionality to log file changes in incremental image backups
Seek to correct position in source file before sending when resuming image restore
Return error correctly when server runs out of space during file backup in a corner case
Only use CURLOPT_EXPECT_100_TIMEOUT_MS if curl version is high enough
Fix Crypto++ 6.0 byte compile issue
Prevent cleanup from deleting incremental image chains that cause number of incremental images to fall below min_incr_image (in testing)
Changes with server 2.3.0 beta
Improve space accounting if reflinking is replaced by copying
Alert/status fixes
Set json content type when returning json in web interface
Stop parallel hash download thread in all cases
Parallel file hashing fixes
Add Pulseway alert script (mainly as an example)
Improve out of space error handling
Log login attempts where username does not exist as failed login attempts
Fix settings threading issue
Log failed client authentications into auth log (Linux)
Changes with client 2.3.1 beta
Fix permission translation for Linux and macOS
Changes with client 2.3.0 beta
Retry llistxattr with a multiple of the required memory if it fails
Cooperate CBT with multiple running clients
Don’t show restore components option if components never have been backed up
Fix change indicator of open files such that the symbolic link detection works for them
Read USNs of symbolic links and directories on Windows instead of last modified time to detect directory metadata changes
Fix file permission translation on Linux/MacOS
Fix Crypto++ 6.0 byte compile issue
Handle reparse tag IO_REPARSE_TAG_APPEXECLINK on Windows
Backup VeraCrypt boot loader
Improve log message if indexing is interrupted
Changes with Restore CD 2.2.1 beta
Restore whole disks (created with Hyper-V client)
Continuously track image download progress for resume
Restore VeraCrypt boot loader
Changes with Restore CD 2.2.0 beta
Bugfix: In some cases the restore did not continue at the most recent position when it had to reconnect to the server
Build with default Debian stretch live-build and not the accumulation of patches, fixes and manual changes I had beforehand
Upgrade process
As always: Replace the executables (via the installers) and the database of the server/client will be updated on first running it.
Place the files from the update directory into C:\Program Files\UrBackupServer\urbackup or /var/urbackup to auto-update clients. Disable Download client from update server in the server settings to prevent the server from downloading the current version.
Stop the UrBackup server, restore C:\Program Files\UrBackupServer\urbackup or /var/urbackup from a backup before upgrade and then install the previous version over the beta release.
Getting failed image backups both with server beta 2.3.1 and 2.3.2, both against matching beta clients, in a way similar to kiga’s report. All failures are on Internet clients, but only 3 of 5 so far. The other two clients worked for the most recent image incremental under server 2.3.1.
Settings are the same for both succeeding and failing Internet clients, which are branch office Windows Server 2008r2 with very similar contents. Both incremental and (Internet style) synthetic full backups fail.
Local clients (Win7pro) haven’t reported any new problems so far; both full image and incrementals succeed, and local full file and incrementals succeed.
Typical client error log on server, from the first test of 2.3.2:
Info 10/13/18 22:48 Starting unscheduled full image backup of volume "C:"...
Info 10/13/18 22:48 Basing image backup on last incremental or full image backup
Errors 10/13/18 22:49 Error opening VHD file "E:\UrBackup\Schertz\181013-2248_Image_C\Image_C_181013-2248.vhdz"
Info 10/13/18 22:49 Transferred 6.06271 MB - Average speed: 1.53269 MBit/s
Info 10/13/18 22:49 Time taken for backing up client Schertz: 35s
Errors 10/13/18 22:49 Backup failed
Addendum: I see no differences in file security properties for the saved Image_C files between succeeding and failing clients to account for the failure to open.
Would have sworn that’s the one I checked permissions on last night, but it isn’t there now, nor is it listed on the Backups tab for Schertz. No mention of that file in app.log or urbackup.log until the recent error opening message, and both start before 180915. [I searched the logs for “180915” which is in the filename.] The debug log posted earlier was created just for that one test. I also do a nightly Windows Backup, but the UrBackup storage path (E:\UrBackup) is excluded so no help there.
From time to time I’ve seen the latest incremental file backups deleted automatically, but don’t recall it happening with images. Trying to fix that is why I’m trying the 2.3.x beta versions here instead of the 2.2.11 release used previously. 2.3.0 was installed July 4, 2.3.1 on September 27, and 2.3.2 on October 13.
Trying to open any of the later image backups crashes urbackup_srv.exe, as pasted from Event Viewer below. The earlier (and only remaining) full image of C from 180908 opens immediately. The other two images, incrementals from 180929 and 181006, both fail to open. I have the most recent 631MB crash dump file saved, if that’s useful.
I can delete the Schertz client and files if a clean slate is needed. I’d rather not wipe the whole server install and 3.2TB of backups but that can be done if necessary.
Excerpt from C:\Program Files\UrBackupServer\urbackup.log:
Thanks, could reproduce the problem. Server 2.3.3 beta/Restore 2.2.2 beta probably fixes it (not the crash though), though you’ll have to run a new full image backup.
Thank you for the update. With 2.3.3 synthetic full image still fails with same file not found issue. Going to painfully slow (using 10Mbit uplink) real full works under 2.3.2 and 2.3.3. Will check tonight if incrementals work.
Incremental image backups of previously-failing Internet clients has succeeded under 2.3.3 following a successful full (non-synthetic) backup. Should the problem recur I will post to a new topic.
Thank you for continuing to care about UrBackup and us needy users.
Hi @uroni,
on a a brand new vanilla Xubuntu 18.04 installation I directly installed the urbackup server 2.3.1 beta and urbackup client 2.3.1 beta from sources. Upon further testing of the urbackupclientgui beta as a standard (non-privileged) user I missed a feature " right click a file/directory in a backup path and then click on “Access/restore backups” as noted in chapter " 9.2 Restoring file backups" of the server administration manual.
This feature is available on the Windows client beta but it seems to miss on the Linux side. So I am not sure whether I do something wrong or if this feature is just missing on Linux. Any hint would be appreciated.
That’s almost impossible to do as a generic thing. There are too many file managers.
All desktop environnements use a different ones.
So you’d need like filer, nautilus, konqueror, pcmanfm and whatnot.
Under Linux the restore operation is conditioned on a setting in /etc/default/urbackupclient. Examining that file shows this helpful text:
# Valid settings:
#
# "client-confirms": If you have the GUI component the currently active user
# will need to confirm restores from the web interface.
# If you have no GUI component this will cause restores
# from the server web interface to not work
# "server-confirms": The server will ask the user starting the restore on
# the web interface for confirmation
# "disabled": Restores via web interface are disabled.
# Restores via urbackupclientctl still work
#
RESTORE=disabled
Perhaps you need to change this value to enable restores. Also see section 9.2 of the Server Admin Guide for more on why this is needed.
Hi Don_Wright,
thanks for the hint. I tried all of the three options in the settings.
However, none of them revealed the feature
" right click a file/directory in a backup path and then click on “Access/restore backups” as noted in chapter " 9.2 Restoring file backups " of the server administration manual.
Thanks orogor for the explanations. So it seems that this feature is missing in the urbackupclientgui. @uroni, could you please confirm this finding?
If so the admin manual might be somehow misleading with regard to the urbackupclientgui. So I would suggest a slight adaption of this section in chapter 9.2 of the admin manual to: “Since UrBackup 2.0.x users can directly access the web interface from the client if a server URL is configured. Either they right-click on the UrBackup tray icon and then click “Access/restore backups” which opens the browser, or they can right click a file/directory in a backup path and then click on “Access/restore backups” to access all backups of a file/directory.” The latter only works on Windows and macOS operation systems.