Restore im Cluster / mit Repliken

[der busse]

Guten Abend,

ich habe möchte ein paar NTFs aus einem Backup wieder herstellen.
Die zu erstetzenden NTFs liegen auf einem Server eines Domino-Clusters, der tauscht sich munter mit anderen Servern in unserem Netzwerk aus. Da ich mich bisher auf "alle Repliken auf den Servern löschen, Backup herstellen, Repliken erstellen" beschränkt habe, es aber irgendwie immer mehr Server werden, wäre meine Überlegung, ob das nicht auch schöner geht.

Die Suche war eher erfolglos, da sich die gefundenen Seiten immer mit normalen Servern und einem einfachen Restore beschäftigen.

Ich vermute mal, das dies nicht klappt, weil Replikationen ja immer Änderungen nachvollziehbar machen und nicht wirklich eine DB zum Master machen und dann mal kurz die Historie (Deletion Stubs usw.) vergessen.
Da fragen nichts kostet, frage ich jetzt doch einmal, ob es so etwas gibt bzw. wie man das umsetzen müsste. Falls Ihr einen Link oder eine Erläuterung hättet, schon einmal Danke für die Zeit, die Ihr Euch nehmt.

Gruß
Der Busse

[ronka]

Es hängt davon ab. Generell ist das Unterschied zwichen Templates (NTF) und Datenbanken (NSF) nur geringfügig. Betrachtet aus den Sicht einer Datensicherung.

Was möchtest du erreichen ?

Gelöschte (gestaltungs) Dokumente wieder herstellen ?
Dann -> Restore AUSSERHALB das Data verzeichnis, und danach für den bestehenden Repliken den Replizierung abschalten (ALLE Repliken!), dann einzeln den Deletion stubs löschen. EINE einzelne Replik der NICHT auf den Server mit den Restored Database liegt den Replikcation wieder einschalten.
Den Datenbank aus den Restored verzeichnis auf OS Ebene KOPIEREN (ebenso ausserhalb Data !), und den Kopie verschieben INS Data verzeichnis (beim Kopieren direkt ins Dataverzeichnis könnte der Datenbank vom Server "gesehen" und angefasst werden und damit direkt Kaputt sein).
Dann diesen beide mit ein ander Replizieren lassen. Dann sollten die gelöschte dokumente die noch in den Backup vorhanden sind, wieder da sein..
ABER achte darauf das auch USER Repliken haben können mit diesen Deletionstubs, und damit muss sofort den Cut-Off date gesetzt werden, damit DIE nicht mehr zurück kommen.

Kompletten Datenbank wieder herstellen (ohne rücksicht auf die Dokumente die seit dem erstellt würden).
Dann -> Restore AUSSERHALB das Data verzeichnis, Alle Repliken Löschen (besser Manuell als über AdminP, weil dieses deutlich mehr Zeit kostet).
Den Datenbank aus den Restored verzeichnis verschieben INS Data verzeichnis.
Repliken erstellen.

Kurz gesagt, IMMER ausserhalb von Data wiederherstellen, und danach ins Data verschieben.

[der busse]

Danke für die Antwort.

Ein gutes Beispiel, was ich machen möchte, dürfte die Standard HCL Mail10.NTF sein.
Da sind zuvor auf einem 10 FP3 Server 3 Sprachen zur Auswahl drin gewesen (Deutsch, Englisch, Spanisch). Da stelle ich eigentlich immer das Datum auf unverkürzt, weil die meisten User das so haben wollen - spart halt am Ende Arbeit.
Die ist durch einen dummen Umstand gegen eine neuere 11er Version auf einem anderen Server mit nur einer Sprache repliziert worden (ich hatte es so verstanden, dass jede eigene Übersetzung seine eigene Replik-ID hat  ). Nun ja. Ich traue mir an der Stelle einfach nicht eine Aussage zu, ob das dann noch alles konsistent ist und will dann wie gesagt die reine NTF wegen der Gestaltungselemente für neue saubere Postfächer aus dem Backup holen.
Zumindest bin ich da etwas skeptisch, was da am Ende bei herum kommen würde.
Ich weiß ja z.B. gar nicht, wie Änderungen an Views / Columns usw. gezählt werden bzw. was als Element zu einem Dokument gezählt wird. Und da ich nicht weiß, was das Template Team alles hantiert hat, dürfte für mich der bisherige Weg (Repliken löschen und dann ins Data zurück kopieren) die sichere Lösung sein, damit ich kein Mischmasch oder evtl. Konflikte bekomme.

[CarstenH]

Der wichtigste Tipp von Rudi ist sein letzte Satz: IMMER ausserhalb vom Data-Verzeichnis wiederherstellen.
Backupprogramme mit nativer Domino Unterstützung (DB Agent) fragen beim Restore nach, ob die DB außerhalb des Data wiederhergestellt werden soll.

Stolperfallen sind einerseits die von Rudi schon genannten Deletion Stubs als auch Replizier- oder Transaktionsprotokolle (wenn das Backup innerhalb der noch im TXL Verzeichnis verfügbaren Logs liegt). Technisch anspruchsvoll wird es nochmal sobald DAOS im Spiel ist, da die zurückgeholte DB dann nur einen Teil der Daten beinhaltet. Liegt der Grund des Restore noch innerhalb der DAOS Prune Zeit muss man sich keine Gedanken machen, liegt er weiter zurück dann schon.

Für dein aktuelles Problem/Beispiel, die Standard HCL Mail10.NTF mit einem bestimmten Stand wiederherzustellen ist aber die altbewährte Methode die beste, da hier nichts auf Dokumentebene zurückgeholt werden muss. Einfach die "fehlerhafte" Db auf allen Servern löschen, die alte aus dem passenden Backup holen und neu über die Server verteilen.

[ronka]

Für (standard) Templates ist einen anderen Weg sicherer..

ALLE neue Templates IMMER als Datenbank KOPIE anlegen, und damit mit einen NEUEN REPLIK ID, dann kann im zukunft keine "bestehenden" NTF kaputt gehen.

Sprich NACHDEM der Server installiert ist UND ZUVOR der gestartet wird, ALLE (neue) Templates die irgendwie "personalisierbar sind" RAUS aus den Data verzeichnis (und unterverzeichnisse) ausserhalb des Data verzeichnis VERSCHIEBEN.

DANN die dingen zu ein CLIENT verschieben / Kopieren (OS ebene), und DANN einen Kopie in einen EIGENSTÄNDIGES verzeichnis (unterhalb data, z.B. Templates) als neue KOPIE (und damit eigenen Replik ID) anlegen.

Beim nächsten Update GENAU das gleiche machen. Dann UND NUR DANN passiert dir so etwas NICHT.

PS. Ach ja, denk dran das NUR den Template name für Notes wichtig ist, der DATEIName ist ihm egal. Mail10.ntf kann also durchaus auch Mail-Meine-Firma.ntf heissen und trotzdem den gestaltung aller Datenbanken beeinflüssen, WENN der die richtigen Template name hat.