UrBackup Server 2.0.33 RC/Client 2.0.32 RC

Changes with server 2.0.33

  • Fix updating client access token after client changes it
  • Fix directory symlink to directory change
  • Continue image backup after getting MBR for dynamic volume failed
  • Fix cleanup and repair commands
  • Do not run backup cleanups after writing failures during file metadata download
  • Do not log to memory when logging cleanups etc.
  • Fix relative VHD file locator for new naming scheme
  • Improve error message if copying database fails during database backup
  • Trim Windows command line args from args.txt
  • Preallocate space for full image if possible to prevent fragmentation
  • Added Finnish translation (by Jussi Bergström)
  • Save partial backup after client read error
  • Do not try to open files if metadata is sent via callback during restore on Windows

Changes with client 2.0.32

  • Keep last client access key to prevent race between old and new key
  • Fixed memory leak after restore
  • Trim Windows command line args from args.txt
  • Persist backup dir flags through saves via command line client
  • Added Finnish translation (by Jussi Bergström)
  • Remove image backups from command line client on non-Windows systems
  • Correctly read tokens on macOS in command line client
  • Prevent tray icon from starting more than once per user on all OS
  • Added C:\Windows.old to default excludes
  • Fix enable_internet_only.bat (try #2)

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.

On Linux e.g. with:

cd /var/urbackup && wget -r -l1 --no-parent --reject "index.html*" -nH -nd -N https://www.urbackup.org/downloads/Client/2.0.32/update/


I have some concerns about this. Maybe I’m just not understanding it correctly. I have a fair number of computers that I want to backup that have 500GB drives of which maybe only 90GB is being used. If 4 computers happen to have full image backups running at the same time, I suddenly need to have 2TB+ of free space available when I would only need to have about 360GB.

In this same scenario it could actually increase fragmentation if the client drive is not very full. A 500GB mostly-contiguous image file would be allocated and then when the image was complete and the sparse holes were punched into it I could end up with a bunch of extents in the middle that are released.

How would this work when using BTRFS and raw cow images? Since every full image backup after the initial is really just an incremental?