Ability to reconnect during indexing if connection is broken
Define which volumes need to be snapshotted together (snapshot groups)
Image backup mounting, browsing and archival on Windows, Linux and FreeBSD (does not work in FreeBSD jails and with VHD/VHDZ on FreeBSD)
Major changes with client 2.1.x
Ability to reconnect during indexing if connection is broken
Improved image backup performance
Windows Backup API support (tested backup and restore with Microsoft SQL, tested backup with Microsoft Exchange and Hyper V)
File backups and restores use the change block data from the change block tracking driver now (you can install the beta client over a CBT client and this will work)
Define which volumes need to be snapshotted together (snapshot groups)
Changes with server 2.1.17 RC
Resize VHD/cow-raw file when opened with parent file and size changes
Fix assert for last trim in image backup (caused assertion failure in some cases)
Linux/FreeBSD: Remove urbackupsrv from sbindir during make install
Changes with client 2.1.13 RC
Updated translations
Allow deletion of open hdat_file_vol.dat files on Windows
More logging on some CBT failures
Upgrade process
As always: Replace the executables (via the installers) and the database of the server/client will be updated on first running it.
Download of client update files should now work.
Downgrade process (server)
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.
because when I downloaded the client the first time, the .sig2 files didn’t get updated. This should help to clean out any old files and ensure the correct files are in place.
my urbackup server have been working flawless since 2.0.x beta versions and later upgraded to 2.1.x but in newer beta versions it have been a bit unstable for last week.
urbackup server daemon dies every day, and I need to restart service.
Last line in log file before I restart it again is: 2017-02-12 03:23:16: WARNING: Exponential backoff: Waiting at least 40m before next file backup
im running it on debian jessie with backport kernel, btrfs as storage.
I’ve updated to this current version (2.1.17 / 2.1.11 client.) Running an internet server for off-site file backups of client computers.
I recently added a computer that runs SQL Express 2005, Server 2008 R2. It’s not able to complete a backup. Each time the error log contains this (sanitized for privacy):
2017-02-19 10:30:16(info): Starting unscheduled full file backup…
2017-02-19 10:31:13(error): Cannot access path to backup: “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy67\program files (x86)\folder\database” Errorcode: 123 - The filename, directory name, or volume label syntax is incorrect.
2017-02-19 10:31:13(error): Cannot access path to backup: “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy67\program files (x86)\folder\database” Errorcode: 123 - The filename, directory name, or volume label syntax is incorrect.
2017-02-19 10:31:13(error): Cannot access path to backup: “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy67\program files (x86)\folder\database” Errorcode: 123 - The filename, directory name, or volume label syntax is incorrect.
2017-02-19 10:31:13(error): Cannot access path to backup: “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy67\program files (x86)\folder\database” Errorcode: 123 - The filename, directory name, or volume label syntax is incorrect.
2017-02-19 10:31:13(info): Removing unconfirmed VSS path “.symlink_SqlServerWriter_{A65FAA63-5EA8-4EBC-9DBD-A0C4DB26912A}_812deaa19cc9dee311e2a033fbe7a2dd_files00000000” to "C:\Program Files (x86)\folder\Database
2017-02-19 10:31:13(error): Constructing of filelist of “client site” failed: error - index error
2017-02-19 10:31:17(error): Backup had an early error. Deleting partial backup.
I have the settings configured to allow clients to configure windows components to be backed up.
On the client, UrBackup had automatically selected the “SqlServerWriter” tree of windows components to be backed up. I turned this off, and now it seems to be running (it’s currently indexing…)
Any thoughts on the error? It would be nice to backup the SQL instance, but not sure if it’s fully working yet?