Incremental SQL backup is successful but it can't be restored

UrBackup Server: 2.3.8, OS Ubuntu 16.04.6 LTS, File System LVM, ext4
UrBackup Client: version: 2.3.4, OS Windows Server 2008 R2 with SQL Server 2008 R2 installed

SQL windows component can not be restored after an incremental file backup.

Reproduce steps 1:

  1. Fresh install the server and client.
  2. Config the client to backup SQL component.
  3. Execute a full file backup and wait for it finished
  4. Download the SQL component backup file via web-UI to confirm the full backup is OK.
  5. Execute a incremental file backup and wait for it finished.
  6. Download the SQL component files in this incremental backup. You will get an invalid ZIP file.
  7. Now try to download the SQL component files in the previous backup (full backup). You will get an invalid ZIP file too!
  8. If the files can be downloaded, unzip it and take a look at *.mdf file’s “modified datetime”.
  9. In my case, I always use SqlServerWriter->master to test.

It seems to me there are something wrong with the file link as I mentioned in the other thread:

After I disabled "Use symlinks during incremental file backups” and enabled “Debugging: End-to-end verification of all file backups” in the advanced settings, I tried the above steps again. This time the files can be downloaded. BUT something is still WRONG!!!

I keep getting error message from the server log when downloading. It reports:
ERROR: Error while adding files and folders to ZIP archive
ERROR: Error while adding file “/repo/WIN-UUNOK8B4N39/190422-1914/.symlink_SqlServerWriter_{A65FAA63-5EA8-4EBC-9DBD-A0C4DB26912A}_ae2b4cde59afa2ab20f1a6b080698836_master_files00000000/master.mdf” to ZIP file. Error: compression failed. OS error: Broken pipe (code: 32)

What’s most important, the files I download from the latest backup is not the latest file! Both full backup and Incremental backup always return me the oldest backup file.

If the end-to-end verification does not fail, this is probably just the file not changing between backups.

I don’t think so. The file has already changed and I can locate the latest file in the backup server. The latest file is the path of directory “.hashes” .

root@urbackup:/repo/WIN-UUNOK8B4N39/190422-1914# ls -l ./.hashes/.symlink_SqlServerWriter_{A65FAA63-5EA8-4EBC-9DBD-A0C4DB26912A}ae2b4cde59afa2ab20f1a6b080698836_master_files00000000/master.mdf
-rwxr-x— 1 root root 432 Apr 22 19:14 ./.hashes/.symlink_SqlServerWriter

root@urbackup:/repo/WIN-UUNOK8B4N39/190422-1914# ls -l ./.symlink_SqlServerWriter_{A65FAA63-5EA8-4EBC-9DBD-A0C4DB26912A}ae2b4cde59afa2ab20f1a6b080698836_master_files00000000/master.mdf
-rwxr-x— 1 root root 4194304 Apr 17 19:39 ./.symlink_SqlServerWriter

There are two “master.mdf” files here. The one in “.hashes” has the timestamp “Apr 22 19:14” while the one in “190422-1914/.symlink…” has the timestamp “Apr 17 19:39”. Obviously, the first one is what I want, and the later one is the file I got from the restore/download.

The file in the “.hashes” is still not correct yet! Though its timestamp is correct, but its size is not correct. It is only 432 Bytes while the original file has almost 4MB.

Any update about this issue? This is a very common operation. I am wondering why there are not other users report it? Is this project still active?

Except for the symlink issue it is working as intended as far as I know (as I already said above). See here on why the last modify time might not change.