Dringender Tipp:
Server aufräumen. Da befinden sich so viele inkonsistente Data-Verzeichnisse, die zu keiner NOTES.INI passen (keines ist das aktive Verzeichnis - wie der FATAL-Fehler besagt), daß es schwer wird zu helfen. Die temporären PID-Dateien wurden aufgrund eines ersten Absturzes nicht gelöscht und führen daher zu fehlenden bzw. falschen Task-Zuordnungen. Der Server versucht auf den Task mit der PID 4711 zuzugreifen, weil er den für den Task NSERVER hält, aber die 4711 stimmte nur vorgestern, als der Server abgestürzt ist, heute hat der NSERVER-Task die PID 3685 - und der Griff führte ins Leere. Der NSD hat jetzt wenigstens entdeckt (und berichtet dir das auch), daß dies sein, vor allem aber DEIN Problem ist. Du wirst mit dieser Anhäufung von Sicherungsverzeichnissen nicht glücklich - und dein Server erst recht nicht. Dabei sind nicht die Sicherungsverzeichnisse selbst das Problem, sondern der unsaubere Start von Notes mit unsauberen NOTES.INI-Dateien.
ERROR (0): d:\DominoData is used in the following notes.ini:
D:\Dominoserver\notes.ini
D:\Sicherung_Dominoserver\notes.ini
Ganz zum Schluß wage ich einmal eine Diagnose: wenn du den Server selbst nach einem Notes-Serverabsturz richtig bootest, dann stürzt der Server-Task nicht ab (weil beim Shutdown des Betriebssystems das Locking der PID-Datei aufgehoben wird und der nächste Notes-Serverstart eine neue PID-Datei anlegen kann), aber wenn du den Notes-Server ohne Reboot neu startest, muß der Notes-Server die bestehende PID-Datei verwenden, deren Einträge jetzt nicht mehr stimmen. Normalerweise wehrt er sich dagegen und startet nicht, aber du läßt bestimmt eines der KILLNOTES-Tools laufen, mit denen du es dann doch schaffst, aber eben nicht schaffst.
Die alte Weisheit, daß in der NOTES.INI die erste Zeile inter dem [NOTES]-Paragraphen DIRECTORY= lauten sollte, hat darin ihre Begründung.
Deshalb: Aufräumen. Unbedingt. Jetzt. Sofort.
