Error restoring Sql Server database

Hi there

I’m having problems restoring database with Windows Components Restore.
17/04/2019 18:18:05: Starting restore operation…
17/04/2019 18:18:05: Collecting information about running writers…
17/04/2019 18:18:08: Selecting components to restore…
17/04/2019 18:18:08: Starting restore operation (pre restore)…
17/04/2019 18:18:08: Restoring file set 0 of of component “ebm_pruebas” of writer “SqlServerWriter” to “C:\Program Files\Microsoft SQL Server\MSSQL11.SQLSERVERCIU\MSSQL\DATA”…
17/04/2019 18:18:09: Restoring file set failed. See restore log for details.
17/04/2019 18:18:09: Restoring file set 1 of of component “ebm_pruebas” of writer “SqlServerWriter” to “C:\Program Files\Microsoft SQL Server\MSSQL11.SQLSERVERCIU\MSSQL\DATA”…
17/04/2019 18:18:11: Restoring file set failed. See restore log for details.
17/04/2019 18:18:11: Restore of component “ebm_pruebas” of writer “SqlServerWriter” failed.
17/04/2019 18:18:11: Finalizing restore operation (post restore)…
17/04/2019 18:18:11: Restore finished.

Windows Version: Windows Server 2012 R2
Urbackup client version: 2.3.4
Urbackup Server version: 2.3.8

Can you check it for me?

Thanks!

I got similar issue and expecting a fix from here. After some digging I found there is a bug for the “Windows Components” 's incremental backup.

===============
Reproduce Steps

a. Perform a full backup for SQL component.
b. The SQL file can be restored or download at this point.
c. Perform a increamental backup for it and wait for it done.
d. Try to download the the latest backup file (the increamental one), you will get a invalid zip file.
e. Try to downlaod the files backup in #a, you will get a invalid zip file too!!

==========================
There are two issues here.



SQL backup file’s soft link is not working after a increamental windows component backup.

$ ls -l /repo/WIN-UUNOK8B4N39/190417-2359
total 12
drwxr-xr-x 4 root root 4096 Apr 17 19:44 lang
lrwxrwxrwx 1 root root 68 Apr 18 00:38 windows_components -> /repo/WIN-UUNOK8B4N39/.directory_pool/io/ioIfVfEcFA15555190997335153
drwxr-xr-x 2 root root 4096 Apr 17 23:59 windows_components_config

$ ls -l /repo/WIN-UUNOK8B4N39/190417-2359/windows_components/00000004_SqlServerWriter/00000000_master
total 8
lrwxrwxrwx 1 root root 126 Apr 17 20:20 files00000000 -> …/…/…/.symlink_SqlServerWriter_{A65FAA63-5EA8-4EBC-9DBD-A0C4DB26912A}ae2b4cde59afa2ab20f1a6b080698836_master_files00000000
lrwxrwxrwx 1 root root 126 Apr 17 20:20 files00000001 -> …/…/…/.symlink_SqlServerWriter
{A65FAA63-5EA8-4EBC-9DBD-A0C4DB26912A}_ae2b4cde59afa2ab20f1a6b080698836_master_files00000001

These two soft link files are invalid. Because the windows_components itself it is a soft link. “…/…/…/” can’t point to the parrent directory (190417-2359 in my case).
Actually it points to path “ioIfVfEcFA15555190997335153”. That’s why the restore is failed. The file is still there, but it lost contact with the urbackupsrv.



What’s more, even the soft links issue are fixed, the SQL files in path /repo/WIN-UUNOK8B4N39/190417-2359/.symlink_SqlServerWriter_… are not correct.

$ ls -l /repo/WIN-UUNOK8B4N39/190417-2359/.symlink_SqlServerWriter_{A65FAA63-5EA8-4EBC-9DBD-A0C4DB26912A}ae2b4cde59afa2ab20f1a6b080698836_master_files00000000/master.mdf
-rwxr-xr-x 1 root root 4194304 Apr 17 20:52 /repo/WIN-UUNOK8B4N39/190417-2359/.symlink_SqlServerWriter
{A65FAA63-5EA8-4EBC-9DBD-A0C4DB26912A}_ae2b4cde59afa2ab20f1a6b080698836_master_files00000000/master.mdf

The timestamp is 20:52. It’s an old previous backup. Actually the correct file for this backup is in “.hashes” 's path:

$ ls -l /repo/WIN-UUNOK8B4N39/190417-2359/.hashes/.symlink_SqlServerWriter_{A65FAA63-5EA8-4EBC-9DBD-A0C4DB26912A}ae2b4cde59afa2ab20f1a6b080698836_master_files00000000/master.mdf
-rwxr-xr-x 1 root root 432 Apr 17 23:59 /repo/WIN-UUNOK8B4N39/190417-2359/.hashes/.symlink_SqlServerWriter
{A65FAA63-5EA8-4EBC-9DBD-A0C4DB26912A}_ae2b4cde59afa2ab20f1a6b080698836_master_files00000000/master.mdf

The file in “.hashes” 's timestamp “23:59” is correct one!

OP is using a Windows server and it should use directory junctions instead of symlinks there, so you two probably have different issues.

OK. The issues may be different. I don’t have any idea about the window server since I nerver use it.

About the issue in linux server , is there a plan to fix it? How could I report this bug? Thanks!

Create a new thread. Add info descriped in Having problems with UrBackup? Please read before posting . In your case you can further narrow down the issue by disabling “Use symlinks during incremental file backups” in the advanced settings (would narrow it down to symlink use in file backups) and enabling “Debugging: End-to-end verification of all file backups” (this checks if the file data/changes have been transferred correctly).