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
Issue:
SQL windows component can not be restored after an incremental file backup.
Reproduce steps 1:
Fresh install the server and client.
Config the client to backup SQL component.
Execute a full file backup and wait for it finished
Download the SQL component backup file via web-UI to confirm the full backup is OK.
Execute a incremental file backup and wait for it finished.
Download the SQL component files in this incremental backup. You will get an invalid ZIP file.
Now try to download the SQL component files in the previous backup (full backup). You will get an invalid ZIP file too!
If the files can be downloaded, unzip it and take a look at *.mdf file’s “modified datetime”.
In my case, I always use SqlServerWriter->master to test.
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.
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” .
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.