This document describes the common things to check to ensure that your installation/upgrade of the SQL Backup server components has been performed correctly.
SQL Backup server components
The SQL Backup server components consists of the SQL Backup service application and the SQL Backup extended stored procedure library.
SQL Backup service application
The service application file is named SQBCoreService.exe, and the default installation folder is a subfolder beneath the root SQL Backup installation folder. The name of the subfolder is the associated SQL Server instances' name. For the default instance, the subfolder is named (LOCAL).
Each instance of SQL Server that runs SQL Backup requires its own service. Note that a single license of SQL Backup allows you to install SQL Backup on all instances on the same physical machine.
SQBCoreService.exe uses the zlib compression algorithm contained in the file named zlib1.dll. This file needs to be present in the same folder where SQBCoreService.dll is located.
During the server components installation, the installer would have installed the related SQL Backup Agent service with the Windows Service Manager. Open the Windows Service Manager and verify this.
If the service is installed for a named instance, ensure that the service is started up with the -I parameter together with the instance name.
For a cluster, the -I parameter is not required for the default instance e.g.
A named cluster instance requires the -I parameter e.g.
If the -I parameter is missing for a named instance, you will need to add it manually. To do this, first stop the service. Then open the registry, locate the services' entry in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services, and add the -I parameter to the ImagePath value, together with the instance name. Then start the service.
If the SQL Backup Agent service fails to start, first check the Event Viewer application log. Common errors are logged there.
If no errors are logged, the failure to start could then be due to many reasons. In these situations, we will require a trace file in order to identify the exact cause of the error. You will need to start the SQL Backup Agent service with a trace flag in order to generate a trace file. You can do this by adding the -sqbdebug parameter to the services' ImagePath registry value.
The service should now generate a trace file named SQBCoreService_log.txt in the folder where the service application is installed. You should send us this file when contacting us regarding service startup failures. You should remove this flag if you are not generating a trace file, as the file can get very large.
SQL Backup extended stored procedure library
The SQL Backup extended stored procedure library is named xp_sqlbackup.dll, and is installed in the associated SQL Servers instances' Binn folder.
SQL Backup registers the following extended stored procedures, which are contained in this library:
A common issue during upgrading is that the xp_sqlbackup.dll file has not been upgraded. This is more common with SQL Server 2000 instances'. In these cases, SQL Server could not free the library from its memory space, and the installer then cannot replace the file. In these cases, you should confirm that this is the case by first trying to free the library manually using the following command:
and copying the xp_sqlbackup.dll file from the SQL Backup installation folder to the SQL Server instances' Binn folder. During installation, the installer places a copy of xp_sqlbackup.dll in a subfolder beneath the services' folder. The name of the subfolder depends on the processor architecture that the SQL Server instance is running on, as follows:
If you are unable to replace the old copy of xp_sqlbackup.dll, this means that you would need to stop the SQL Server instances' service, replace the file, and restart the SQL Server service. If this is not a feasible option the workaround is to redirect the extended stored procedures to another file, until such time that you can replace xp_sqlbackup.dll.
To perform the redirection, first make a copy of the new xp_sqlbackup.dll, rename it (e.g. xp_sqlbackup_new.dll) and place it in the SQL Server instances' Binn folder. Then unregister the extended stored procedures from the existing file e.g.
and register the extended stored procedures using the newly renamed file e.g.
The SQL Backup extended stored procedures will now use the functions located in the renamed DLL. If you do use this workaround, do remember to replace the older xp_sqlbackup.dll when you next bounce the SQL Server instance.
Checking the file versions
The easiest way to check the file versions is to view the properties of the files themselves, SQBCoreService.exe and xp_sqlbackup.dll.
You can also check the file versions remotely. When you run the SQL Backup extended stored procedure 'sqlbackup', the result set column header provides the version number of the xp_sqlbackup.dll file that is in use:
To check the version of the SQL Backup Agent service that is active, run the following command:
If you are running multiple instances of SQL Server, note that you must log in to each instance, and check each instances' SQL Backup server components file versions separately.
SQL Backup uses the SQL Server Virtual Device Interface (VDI) to communicate with SQL Server. You may also need to ensure that the VDI library file (sqlvdi.dll) has been correctly installed on your server. See this document for further details.
Discuss or comment on this article on our Facebook group.