11d and Lotus Domino

[Andreas_N_sbe1]

Eventlog:
Event Type:Error
Event Source:Backup Exec
Event Category:None
Event ID:65215
Date:28.11.2006
Time:23:26:59
User:N/A
Computer:IVORY
Description:
The connection to the Lotus Domino server has been lost. The following error was reported: 8,26. The job that was running on this server has been stopped.

Job History
Backup- IVORY|D: V-79-57344-65072 - The database server is not responding. Backup set canceled

V-79-57344-65072 - The database server is not responding. Backup set canceled.
WARNING: "IVORY|D:\Lotus\Dominodata\mail\mmagdzio.nsf" is a corrupt file.
This file cannot verify.

But why it can backup 1074 domino files?
Set Information - IVORY|D:

Backup completed on 28.11.2006 at 23:33:58.

Backup Set Summary
Backed up 1074 files in 15 directories.
1 corrupt file was backed up
Processed 45'491'408'638 bytes in 19 minutes and 0 seconds.
Throughput rate: 2283 MB/min

[Mike_Roden]

Russ,

Here's my latest experiment: I made a copy of the job that backs up the 10 GB Domino server in the above post. I edited the selection list on the copy and only selected a few folders under the Notes Databases selection (turned out to be 2.8 GB). Without doing anything on the remote server, I was able to get five successful backups in a row. The backups all started immediately and I don't even see it do a backup scan before it starts counting bytes.

I don't know what that tells you, but it sure looks like a database size or timeout issue.

Follow-up: I edited the copied job and changed my selection list back to doing a full backup of the Notes data folder using the Notes Databases selection. The job ran successfully one time. I started the job again for a second time and it's now been stuck on Backup Scan for 15 minutes.

Thanks,
Mike

[gth]

Hi Guys,

Surprise surprise we have this issue with Lotus Domino 7 + BackupExec 11d.

We have a case open with Symantec at the moment, but as happened with other people they have closed it over Christmas and we haven't heard a thing.

I do have some good news for those of you who are stuggling however - a definate fix is to install the Version 10d Agent on the Domino servers that experience this Error 8,26 issue. Yes this isn't "recommended", but after going through the issue with Symantec Support we tried using the v10d Agent and we haven't experienced an error at all (other than a warning in the Job Log that it is using a previous version of the agent).

We have 2 Domino Servers (in a cluster) which both experienced the issue - after putting the v10d Agent on one of them the issue seems to have gone away. So we are currently running a v11d Agent and a v10d Agent.

I believe it has something to do with the "smart" backup feature that Symantec introduced in v11d whereby if you have Domino databases on the server, BackupExec will only back them up via the Agent and won't back them up via standard Windows File backups as well - it seems to me like this doesn't work properly. In v10d, it doesn't have these "smarts" and so it will back up via the Domino Agent and the standard Windows File method (if your selection lists reflect this).

I'm sure Symantec will eventually come out with a fix for this - but I have to say I'm pretty dissapointed with the Support and acknowledgement of this issue, clearly several customers have the problem and surely Symantec could at least release a KB article saying "we understand this is an issue, and using the v10d Agent will resolve it temporarily until we can provide a hotfix".

And if anyone from Symantec is reading the forums - is the 2-3 hour phone support waiting time 'normal' for Symantec? Not very impressed with that especially after Symantec make you pay for Technical Support - I guess it is good that the BackupExec products are fairly stable and we haven't had to ring Support before!!!!

Here's hoping we get a fix soon for the issue :)

Message was edited by:
IT Servicesnull

[Tim_Longbotham]

I am inclined to agree with Mike that size could be important. Our mail servers contain the largest databases and these are the ones that fail without question.

After getting a job to run on the mail servers it is not uncommon to see the job ultimately fail with a timeout problem however I notice that any databases that is over 2.2 gig on the mail server, registers as 18,014,398,507,xxx,xxxKB in size on the backup server when I look under restore. In addition to this it is usually one of these databases that fails the job.

[Ken_Putnam]

In v10d, it doesn't have these "smarts"

Actually, Active File Exclusion was introduced with v9.0 (see http://support.veritas.com/docs/259152 )


Looks like one more thing that got broke in v11d

[AL]

We're experiencing this exact same thing as Tim a couple of posts above here, any databases over 2gig are listed as being 18,014,398,50x,xxx,xxxkb and regularly are causing backup failures.

We went from 9 straight to 11d, so I don't have the 10d agent to try out, can any nice person provide a link to somewhere I could download a copy from?

Message Edited by AL on 04-11-200712:15 PM

[Tangui]

Hello,

I do have the exact same issues (i'm talking about the hang of the domino agent... working on the first(s) backup after a relaunch of the agent service... but failing then...)

i'm running BE 11d (6534) on Windows 2003 and 6.5.4 Domino servers...

The symantec tech support only told me about restarting the agents when they failed, and to split my backup jobs to let my non-domino servers to be backed up....

I'm quite sad to see what's BackupExec is becoming... it used to works fine with Domino...

[David_Woodcock]

rename bedsnote.dll --> oldbedsnote.dll

It lives on the domino server:  C:\program files\symantec\backup exec\raws

This will disable the lotus notes agent, yet will still back up the notes files, AND won't hang AND won't complain.

I worked this out long ago, and support agreed.

Not sure why Symantec haven't fixed this yet.

[Shurbaji]

After more than two weeks of work on this issue with symantec technical support , it was solved successfully by devided one job to 2 jobs, I was backup SQL and Domino using one job now I am using one job for each task and till now it works perfect.

I hope that help you

[SteveVRTS]

Good news for you folks with Lotus Domino issues!  A patch was released today with a fix for most issues with the Lotus Domino agent.

Link to download the 32 bit version of the hotfix: http://support.veritas.com/docs/288328

Link to download the 64 bit version of the hotfix: http://support.veritas.com/docs/288329

[rhbmcse]

...which is very useful IF you're running build 7170 of 11d.

What about if you're running build 6235 like me and some of the other guys on this thread?

Come on Symantec - I have had no succesful backups of my hub mail server since we switched to version 11D.

Any suggestions - is there a patch for build 6235, or how do I get my build 6235 up to 7170 so I can use this patch.

Seems like i am patching my patches...

FYI...the update for the above can be found on the 1st page of the forum if you are running build 6235 you will need to do a 557MB download.  Hope your bandwidth is good guys!

Message Edited by rhbmcse on 05-15-200703:36 AM

[JCasares]

I'm having this same issue even though I have the last updates installed.
Do we need the registry setting besides the updated code as well?

[Attila_Nagy]

same here, BE11d b7170 (sp1) + lotus agent version - BEDSNOTE.DLL --> 11.0.7170.4

even if I set the 'enable change journal' key to 0 in the registry the UCJ files are created when backup starts and on the 2nd run it will fail with error
"Final error: 0xe00084bf - A restore Job is already in progress. Rerun your job, after the current job has finished.
Final error category: Job Errors" if the first run failed somehow (even if I only cancel the 1st backup).

also I have the 'different corrupt nsf file every day' problem, the incredibly huge filesize in restore view, etc ... this edition (11d) just doesn't work.

I haven't got any issue with 9.1 and no idea how symantec could screw it up? and why there is no fix for this problem? it affects dozens of our servers ... day by day ...