I built rpm package for CentOS 7. You can download them at the link https://yadi.sk/d/8qmB64sSrCp6U
Exchange edb incremental backup is not looking for changed bits with .10 client backing up to .12 server. I triggered the first full and incremental manually, then let it run on it’s own for a day. It had time for two more incremental backups. All four were nearly the same size.
I ran a different open backup that also ignores file modified time. The incremental block diff backup was 250mb after a day.
You could use “Debugging: End-to-end verification of all file backups” in the advanced tab to confirm that it does something wrong.
Then could you post the client Windows and Exchange version?
Bug? Clicking on Access/restore backups on Windows 10 Pro x64
or
results in:
No rights to access any files.
Error getting server URL. Cannot access files.
Configuration:
Server 2.0.12 [Debian 8.3] / Client 2.0.10 [Windows 10 Pro x64 - fresh install for testing UrBackup]
To be sure it isn’t a server/client configuration issue, I installed the same client/name/internet auth key on a Windows 2012R2 system and had no problems accessing the backups.
OS = Server 2008 R2
Exch Ver = 2010 v 14.03.0266.001
Logs:
Info
04/25/16 02:34
Starting incremental file backup…
Info
04/25/16 02:43
Writer Microsoft Exchange Writer has failure state VSS_WS_WAITING_FOR_BACKUP_COMPLETE with error VSS_E_WRITERERROR_RETRYABLE
Warnings
04/25/16 02:43
Snapshotting failed because of Writer. Retrying in 30s…
Info
04/25/16 02:43
Writer Microsoft Exchange Writer has failure state VSS_WS_STABLE with error VSS_E_WRITERERROR_RETRYABLE
Info
04/25/16 02:43
Writer Microsoft Exchange Writer has failure state VSS_WS_WAITING_FOR_BACKUP_COMPLETE with error VSS_E_WRITERERROR_RETRYABLE
Warnings
04/25/16 02:43
Snapshotting failed because of Writer. Retrying in 30s…
Info
04/25/16 02:43
Writer Microsoft Exchange Writer has failure state VSS_WS_STABLE with error VSS_E_WRITERERROR_RETRYABLE
Warnings
04/25/16 02:43
Writer Microsoft Exchange Writer has failure state VSS_WS_WAITING_FOR_BACKUP_COMPLETE with error VSS_E_WRITERERROR_RETRYABLE. UrBackup will continue with the backup but the associated data may not be consistent.
Warnings
04/25/16 02:43
Writer is in error state during snapshot creation. Writer data may not be consistent. This means the files open by this application (e.g. databases) will be backed up in a crash consistent state instead of a properly shutdown state. Properly written applications can recover from system crashes or power failures.
I have the same combination running and verifying backups with the above mentioned setting. The Warnings are normal.
The warnings looked harmless to me. Just Exchange VSS Writer complaining a bit. Posted them because I didn’t want to assume I knew more about backup than you. 
It’s the size of the incremental backup that concerns me. Haven’t tried a restore test.
Does anybody know where the source code for UrbackupClientBackend.exe is? I couldn’t find it.
Thanks，
Issue: Image backups not starting automatically.
Configuration:
Server 2.0.12 [Debian 8.3] / Client 2.0.10 [Windows 10 Pro x64 - fresh install for testing UrBackup]
Manually starting the image backup works fine:
FreeBSD 10.3
Server does not complile… curl and cryptopp are installed via pkg
Name : curl
Version : 7.48.0_1
Name : cryptopp
Version : 5.6.2_2
make.log (40.3 KB)
seems like this is a problem only with the pkg versions…
installed cryptopp from ports and it works
Full image backup of SYSVOL is always made even during incremental image backups. Is it possible to do incremental image backups of the SYSVOL volume? Otherwise, computers with large SYSVOL volumes take a long time to backup over the internet:
Configuration:
Server 2.0.12 [Debian 8.3] / Client 2.0.9 [Windows 7 Pro x64]
Edit: I’m just going to exclude SYSVOL from image backups for now on this client…
If you look here:
It is renamed from the Server.exe file in the update_data.bat.
The general process is that you compile everything and then run the update_data.bat scripts before running the packaging scripts to get the installer.
During the 2 last incremental backups of a Win 2k12 R2 server, we have the following error message in urbackup.log server log :
2016-04-26 22:50:22: WARNING: Read error in hash calculation at position 4096 toread=32768 read=0. This will cause the whole block to be loaded.
2016-04-26 22:52:54: WARNING: Not all folder metadata could be applied. Metadata was inconsistent.
2016-04-26 22:53:36: ERROR: Connection broken: Removing shadow copy on "SV408" for path "SavDossiers" failedAnd backup hangs at 2%
Edit : hangs at 2% for a long time and then continue but slowly with a new error message :
2016-04-26 23:23:36: ERROR: Connection broken: Activating shadow copy on "SV408" for path "Fichiers" failed
2016-04-26 23:23:36: ERROR: Timeout during flush requestNo problems with other 11 Win 2K12R2 clients.
Any ideas on how we can fix ?
Regards,
How can I prevent the swapfile.sys error?
Does it do automatic backups after the initial backup?
If you manually exclude C:\swapfile.sys it should work.
No.
Hi,
This morning the urbackup server was down and in the server logfile we have :
2016-04-28 00:23:53: WARNING: Read error in hash calculation at position 4096 toread=32768 read=0. This will cause the whole block to be loaded.
2016-04-28 00:28:05: WARNING: Read error in hash calculation at position 68719476736 toread=8192 read=0. This will cause the whole block to be loaded.
2016-04-28 00:28:05: ERROR: Chunk not requested. (68719476736)
2016-04-28 00:28:05: ERROR: Pending chunk: 0Regards,
Is the connection to that client encrypted?
Normally it would not stop with that error, but it is currently still in error finding mode and therefore stops. Either the client sends the server garbage sometimes or there is a bug. In the second case a server debug log would be helpful.
No encryption, only compression (Internet client with hashing on client side). There was 12 clients running simultaneously so i can’t determinate which one cause the failure, maybe i’ll have to try to launch them individually and see which one is involved ?
Complete server log file sequence :
2016-04-27 22:04:37: WARNING: Cannot retrieve last file backup when doing incremental backup. Doing full backup now...
2016-04-27 22:04:37: ERROR: No permission to access "/media/backup/urbackup_btrfs/SV408/160427-2204"
2016-04-27 22:57:21: ERROR: Unknown Packet ID in State_First
2016-04-27 22:57:21: ERROR: Error getting file patch for "JjumQSQ8qzkb3VU1JEid|isagiwf/B441138.COW/SKSVCAT.PX" from SV413. Errorcode: ERROR (6)
2016-04-27 22:57:22: ERROR: Client SV413 went offline.
2016-04-27 23:01:06: WARNING: Read error in hash calculation at position 1152921504606846976 toread=8192 read=0. This will cause the whole block to be loaded.
2016-04-27 23:01:06: ERROR: Chunk not requested. (1152921504606846976)
2016-04-27 23:01:06: ERROR: Pending chunk: 0
2016-04-27 23:24:35: WARNING: Cannot retrieve last file backup when doing incremental backup. Doing full backup now...
2016-04-27 23:24:35: ERROR: No permission to access "/media/backup/urbackup_btrfs/SV408/160427-2324"
2016-04-27 23:26:30: WARNING: Restarting shadow copy of T:\ because it was started by this server
2016-04-27 23:27:32: WARNING: Restarting shadow copy of T:\ because it was started by this server
2016-04-27 23:27:33: WARNING: Restarting shadow copy of T:\ because it was started by this server
2016-04-27 23:27:57: WARNING: Restarting shadow copy of T:\ because it was started by this server
2016-04-27 23:28:11: WARNING: Restarting shadow copy of T:\ because it was started by this server
2016-04-27 23:28:18: WARNING: Restarting shadow copy of T:\ because it was started by this server
2016-04-27 23:28:24: WARNING: Restarting shadow copy of T:\ because it was started by this server
2016-04-27 23:28:45: WARNING: Restarting shadow copy of T:\ because it was started by this server
2016-04-28 00:00:06: WARNING: Restarting shadow copy of C:\ because it was started by this server
2016-04-28 00:00:06: WARNING: Restarting shadow copy of T:\ because it was started by this server
2016-04-28 00:23:53: WARNING: Read error in hash calculation at position 4096 toread=32768 read=0. This will cause the whole block to be loaded.
2016-04-28 00:28:05: WARNING: Read error in hash calculation at position 68719476736 toread=8192 read=0. This will cause the whole block to be loaded.
2016-04-28 00:28:05: ERROR: Chunk not requested. (68719476736)
2016-04-28 00:28:05: ERROR: Pending chunk: 0