Unity DiRT backup SQL error message for VM-only with Failover

Unanswered Question

I have to Unity 7.0(4) servers running VM-only with Failover. If I run DiRT on the "secondary" server, where the mail store resides, I get an SQL error in the log:

(error) in cmbBackup routine:[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open backup device 'Z:\UnityDBBackUp.sql'. Device error or device off-line. See the SQL Server error log for more details.
[Microsoft][ODBC SQL Server Driver][SQL Server]BACKUP DATABASE is terminating abnormally. number= 0

If I run it on the Primary, I receieve the same message. If I run COBRA, it completed successfully but the COBRA log eludes to the same error. Currently, my primary is active, and is where the Subscribers are modifyable.  I've never done backups with VM-only with FO, so is there something unique to the DiRT procedure that I need to be aware of?

The rest of the backup seems to be okay. I just want to make sure:

(Please see attached log).


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
David Hailey Tue, 04/20/2010 - 13:40

Your error indicates that the shared drive that you are "mapped" to cannot be opened by the user running DiRT.  You should configure DiRT for the two-hop method (if you haven't done so already) and use a full UNC path to the server.  Read up on DiRT here and it tells you all you need:



Please rate helpful posts!

lindborg Tue, 04/20/2010 - 13:41

can you explain what you mean by "COBRAS eludes to the same error"?

COBRAS and DiRT go about their business in very different ways - COBRAS does not ever connect directly to SQL via SQLDMO (as diRT does when that error is thrown).  If you can post the log errors from COBRAS you refer to this may help explain what's going on.

Also, I suspect this has to do with the share you're using (the "Z" drive) - if you do a diRT backup to a local drive on the server as a test, do you get the same error?

lindborg Tue, 04/20/2010 - 13:59

...and since it trips so many folks up, just need to point out that it's not the account you're running DiRT as that is having rights problems on the mapped drive - it's the SQL service (or more to the point the account associated with that service assuming there is on).  DiRT asks SQL to backup tables using the SQLDMO library - it's SQL that runs off and does the backup to the target - if it throws an error like that then the SQL service doesn't have full write/create rights to that location - this is why the two hop method was added - so it can do it's backup locally and then DiRT copies the files in a follow-on step (which does use the rights of the account you're running DiRT with).


David Hailey Tue, 04/20/2010 - 14:08

Jeff - this is why you are the guru. Believe it or not, I knew that

just not to the level of detail. I think you point this out in DiRT

help files.

Sent from my iPhone

On Apr 20, 2010, at 4:59 PM, lindborg

lindborg Tue, 04/20/2010 - 14:31

yeah - the error message is just being passed along from SQLDMO - it's still using the old-school terminology like the destination would be an external "device" like a tape drive or the like - not necessarily obvious it's just talking about the destination in general.  I could check for that error and add a follow on blurb to the log file noting that "this usually means it doesn't have full write/create access to the destination" or the like...


This Discussion