User profile for Jason Cook

To get an idea of how long the task will take to execute, you can perform the following calculation: * Get the current size of the "msdb" database's MDF file. * Navigate to "C:\Documents and Settings\<username>\Local Settings\Application Data\Red Gate\SQL Backup\Server Data" (where <username> is your account name), and get the current size of the last database to be modified (which should be your SQL Server 2000 server). You can work out the proportion done so far by dividing the second size by the first (since the final datastore size should be in the same ballpark as the msdb size), and then use that to work out how long it might take. I'm afraid that's the best approximation that we can offer at this time without getting into the depths of probing the various tables used by SQL Server and SQL Backup (which would add additional load to the server). If you have hundreds of thousands of rows in your msdb backup and restore tables, a couple of hours processing time would not be uncommon, given the sheer quantity of data that SQL Backup is having to handle. Fortunately this is a one-time cost for a given user, so you shouldn't have the same delay in the future. I've also passed on a request to our development team for them to add progress indications when the GUI is pulling the activity history from the datastore or from SQL Server, so hopefully that will be included in a future release to make life easier. Hope that helps, Jason / comments

To get an idea of how long the task will take to execute, you can perform the following calculation: * Get the current size of the "msdb" database's MDF file. * Navigate to "C:\Documents and Settin...

0 votes

The "data.sdf" file that is shared contains additional information on backups and restores that have been performed. This information is in addition to that stored by SQL Server, and includes error and warning messages generated by SQL Backup, as well as various statistics about the backup/restore - including compression and encryption. The jobs themselves should be controlled by SQL Server, rather than SQL Backup. The clustered SQL Backup installation will transfer across saved templates and backup settings (such as mail server details, retention information etc) to each of the cluster nodes. I'm not entirely sure what you are referring to by "group name", if you can give me some more information on that, I can answer or resolve why it isn't transferring. Thanks, Jason / comments

The "data.sdf" file that is shared contains additional information on backups and restores that have been performed. This information is in addition to that stored by SQL Server, and includes error...

0 votes

Hi, The scenario you have mentioned should indeed cluster the activity history to a shared drive, such that regardless of which node the backup is performed on, it should still appear in the SQL Backup 5 GUI. SQL Backup will quite happily function on individual cluster nodes in a non-cluster aware fashion, but to get the behaviour you are expecting, you need to ensure that it has been installed as cluster-aware (using the "Install SQL Backup on all cluster nodes" option of the installer). To check how SQL Backup has been installed (where <instancename> is the name of the clustered instance), on each of the nodes: - In the registry, locate the node HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\SQL Backup\InstalledInstances\<instancename>, and find a key called "IsCluster". If this exists (and is set to 1) then the installation has been installed as a cluster. - If the above identifies the cluster, locate another node in the registry, called HKEY_LOCAL_MACHINE\Software\Red Gate\SQL Backup\BackupSettingsGlobal\<instancename>, and find a key called "DataPath". If this exists, the location specified should be on a shared cluster location rather than a local drive such as C:\. If it is installed to a local drive, it implies the components were not installed as cluster-aware. If the above indicates that the server components have *not* been installed as cluster-aware, the easiest way to fix this is as follows: * Uninstall the server components on each node, if asked to remove the datastore, select "no" (so that the history can be retained, even though it may not appear in the clustered datastore). * Re-install the server components on the active node of the cluster, selecting the "Install SQL Backup on all cluster nodes" option. * Repeat the two registry steps above to check what the new values are on each node, if these are now correct, your backup and restore history should be clustered and updated regardless of which node is used to perform the backup. Hope that helps, Jason / comments

Hi, The scenario you have mentioned should indeed cluster the activity history to a shared drive, such that regardless of which node the backup is performed on, it should still appear in the SQL Ba...

0 votes

Hi David, If you look in your SQL Backup logs directory (which by default will be the following location, assuming c: is your windows drive), you should find a number of activity logs that correspond to the attempted backups and restores of SQL Backup: c:\documents and settings\all users\application data\red gate\sql backup\log\<instance_name> If you could find the one that corresponds to the job/backup in question (they are all timestamped) and either post it here or if you'd prefer email it to jason.cook@red-gate.com, I should be able to identify the problem from that. Thanks, Jason / comments

Hi David, If you look in your SQL Backup logs directory (which by default will be the following location, assuming c: is your windows drive), you should find a number of activity logs that correspo...

0 votes

The error message was generated by your mail server, rather than by SQL Backup. If you have not entered a username and password for mail server authentication, you should enter one that has permissions to send email. Alternatively if you did enter a username and password, you should check with the mail server administrator that the account is allowed to send emails. Once you have supplied an account that has sufficient permissions for sending the emails, that message should no longer occur. Hope that helps, Jason / comments

The error message was generated by your mail server, rather than by SQL Backup. If you have not entered a username and password for mail server authentication, you should enter one that has permiss...

0 votes

Hi ch13jvl, Unfortunately, at the present time there is no way to convert from native .MTF files into SQL Backup's .SQB files. The only suggestion I can make is to utilise a program such a Winzip ( http://www.winzip.com/index.htm ) or 7-Zip ( http://www.7-zip.org/ ), which can compress and encrypt your existing MTF files, but compression and encryption performance may not be as good as with SQL Backup, and it would require additional steps (i.e. uncompressing the archive) when restoring. I'll add your request to the feature suggestion list for the next version of SQL Backup, and it may be included in a future release of the product. Hope that helps, Jason / comments

Hi ch13jvl, Unfortunately, at the present time there is no way to convert from native .MTF files into SQL Backup's .SQB files. The only suggestion I can make is to utilise a program such a Winzip (...

0 votes

Hi alecl, Thanks for the suggestion, I'll pass it on to our developers and hopefully we will be able to include it in a subsequent release of SQL Backup. Thanks, Jason / comments

Hi alecl, Thanks for the suggestion, I'll pass it on to our developers and hopefully we will be able to include it in a subsequent release of SQL Backup. Thanks, Jason

0 votes

Hi Andrew, The list of templates available is generated when you select a server from the list, so initially the template list will be empty and contain the text "You have no saved templates.". If you are selecting the correct server and it still returns an empty list, you can check the list of templates in the registry (on the machine that hosts the SQL Server instance), at the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\SQL Backup\Backup Settings\<name> Where <name> is the name of the instance. You should see some name/data pairs, each one corresponding to a saved template. Hope that helps, Jason / comments

Hi Andrew, The list of templates available is generated when you select a server from the list, so initially the template list will be empty and contain the text "You have no saved templates.". If ...

0 votes

[update]This will also be included in the forthcoming 5.2 release, so the solutions below should only be used if using versions 5.0 or 5.1[/update] As a follow-up to this issue, the reason for the problem is that the value of "SQLDataRoot" (in the SQL Server portion of the registry) contains an additional backslash at the end than it should do. This is causing confusion for the GUI which expects this value to be of the format defined by SQL Server. We hope to have this fixed in a future version of SQL Backup, but at the moment there are two options: 1) The "fix" is to change the registry key SQLDataRoot, which will be: For SQL 2000 on a 32-bit server, under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Setup For SQL 2000 on a 64-bit server, under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Setup For SQL 2005 on a 32-bit server (or 64-bit SQL 2005 on a 64-bit server), under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.#\Setup (where # is the instance number) For 32-bit SQL 2005 on a 64-bit server, under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\MSSQL.#\Setup (where # is the instance number) Removing the final backslash from the location will resolve the problem, for example: c:\program files\microsoft sql server\mssql.1\mssql\ would become: c:\program files\microsoft sql server\mssql.1\mssql 2) Alternatively, the workaround is as follows: * Click the "..." button to the right of the "File Groups" label (the top one in the filegroups and files list). * The "Folder" browser comes up, click OK. Now proceed to use the wizard in the regular way. If the message appears when switching to "Create new database", repeat the above steps. This causes the data directory to be "corrected" internally (even though visibly the directory location is correct) , and will then function correctly in the restore wizard. If you need further assistance with this issue, you can contact the Technical Support team at support@red-gate.com Thanks, Jason / comments

[update]This will also be included in the forthcoming 5.2 release, so the solutions below should only be used if using versions 5.0 or 5.1[/update] As a follow-up to this issue, the reason for the ...

0 votes

Hi ryan, The "database disk image" it refers to is the internal data store used by the graphical user interface. To remove this and start with a clean data store, perform the following steps: * Make sure the SQL Backup GUI is shut down. * Navigate to the directory : C:\Documents and Settings\<user name>\Local Settings\Application Data\Red Gate\SQL Backup\Server Data - where <user name> is the name of the user that is experiencing the problems. * Remove all the files in the directory (which should be .dat) - if you want to keep hold of them you can move them to another directory (as long as that directory is empty). * Start the SQL Backup GUI again, it should now recreate the data store, and pull in data from the servers again... this may take a few minutes to complete if you have a lot of activity history. Hope that helps, Jason / comments

Hi ryan, The "database disk image" it refers to is the internal data store used by the graphical user interface. To remove this and start with a clean data store, perform the following steps: * Mak...

0 votes

How can we help you today?

Jason Cook

Comments