Moin,
ich möchte mal behaupten, das geht noch simpler:
1) DB auf Server in Verzeichnis außerhalb des Domino-Data zurücksichern
2) set cluster_admin_on=1 auf dem Server (auch, wenn's kein Cluster ist)
3) cl copy c:\verzeichnis\ausserhalb\data\names-aus-backup.nsf restore\names-vom-wannauchimmer.nsf
Man beachte: Parameter 1: absoluter Pfad, Parameter 2: relativer Pfad im data.
Und schwupp's, hab ich eine DB-Kopie (nicht Replik) der Rücksicherung auf dem Server, wo ich dann auch per FullAccess-Admin (oder im Falle der names.nsf hoffentlich auch ohne) drankomme.
Doku dazu z.B.
hier.
Alternativer Ansatz, sofern man die passenden Möglichkeiten hat: den entsprechenden Deletion Stub identifizieren und entfernen (oder wenn's nicht weh tut, alle Deletion Stubs entfernen) und dann die Rücksicherung gegen die aktuelles names.nsf replizieren. Danach dann aber schnell wieder das Personendokument einmal neu speichern, sonst gewinnt vermutlich wieder der Deletion Stub vom Nachbarserver, wenn es einen gibt.
Ich muß aber dazu sagen, daß ich letzteren Ansatz bisher nur wenige Male mit Postfächern erfolgreich probiert habe - ob ich mich das bei der names.nsf trauen würde, weiß ich selbst noch nicht recht..
Wenn es übrigens keine Deletion Stubs in der DB gibt, würde mir das zu denken geben:
Das letzte Mal, als ich ein Phänomen mit unerklärlich verschwindenden Dokumenten hatte (allerdings auch wieder in einem Postfach), war es der Haken bei "Remove documents not modified in the last (days)" in den Space Savers der Replikationsoptionen. Worauf man mich freundlicherweise hier im Forum gestupst hat, nachdem ich da fünfmal dran vorbeigeguckt und schon Teufelswerk
vermutet hatte..
Ciao
Sascha
