Comments
Sort by recent activity
Thanks for you reply, and the link to the patch.
I understand your recommendation to upgrade, and If/when we upgrade to to SQL2012 there will be an obvious and clear need to upgrade our Red Gate tools (which will satisfy the people that pay the bills and sign off these things).
For now, for testing, the patch does the job.
Thanks again. / comments
Thanks for you reply, and the link to the patch.
I understand your recommendation to upgrade, and If/when we upgrade to to SQL2012 there will be an obvious and clear need to upgrade our Red Gate to...
We deployed the patch on Tuesday and our log shipping backup/restore processes have been running ok.
Last night there was a failure in the restore job, but this was handled and subsequent restore jobs have completed successfully. The same SQLVDI error messages are recorded in the windows event logs, so it seems likely this is the same error that was causing the jobs to hang previously.
Deploying the patch therefore seems to have resolved the issue with the jobs hanging.
For reference, the errors recorded in the SQL backup log file are: 10/05/2012 03:05:08: Thread 0 error:
Process terminated unexpectedly. Error code: -2139684861 (The api was waiting and the timeout interval had elapsed.)
10/05/2012 03:05:08:
10/05/2012 03:05:08: SQL error 3013: SQL error 3013: RESTORE LOG is terminating abnormally.
10/05/2012 03:05:08: SQL error 3201: SQL error 3201: Cannot open backup device 'SQLBACKUP_2022D7BB-9FE4-4987-AF55-9B1A8AFA6512'. Operating system error 0x80770006(failed to retrieve text for this error. Reason: 15100).
Should the errors persist I will raise a new forum topic.
Thanks for your help. / comments
We deployed the patch on Tuesday and our log shipping backup/restore processes have been running ok.
Last night there was a failure in the restore job, but this was handled and subsequent restore j...
Hi Chris,
Thanks for the response. I'll deploy the patch and let you know. / comments
Hi Chris,
Thanks for the response. I'll deploy the patch and let you know.
Eddie,
Thanks for your reply, and the clarification. / comments
Eddie,
Thanks for your reply, and the clarification.
It's now working!
Simply restarting the SQL Backup Agent service seems to have done the trick.
One of the factors behind the move from the current network share to the new DFS namespace is the new DR solution we are implementing. Part of this solution includes log shipping, which we are using SQL Backup for.
Before approaching the network guys about granting 'EVERYONE' permissions on the new share, I tried the same tests we did before (backup msdb to the DFS namespace/EXEC sqbutility) on the DR server and they worked. The SQL Backup service on the DR server is running under the same domain account as the server we've had the issues with, so this again confirmed it was not a permissions issue. As a final test I thought it may be worth restarting the SQL Backup service, and hey presto everything is working now :-)
Thanks for your assistance Pete. Greatly appreciated. / comments
It's now working!
Simply restarting the SQL Backup Agent service seems to have done the trick.
One of the factors behind the move from the current network share to the new DFS namespace is the new ...
It returns the following: <SQBUTILITYRESULT>:0:Folder does not exist : <network share>
Thanks for your help. / comments
It returns the following:<SQBUTILITYRESULT>:0:Folder does not exist : <network share>
Thanks for your help.
Hi pete.
That backs up successfully.
To confirm, the test install was running under the local system account and attempting to backup to the new location failed. Changed the SQL Server service to run under the same domain account that the SQL Backup Agent Service runs under, and the backup succeeds.
Thanks for your help. / comments
Hi pete.
That backs up successfully.
To confirm, the test install was running under the local system account and attempting to backup to the new location failed. Changed the SQL Server service to ...
Hi James,
Thanks for your reply and for the clarification.
In this instance the target machine is an offsite warm standby for DR purposes, and we need the log backups available on our network for other purposes such as refreshing dev and test environments.
We could configure the processed folder to be the network share, so that we copy from the source to the target and then from the target to the network share, but that would create two way traffic between us and our DR site which we would prefer not to do.
As a workaround I have created a simple SQL job on the target machine which copies the backup files across from the network share, with the SQL Backup restore then being done locally.
Thanks again. / comments
Hi James,
Thanks for your reply and for the clarification.
In this instance the target machine is an offsite warm standby for DR purposes, and we need the log backups available on our network for o...
Thanks, I'll give that a go. / comments
Thanks, I'll give that a go.