This is my second e-mail on this list. This time not a request for help,
but a report of the cause and a work-around for the problem I found.
I'm sending this mainly to get this in the archives, perhaps someone
will be helped by the information I provide below. You will find my
original question below...
---------- My findings ----------
What caused the problem was the use of the Solaris automounter in the
system which ran the Notes server. Notes was given the virtual path
/database/notesdata as the location of the notes database files, while
the real path was /export/database/notesdata. Notes ran fine with this
setup. However the NetBackup Notes agent, when given the location
/database/notesdata, sees that it is an automounted filesystem and goes
back to the source, in this case /export/database/notesdata. It then
enumerates all files in that directory (including subdirectories) and
tries to use the Notes Backup API to backup files with the path
/export/database/notesdata/..., e.g.
/export/database/notesdata/names.nsf. The Notes API however does not
seem to approve of those names, as the begin with /export/database/...,
not /database/...
The workaround was easy: when we changed the NOTES.INI file to point to
/export/database/notesdata in stead of /database/notesdata, everything
suddenly worked without any more problems! This configuration is now
working for a couple of weeks without any more problems, both in the
test and in the production environment of our customer, so I am
confident the problem will not reappear.
So, if I were you, I would double-check whether NetBackup is handing
over filenames to the Notes Backup API with the correct pathname prefix.
On Solaris at least use of the automounter will cause this to be
different and perhaps there are similar configurations possible on
Windows systems? The motto is: "Make sure both Notes and the NetBackup
Notes agent use the same path to the database files!"
In my opinion this is a problem with the NetBackup Notes agent: it
should consider the case that Notes is running in an automount setup and
will use the virtual paths internally. The agent should *NOT* hand the
real paths to the Backup API, but offer the same virtual paths that
Notes itself uses.
---------- My original question ---------
I've got a problem I cannot figure out. Has somebody seen and solved
this problem with the NetBackup Lotus Notes agent?
The situation:
- Notes R5.0.10 on Solaris 8
- NetBackup 4.5 GA, patched to MP1, also on Solaris 8
The NetBackup Notes agent is installed and configured as the
installation document tells me to (with the keyword ALL_NOTES_DATABASES,
not the path to the Notes data directory. However, I also tested this
with the path /export/database/notesdata; it makes no difference). It
does perform backups, but some .nsf and one .box files are not handled
properly, even when Notes is (re-)started just before the backup and
with no users active.
* The files that give me problems are:
/export/database/notesdata/admin4.nsf
/export/database/notesdata/busytime.nsf
/export/database/notesdata/decsadm.nsf
/export/database/notesdata/events4.nsf
/export/database/notesdata/log.nsf
/export/database/notesdata/mail.box
/export/database/notesdata/names.nsf
/export/database/notesdata/names2.nsf
/export/database/notesdata/smconf.nsf
/export/database/notesdata/statmail.nsf
/export/database/notesdata/statrep.nsf
* When performing incremental backups, the following warning is given
for each file:
WRN - Failure determining if backup of Lotus Notes database <name> is
required:
0x20D:This database is currently being used by someone else.
In order to share a Notes database, all users must use
a Domino Server instead of a File Server.
The incremental backup is finished with status 0 (!). The files are
*NOT* backed up.
* When performing full backups, the following error is given for each
file:
ERR - Cannot open Lotus Notes database <name>:
0x1:Release 5.0.10 |March 22, 2002
The full backup is finished with status 1 and the files are *NOT*
backed up.
* Only Notes processes are keeping the files open
- fuser gives:
admin4.nsf: 10401o
busytime.nsf: 10409o
decsadm.nsf: 10414o
events4.nsf: 10411o
log.nsf: 10401o
mail.box: 10403o
names.nsf: 10420o 10412o 10409o 10406o 10405o 10404o 10403o 10402o
10401o
names2.nsf: 10420o 10412o 10409o 10406o 10405o 10404o 10403o 10402o
10401o
smconf.nsf: 10401o
statmail.nsf: 10405o
statrep.nsf: 10411o
- ps for these PIDs gives:
UID PID PPID C STIME TTY TIME CMD
notes 10401 10380 0 Nov 15 ? 177:14
/opt/lotus/notes/latest/sunspa/server
notes 10402 10401 0 Nov 15 ? 0:01
/opt/lotus/notes/latest/sunspa/replica
notes 10403 10401 0 Nov 15 ? 0:04
/opt/lotus/notes/latest/sunspa/router
notes 10404 10401 0 Nov 15 ? 0:01
/opt/lotus/notes/latest/sunspa/update
notes 10405 10401 0 Nov 15 ? 0:41
/opt/lotus/notes/latest/sunspa/stats
notes 10406 10401 0 Nov 15 ? 0:25
/opt/lotus/notes/latest/sunspa/amgr
notes 10409 10401 0 Nov 15 ? 0:13
/opt/lotus/notes/latest/sunspa/sched
notes 10411 10401 0 Nov 15 ? 1:59
/opt/lotus/notes/latest/sunspa/event
notes 10412 10401 0 Nov 15 ? 0:07
/opt/lotus/notes/latest/sunspa/http
notes 10414 10401 0 Nov 15 ? 0:03
/opt/lotus/notes/latest/sunspa/decs
notes 10420 10401 0 Nov 15 ? 12:09
/opt/lotus/notes/latest/sunspa/smtp
Please, can someone tell me what I'm missing?
--
__________________________________________________
Eric van de Meerakker <Eric AT RHODIX DOT nl>
RHODIX
unix professionals
Visiting address : Luchthavenweg 81
Mail address : Luchthavenweg 81107
5657 EA Eindhoven
The Netherlands
Phone : +31 (0)40 2904702
Fax : +31 (0)40 2904921
Website : www.RHODIX.nl
__________________________________________________
|
