02-17-2009 07:51 AM - edited 03-18-2019 10:31 PM
We are currently running Cisco Unity 4.2 build 4.2(1) and DiRT 1.0 build 122. When i manually run the backup it works properly without errors. When the scheduled backup runs the task stays in a running state and returns the listed error in the event viewer. We are currently backing up to a network share using the two hop method.
Event Type: Error
Event Source: VBRuntime
Event Category: None
Event ID: 1
Date: 2/17/2009
Time: 10:38:20 AM
User: N/A
Computer: COG-UNITY1
Description:
The VB Application identified by the event source logged this Application UnityDisasterRecoveryBACKUP: Thread ID: 1368 ,Logged: Disaster Recovery Backup Error in form load routine: number= 0
Any help would be appreciated.
02-17-2009 08:15 AM
Adam,
I would make sure you have the latest DiRT backup version 1.1.9 - 2/6/2009. Have you tried deleting the scheduled task from within control panel and re-creating it through DiRT again? I understand manual backups are working to the network share, have you tried performing a sanity check by witnessing a successful scheduled backup maybe to a local drive to eliminate any problems with access to the network drive when not logged into the server?
Brad
02-17-2009 08:17 AM
I have tried to delete the task and re-create it without any success. I havent tried a scheduled backup to the local drive. I'll give that a shot to see what happens.
Thanks
02-17-2009 08:46 AM
I created a new scheduled DiRT task to backup to the local drive and it completed without errors.
It appears that the issue is with writing to the network drive. It doesnt make sense because when i run the DiRT application manually it works fine. I'm wondering what would be casuing the issue with the scheduled task.
02-17-2009 10:56 AM
I would check the account that is running the scheduled task and make sure it has permissions on that network drive.
Also, I just tried a scheduled backup using a mapped network drive while I was logged into the server as that account and it succeeded. I scheduled it for a minute later, logged out of the server and I didn't see the backup files appear in my destination mapped drive. So, I went back and saw that I had a VBScript error too, but mine said that it couldn't write to the destination path. Since the mapped drives aren't "mounted" when logged off, this is why the help file for DiRT advises against this and says to use UNC format (\\servername). I changed it to UNC format, and the scheduled backup succeeded. Now, your error looks a bit different, but it can't hurt to try UNC format and verify permissions on the drive and see how it behaves.
Brad
02-17-2009 11:43 AM
I have always been using the UNC format, because I don't have the network drive mapped. The account that I am using to run the backup is a domain account, that has read/write privileges to the network location.
One thing that I noticed is that when I used the DiRT tool as the local administrator, the path of the backup location ("backup target location" field) was saved when I reopened the program again. When I ran the DiRT tool while logged in as a domain user, it wasnt. I'm starting to thing that for some reason the destination isn't being saved when I schedule the automated task. Do you know where the designation is stored for the scheduled automated task?
Thanks
02-17-2009 02:35 PM
it's stored in the registry
HKLM\Software\Active Voice\DisasterRecovery\Settings
it's in the "BackupTargetPath" key. If you're using the two hop (which it sounds like you are) the local directory is in the "LocalBackupPAth" key.
Note that these values are only set in the registry after you do a manual backup - they are not set when you change them. This is why you need to run a backup before the scheduled backup will fly.
02-17-2009 02:57 PM
In addition to what Jeff said, see the following defect that is tied to Jeff's response:
Brad
03-10-2009 06:55 AM
I finally got the scheduled task toy run successfully by applying the permissions listed below. The really weird thing is that the DiRT backup would run successfully if performed manually under the old permissions but not as a scheduled task.
You will need to run the Disaster Recovery Backup tool logged in as an account that has administration rights to SQL and, if you've selected to backup messages, an account that has Exchange Service account rights. This is much trickier than it sounds and will not be the case for any account you may have used to install Unity since it would have been a member of the Domain Admins group which is explicitly denied this right in Exchange. Please see the Configuring Permissions for DiRT section for details on how to go about this. Once you've launched the application, you need only use the âBrowseâ button to indicate where you want the backup files written and hit the âbackupâ button. The progress is indicated by the checkboxes next to each task as it's undertaken.
Also, I believe you've mentioned you are using the Two-Hop Method. Please review below and let me know that you are providing local space with more then enough room for the backup.
Using The Two Hop Backup
The actual backup of the SQL data for the main Unity database and, optionally, the reports database is done using the SQL services themselves. As such the permissions to write files to the target directory are limited by the account the SQL services are running under. If your site is using the local system account for these services then writing the SQL backup data to an off box location will fail. Further, you are using a domain account for the SQL services but don't want to grant read/write permissions to the off box location then the SQL backup portion will fail as well.
This is a fairly common scenario so we provided a simple mechanism to work around it. First do the SQL backup to a local drive the move the backed up database files to the off box target using the account DiRT backup is running under and then delete the local copies of the backup files. This is called the âtwo hopâ method.
You can use this method by checking the âUse 'two hop' method for backing up SQL dataâ check box and then providing a local target to use. Be sure to use a local drive where you have room enough to do the backup. For large systems the SQL tables can be large so be sure to leave yourself plenty of room.
03-10-2009 08:28 AM
the running nightmare that is Exchange mailstore access rights for ExMerge is the primary reason why I moved away from that as a message backup mechanism for COBRAS - and of course now it's no longer supported in Exchange 2007 - It's certainly handy as it can get the entire mailbox regardless of message type but it is a bear to make work correctly...
I'm not real sure why it would work logged into the desktop but not from the windows scheduler using the same account - I have no theory for that.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide