Path for data.sdf keeps reverting to C: drive on cluster

jhboricua

I'm seeing a disturbing behavior in several of our 64-bit Server 2003 SQL clusters where the value of the key "DataPath" on:

HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\SQL Backup\BackupSettingsGlobal\(LOCAL)

keeps getting changed to:

C:\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Data\(LOCAL)

instead of the path in the cluster shared drive we specified during the install.

I've gone to the registry on all the nodes and changed the value back to the path on cluster shared drive but eventually it reverts back. It seems to be happening during our monthly windows patching weekend cycle when the nodes are rebooted.

Interestingly enough the value for the 'LogFolder' key on the same registry location stays on the cluster shared drive. It's only the 'DataPath' value that keeps reverting to the C: volume.

Any ideas on whats going on here?

SQL Backup release on all of our SQL clusters is 6.4.0.56 with patch 6.4.0.1028.

petey

It could be a timing issue, either with the active node not getting the SQL Backup replicated keys in time, or the shared drive not being available to the active node in time.

The 'DataPath' value is a critical value, in that SQL Backup uses it when it starts up. When no value exists, it creates a 'DataPath' value using the default location. If a value exists, but the directory is non-existent (or not accessible), it also creates a 'DataPath' value using the default location.

The 'LogFolder' key isn't as critical, as it's only used when a backup/restore process completes, and not when the service starts up.

We could try putting a 15 second delay during the startup process for clustered configurations, to test if it addresses the issue. Would you be willing to try that?

Thanks.

jhboricua

Yes, I would be willing to try that.

jhboricua

I noticed that the generic cluster resource created by the RedGate installer for the SQLBackupAgent doesnt have any dependencies listed. Wouldn't be easier to add the shared volume as a dependency to ensure that the volume is available before the service is started?

petey

You are right, that would be the easier thing to do if it is an issue with the availability of the shared volume.

richard

Ive also had this issue occur this afternoon when upgrading the SQLBackup on one of my x64 cluster instances to version 6.5.0.75

I can start the sqlbackup resource on the cluster, but doing any backups fails with the error unable to initialise data store etc..

I then copied the old data.sdf to the path requested (eg C:...) and this has rectified the backup problem. I have also tried changing the registry to for the data path to the correct path on the shared storage, but this keeps getting reset back to C:\....

clearly this is going to be a problem when I fail the instance over to another node which doesnt have the data.sdf local to C

ideas???

petey

... but this keeps getting reset back to C:\....

When does this happen? When you stop and restart the SQL Backup Agent service, or when you fail over the instance to the other node?

Thanks.

richard

this happens when I restart the SQLBackup service

havent been able to fail the instance over as this is a live prod box.

jhboricua

I added the cluster shared drive as a dependency of the SQLBackupAgent cluster resource on a test cluster instance and the registry key didn't revert to the C: drive after our last patch cycle reboot.

I'm not declaring victory yet though. I've since since made this change on all our production clustered SQL instances but won't know for sure this will fix the problem until our next patch cycle next week.

I will update this thread with the results.

jhboricua

Just wanted to post an update. Last weekend we had our production servers run through our windows patching maintenance window which requires them to reboot. I just checked the registry keys for the DataPath location on all of our SQL clusters and the path DID NOT revert to the C: volume. It still pointing to the proper location.

So it looks like adding the shared volume where the files reside as a dependency of the SQL Backup Agent cluster resource was the fix, since the SQL Backup Agent cluster resource won't go online until the shared volume does.

I will keep my eyes on this next month but I think this problem is resolved.