04-20-2010 01:34 PM - edited 03-19-2019 12:49 AM
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).
THANKS!
04-20-2010 01:40 PM
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:
http://www.ciscounitytools.com/Applications/Unity/DIRT/DIRT.html
Hailey
Please rate helpful posts!
04-20-2010 01:41 PM
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?
04-20-2010 01:59 PM
...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).
-J
04-20-2010 02:08 PM
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
04-20-2010 02:19 PM
AWESOME! THANKS GUYS!!!!! The 'ol two-hop did the trick! The error message certainly wasn't helpful, so I definitely couldn't have done it without you two! Thanks!!!!!!!
Mike.
04-20-2010 02:31 PM
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...
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: