Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: MatsBS am 25.10.10 - 15:39:12
-
Hallo zusammen
Ich habe einen ganz komischen Fall:
Vor 2 Wochen hat mich ein User angerufen, bei welchem über 75% aller Dokumente "verschwunden" waren.
Ich habe daraufhin seine MailDB auf Server1 und Server2 (cluster), sowie die lokale Replik gelöscht und einen Restore zurückgespielt, wo alles wieder drinn war.
10 Stunden später war die DB wieder auf dem gleichen Stand wie vor dem Restore...! 75% der Dokumente waren weg!
Sie sind auch nicht im Trash etc. obwohl eine Softdeletion von 48h eingestellt ist.
Dieses Prozedere spiele ich nun seit 2 Wochen. Wir sind aktuell beim 6. Restore.
Die Datenbank bleibt manchmal 2 Tage OK und plötzlich sind wieder viele Dokumente (im die Selben) weg.
Was ich schon probiert habe:
- Neue ReplikID für die Restorte Datenbank
- div. ProfilDokumente gelöscht, die Verdächtig waren
- Client überprüft
- nach identischen Replika IDs gesucht
- DBIID geändert
- DB nur auf Server1 zurückgespielt (hat 3 Tage funktioniert) und dann erst auf den Cluster (DB war dann nach 26h wieder leer).
- Es gibt keine Agenten / Rules etc.
- User (schwört) hat nichts manuell gelöscht
Komisch ist, dass in den Activity-Details der DB ersichtlich ist, dass der User auf der Replik auf dem Cluster die Dokumente gelöscht hat. ich kann nun aber zu 99.9% bestätigen, dass er das nicht manuell gemacht hat. Es sind immer die selben Dokumente...!
Was hab ich vergessen? Wo steckt der Wurm drinn?
LN 8.5.0
Domino 8.5.1 FP2
-
Archivierung?
-
User archiviert manuell und nur selektierte Dokumente...! Im Archiv ist nix drinn ;-((
-
Hallo,
ist die mailbox (sehr) groß bzw. schon "alt"
spielt ein Cluster mit rein?
gibt es mehrere Repliken?
Gruß Werner
-
Sind die Dokumente unter "Alle Dokumente"? Wenn ja, Probleme mit der Ordnerstruktur?
Jan
-
Spacesaver in den Replica-Einstellungen?
Werden alte Dokument autom. gelöscht?
-
Liegen auf einem Server evtl. mehrere Repliken der selben DB?
-
Hallo...
- Nein, es liegt nur eine Replika auf dem anderen (cluster) Server
- Ja, DB ist rund 3GB gross und 2.5 Jahre alt
- Nein, unter ALLE DOKUMENTE ist natürlich nix drinn. Die DB zählt danach anstelle von 16'000 Doks nur noch 4'000 Doks
-
Database activity: Was sagen die Uhrzeiten der Löschungen aus und die Kadenz der Löschungen?
Bernhard
-
Das ist ja das verflixte....!
Einmal sind es 6h nach dem Restore, einmal 25h, einmal 2h etc. etc.!
Die Uhrzeiten sind auch immer unterschiedlich...!
09:23h
18:55h
22:15h etc. etc.
Ich kann keine Regelmässigkeit feststellen.
Übrigens...nein, Space-Savers sind auf der Replik etc. nirgends vorhanden.
-
Und was ist mit der Kadenz?
-
Wie meinst du das??
-
Liegt eine Replik auf dem Client?
-
Ja, es liegt immer wieder eine Replik auf dem Client.
Diese wird aber immer wieder neu erstellt, da ich ja die ReplikID immer ändere...
-
Und geht die Löschung vom Server aus, oder vom Client?
Sprich wo wird gelöscht, wenn Du nun die Replikation zwischen Client und Server deaktivierst?
-
Kadenz: "Schussfolge", die Frequenz der Löschungen. Hieraus kann man Schlussfolgerungen ziehen über den Ort der Löschungen und den Automatisierungsgrad.
- Laut Activity Details geschehen die Löschungen mit der ID des Anwenders?
- Welche Dokumente werden gelöscht? Sind diese zeitlich zusammenhängend?
- Hat der User ein synchronisierendes Mobilgerät?
Bernhard
-
Hallo,
sorry ich habe oben noch eine Fragen vergessen:
wird die Erstellung der Replik "von Hand" oder mit AdminP (spezielle im Cluster) angestoßen?
Gruß Werner
PS: mich erinnert das an eine Fall
-
Also, nochmal zusammengefasst:
- Löschung passiert auf dem Cluster mit der ID des Users
- Es werden Dokumente (Mails und Kalender) vor dem 1.10.10 bis cirka Januar 2010 und dann hats wieder ein paar stehen lassen. Danach werden wieder alle bis September 09 gelöscht etc. Also schon zusammenhängend, aber immer wieder mit Lücken...!
- Mobilgerät hat er, das ist aber nicht der Ursprung. Haben wir bereits geprüft (LOG, Tests etc.)
- Die Replik geschieht so, dass ich die DB einfach über den Admin von Server1 zum Clusterpartner ziehe....!
Habe jetzt gestern um 15 Uhr wieder einen Restore gemacht, auf Server1 gelegt und seither ist wieder alles i.O.
Ebenfalls hat User gestern eine lokale Replik erstellt...auch alles immernoch i.O.
Wenn ich nun aber die DB auf den ClusterServer setze, könnte ich wetten, dass Morgen die Doks wieder weg sind.... (Erfahrungen)
-
Hallo,
Nur mal so gefragt.
Von dem Restore schon mal eine neue Kopie (ueber den LN-Client) angefertigt und diese dann als neue Replik verteilt?
Wenn es dann nicht mehr passiert, kann man wohl getrost davon ausgehen, dass irgendwo an einer noch nicht beruekcsichtigten Stelle eine Replik herumgeistert.
Andreas
-
Bin ja nicht deppert ;-)
Habs zwar nicht auf diesem Weg gemacht, jedoch habe ich über die PowerTools die ReplicaID des Restors geändert...! Die DB hat nach jedem Restore eine neue ReplicaID...! Er DÜRFTE nichts mehr replizieren, auch wenn da noch irgendwo 'ne DB wäre.......!
-
Mats schreibt doch, dass er nach dem Restore der DB eine neue ReplicaID vergibt, Andreas.
Ausserdem würde bei der Replizierung in den Lösch-Aktivitäten eher nicht der Name des Benutzers stehen.
Bernhard
-
I GOT IT!!!!
Ich habe jetzt mühsam herausgefunden, dass alle Deletion-Stubs in der names.nsf des Users verfügbar sind.
Wenn die MailDatenbank dann auf den Cluster repliziert wird und der User das erste Mal seine lokalen Kontakte mit dem Mailfile repliziert, so werden auch die Deletionstubs wieder ins Mailfile genommen und voilà, die Dokumente sind wieder weg!
-
Was bitte hat die names.nsf damit zu tun? ??? ... aber da war was:
Wir haben uns letztens aber auch schon gewundert, dass im Traveler die lokalen Kontakte synchronisiert werden. Scheinbar macht Notes hier auf der Replikatorseite eine Replizierung der Kontakt-Dokumente zwischen lokaler names.nsf <-> mail-DB.
Interessant wäre aber, wieso kommen die deletion-stubs da überhaupt rein? (evtl doch durch das mobile Endgerät angelegt)
Gruß
Roland
-
Nein, es ist eigentlich jetzt im Nachhinein logisch wieso die da drinne stehen:
Über die Option "Synchronize Contacts" im pers. Adressbuch habe ich ja die Möglichkeit, meine Adressen auch aufs Mailfile zu "replizieren". Dies, damit ich im iNotes meine Kontaktdaten verfügbar habe.
Wenn ich nun im iNotes einen Kontakt löschen (dies passiert ja in meiner Maildatenbank), muss dieser deletionstub beim nächsten Replizieren natürlich auch ins names.nsf übertragen werden. Da in einer Deletion-Stub nur die UNID und ein paar Daten stehen, kann er natürlich nicht unterscheiden, bei welcher Deletion-Stub es sich um einen Kontakt oder z.B. um ein Memo handelt. Darum werden gleich alles Deletion-Stubs ins names.nsf übertragen.......!!!
Wenn ich jetzt also meine restorte DB wieder an die Stelle setze, wo das names.nsf das nächste Mal seine "Kontakte" und eben auch Deletionstubs hinrepliziert, dann ists passiert!
-
Vielleicht steht ich ja auf dem Schlauch, aber wie löst man das nun am besten ?
-
...ja, das ist leider nicht so einfach.
Ich habs jetzt in dem speziellen Fall mal so gemacht, dass ich alle DeletionStubs aus names.nsf gelöscht habe.
Muss halt jetzt schauen, dass der User nicht plötzlich "gelöschte" Dokumente wieder in der DB hat...! Sehe sonst aber keine Lösung.
-
Hallo!
Ich weiß - Du hast "Thema gelöst" gepostet - aber hat sich hier nochmal was getan?
Grüße!
-
Was sollte sich hier noch tun, Petra? Das funktioniert nun wirklich, wie man es auch logisch erwarten kann.
Unterbricht man den normalen Prozess (der "Replizierung" - wobei das in Wirklichkeit keine echte Replizierung ist!), dann muss man eben manuell nachhelfen, zum Beispiel mit entsprechenden Tools die Deletion Stubs in der Ausgangs-DB "meucheln", bevor wieder eine Synchronisation stattfindet.
Bernhard
-
Ich schätze, dass hier eine Archivierung zieht... und zwar auf einem ganz anderen Client....
Ich hatte das mal, dass ein Client eines Admins immer wieder die Datenbank eines Users bei sich lokal archiviert hat...
Ursache: Im persönlichen Adressbuch des verursachenden Benutzers (also desjenigen, der in den Datenbankaktivitäten als der drinsteht, der gelöscht hat), gibt es in der versteckten Ansicht "($Programs)" ein Programmdokument für compact -a Server!!mail\DeinUser.nsf
Wie das dahin gekommen ist, weiss ich nicht...
Deshalb auch das "unregelmässige"... wann immer DIESER Client gestartet wird (eventuell benutzt der User ja zu Hause einen anderen Client, oder aber es handelt sich um einen Admin- Client, der nur selten benutzt wird), fängt der an, die "Fremde" Maildatenbank zu archivieren. Checked mal darauf das ganze ab...
HTH
Tode
EDIT: uuups... vergesst es, hatte das hier gepostet, bevor ich die zweite Seite mit dem "gelöst" gelesen habe... Schande über mich...