Hi Stephen,
We've had one or two reports of this in the latest version and I'm not sure the underlying cause has been identified so far. In short, it seems like the local data store is encountering trouble after the cache compress.
You may find it springs into life after some time - how long have you left it?
If it's still not working after being left alone for ages, the quickest way to get things working again is to let it create a fresh file. It'll import history from SQL Server, but you'll lose the more detailed history specific to SQL Backup (such as compression rates etc.)
To do this, stop the SQL Backup service, and then locate the data.sdf file. On a cluster, this is usually installed to a shared folder between the nodes somewhere, and on a single server would be in c:\programdata\red gate\sql backup\data\<instance name>. Rename / move the file elsewhere, and then start the service again. A new file should get created, and things should come back to life.
We've had one or two reports of this in the latest version and I'm not sure the underlying cause has been identified so far. In short, it seems like the local data store is encountering trouble after the cache compress.
You may find it springs into life after some time - how long have you left it?
If it's still not working after being left alone for ages, the quickest way to get things working again is to let it create a fresh file. It'll import history from SQL Server, but you'll lose the more detailed history specific to SQL Backup (such as compression rates etc.)
To do this, stop the SQL Backup service, and then locate the data.sdf file. On a cluster, this is usually installed to a shared folder between the nodes somewhere, and on a single server would be in c:\programdata\red gate\sql backup\data\<instance name>. Rename / move the file elsewhere, and then start the service again. A new file should get created, and things should come back to life.