I am getting an error after attempting backups using DIRT. I am just wondering if these errors are indeed relevant. It is giving an error of "can't open backup device".
The domain account that unity was configured as has full access to the local administrators group. I don't see any issues with permissions.
Running UnityDisasterRecoveryBACKUP version: 1.0.95
Local Unity version=4.0(2.0)
Search for '(error)' or '(warning)' to find logged errors and warnings during the backup process.
Starting disaster reocovery backup at: 10/27/2003 10:15:00 PM
Backing up in silent mode
Backing up registry to: \\Mtkfs01\Shared\TelephonyBackups\Unity\UnityReg.REG
Backing up the Cisco TSP branch to:\\Mtkfs01\Shared\TelephonyBackups\Unity\CiscoTSP.reg
Backing up active switch file 1 :C:\CommServer\IntLib\cisco0002.ini
Backing up all AVD files
Backing up StreamFiles folder
Copying out system greetings for default objects
Backing up UnityDB SQL table
(error) in cmbBackup routine:[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open backup device '\\Mtkfs01\Shared\TelephonyBackups\Unity\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
User elected to skip backup of reportDB
Finished disaster reocovery backup at: 10/27/2003 10:15:24 PM
Yes, those errors are very relevant. That's SQL coming back and saying it doesn't like the path you've provided for backup - that's the most important part of the backup so you'll need to figure out what it doesn't like about that. DiRT itself is simply passing the path to SQL and waiting for it to return - there's nothing I can do on my end of the fence to force it to be happy with it.
Common issues hwere are using a shared drive instead of a full UNC (SQL sometimes doesn't like that) or the account you're running as (or the SQL services is running as) don't have full read/write/update rights to the target you provided. I've also seen folks trying to park this on a location outside the domain (that's a no-no for SQL).
I always suggest trying the backup to a local drive to ensure yourself that everything is working as it should be and then moving on to investigate why the remote location is causing you problems.
Also, be sure to fetch the latest versions of DiRT backup and restore (the most recent version of backup is 1.0.97 - you're running 95 here). Always a good idea to be on the latest.
Thanks for the info by rote. I snooped into this one and found my answer. But it does raise a question...why does it work like this?
It was really kinda strange. The backup tool gave me these errors, which should have meant that there was no access to that UNC path. There was access, however, since the tool was able to write files of many different types to that UNC directory up to the point that the tool tries to write the SQL server files. So, I followed it through to see if I could figure out what was causing it to fail. I checked the access permissions on the share. I had originally planned on only letting the Unity Admin and Domain Administrators have access to this directory (kinda redundant, but I'm that kinda guy). I had changed the rights for "Everyone" from "Full Access" (the default setting for a terribly secure windows share) to "Read" only I was going to take the rights completely away once I tested it, but alas could not. When I ran the backup with those rights, it failed. In order to get it working, I had to give "Everyone" Full Access rights to that share.
I'm sure I don't have to explain why I think this is not exactly the best way to do this, but what I'm wondering is, when it gets to the two SQL tasks, what account is it actually using to make that connection? Is it using the SQL service account, or the UnityAdmin (or whomever else might be used at that time)? If it is using the SQL service account, is that completely necessary for the backup/restore? Is there a way to change the tool to either a) use the specified user (i.e. unity admin) to log in during the SQL backup portion, or maybe b) stage the backup local, then copy it to the UNC path point?
I'd like to see it to where I can use a share that is only accessible to the domain admins/unityadmin for backups. Just my $.02.
What do you think?
DiRT simply calls the SQLDMO library and asks it to backup the specified table(s) (UnityDB and Optionally ReportDB) to the location proviced - it's the SQL service itself doing the work so I don't have any control over this (i.e. I'm not tearing open SQL externally and doing the backup as part of the DiRT process). If you want to quickly snag the entire DB (or DBs) in SQL this is really the only way to go.
So, the only real alternative here if I wanted to exclude the "Everyone" group from access to that share point would be to change the SQL server service login account to Unityadmin (instead of the localservice account) or something like that?
I guess if that's not a recommeded way to handle it, the only other alternative would be to back it up locally and share it out to a server that runs tape backups...
Running the SQL services under a domain account should be fine (my test boxes are configured like this). Doing the local backup works OK, too, of course...
OK. When I change from the local service account to a domain account, will that require a reboot or at the very least a stop...change...restart of SQL services?
well, you can't stop/start SQL without bringing Unity down with it - I've never tried it just bouncing the services themselves, a reboot should probably be assumed here.
right, then. I'll do that at the next time I can work in a maintenance window. I'll stop unity, ensure the services are stopped, change the account to a domain account, then reboot.
thanks again for your help. in case you couldn't tell, this was my first unity install, so i have had a few questions.
follow up to this - check out this related thread for a note about a possible change I can make to DiRT backup - looking for opinions on the viability of such an approach:
and a follow up to that follow up - a new version of DiRT that supports a "two hop" SQL backup method that will allow you to leave your SQL services as "local" has been tested and is posted for download here:
Thanks, yeah, I saw that you had posted a new ver of DiRT, and I thought that might have been what you did. Thanks for that. I appreciate it.
hey, ran the new two-step backup with the everyone object restricted from that particular directory and it worked like a champ...Nice job.
One thing, I looked at the latest RESTORE util and didn't see a check to do a two step restore, are you going to put that functionality into the RESTORE tool as well, or not. It's no problem if you aren't, but I was just wondering...and I figured maybe you might need something else to pass your time.
No, I wasn't going to add the two hop stuff to the restore - it's more important for the backup end of the house since it can be a scheduled regular activity. When the restore is being done the system is off line and presumably copying everything local if necessary isn't nearly as big a burden as for regular backups. Besides, the restore application is considerably larger and more complex than the backup (about 8 times as much code give or take) - I don't want to add new stuff in there unless it's really necessary.
gotcha. i can dig it, and it's not a problem. there will likely be much more work on restoring it to that point anyway, so one step vs two step is really a moot point. Thanks again for all your help in this. I'm glad that you added that option, it helps my security nerd personality get along with my project manager personality. In a way, you are doing me a very nice public service and even maybe a little phsychological healing. God bless...