What are the challenges you face when working across database platforms? Take the survey

Activity Window on a sql cluster

shirazshiraz Posts: 9
edited August 8, 2007 7:01AM in SQL Backup Previous Versions
I've got SQL BACKUP installed and working on a w2k3 active passive cluster. SQL backup runs fine, however when I switch nodes the Activity window in the SQL Backup GUI does not display any backups done while on the other node. Is this normal or is there some other setting I have missed?



  • Options

    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,
  • Options
    mfailemfaile Posts: 18 Bronze 2
    For the 2 keys referenced, I have the first as a 1. However the second DataPath is a local non-shared drive. I selected the cluster install, obvious if #1 was a 1.

    Obviously the cluster install did not work for me and I have now installed it on 3 clusters and all 3 of them have the same issue. It has seen both cluster nodes each time. All 3 clusters have a 1 in the IsCluster key but all 3 have local DataPaths.

    This explains why none of my settings xfer across nodes.
    Is there another way to fix the DataPath issue w/o a remove & reinstall?
  • Options
    mfailemfaile Posts: 18 Bronze 2
    After tinkering with it a while I finally have it working.

    The trick was to edit the registry on the virtual server and then it propagates back to the registry on the nodes once they become active at least once.

    Now....having said that the jobs do now xfer to nodes. Some things do not xfer though, for instance the group name. What items are stored in the sdf file that will xfer across nodes?
  • Options
    I managed to fix my install by uninstalling redgate on all nodes first including manually deleting the registry settings (these do not get deleted on uninstall, then reinstalling on to one of the shared drives.
    However the globalpath registry setting was still pointing to the local disk so manually changed this to point to the shared drive.
    repeated the same thing on all nodes.
  • Options
    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.

Sign In or Register to comment.