Das Notes Forum

Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: Hartie am 16.02.11 - 17:26:55

Titel: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: Hartie am 16.02.11 - 17:26:55
Hallo,

aus einer produktiven Datenbank werden versehentlich - sagen wir - 1000 Dokumente gelöscht. Als guter Admin hat man natürlich eine Datensicherung - hier sogar Tivoli Data Protection für Domino, so dass man die wiederhergestellte Datenbank bis genau 1 Minute vor der versehentlichen Löschung zurückfahren kann.

ABER: Die Datenbank ist auf >20 Servern repliziert und einige Server haben schon die Dokumente per Replizierung gelöscht bekommen, andere noch nicht.

Ersetze ich die fehlerhafte Datenbank mit dem Restore --> bei der nächsten Replizierung sind die 1000 Dokumente wieder weg wegen den Deletion Stubs in den anderen, replizierten DBs.

Lösung 1: Speichere alle versehentlich gelöschten Dokumente in der restaurierten DB nochmals --> Dokumente sind neuer als die Deletion Stubs -> nächste Replizierung verteilt die Dokus wieder


Gibt es bessere Lösungen?


Administrative Grüsse

Hartie
Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: cg-home am 16.02.11 - 21:54:17
Hallo Hartie,

das mit dem erneut speichern habe ich auch schon ab und zu mal gemacht.
Am besten vorher die Replikation stoppen und die Dokumente mehrmals
speichern. Wenn man es rechtzeitig merkt kann man es auch in einer
anderen Replik tun z.B.: in einer Lokalen.
Ich habe auch schon die zurück gesicherte DB auf einen anderen
Server oder Lokal kopiert und nur die fehlenden Dokumente raus kopiert.
Allerdings muss man dann auch in Kauf nehmen das Doc-Links nicht
mehr funktionieren. Und das geht natürlich auch nur in DBs wo es das
Design zulässt. Eine andere Möglichkeit kenne ich nicht, vielleicht weiß
ja jemand anderes noch eine Möglichkeit.
Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: Hartie am 17.02.11 - 09:53:51
Das "Rauskopieren" aus der Sicherung und "Reinkopieren" in die Produktiv-Datenbank ist zwar möglich, hat aber zu viele Nachteile (Doc-Links, Antworthierarchien, Repliziervolumen ...)

Das erneute Speichern als Möglichkeit hatte ich ja schon erwähnt.

Kennst Du eine Möglichkeit, wie man die Deletion Stubs löschen kann? Würde doch auch helfen, oder?


Gruß Hartie
Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: CarstenB am 17.02.11 - 10:06:50
Löschen von Deletion Stubs ist möglich mit veschiedenen Tools, z.B. mit dem Noteshound
http://domino-80.prominic.net/A55BE4/NotesHoundWeb.nsf/index.html?readform
Das ist kostenlos als Entwicklerversion verfügbar

Würde für die Serverrepliken funktionieren. Aber was ist mit lokalen Repliken
Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: Hartie am 17.02.11 - 10:28:51
@Carsten

Danke, dass Du mich auf einen Denkfehler von mir aufmerksam machst!

Ich bin davon ausgegangen, dass (z.B. mit einem Tool) gelöschte/entfernte "Deletion stubs" per Replikation an alle Server und Clients weitergegeben werden, also die "Deletion stubs" in allen Repliken gelöscht werden (sowohl in Serverrepliken als auch in Clientrepliken).

Dann müsste aber sozusagen ein Deletion stub für den gelöschten Deletion stub erzeugt werden. Aber diese Funktionalität ist wahrscheinlich in Domino/Notes nicht implementiert.

Folgt man also Deinem Vorschlag mit dem Tool, dann man müsste man in ALLEN Serverrepliken die Deletion stubs manuell per Tool löschen. Die lokalen Repliken z.B. eines Users mit Manager- und Löschrechte bleibt unberührt und bei der nächsten Replizierung dieses Admins sind die restorten Dokumente wieder weg.

Hartie
Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: MCPvsTron am 17.02.11 - 11:25:02
Hallo,

wir setzen ebenfalls TSM und den TDP Client ein und dies

Code
Folgt man also Deinem Vorschlag mit dem Tool, dann man müsste man in ALLEN Serverrepliken die Deletion stubs manuell per Tool löschen. Die lokalen Repliken z.B. eines Users mit Manager- und Löschrechte bleibt unberührt und bei der nächsten Replizierung dieses Admins sind die restorten Dokumente wieder weg.

ist meines Erachtens nach auch der richtige Ansatz. Alle anderen Repliken müssen repliziert haben und dann die Deletion Stubs dort löschen. Als Tool ist nicht nur dafür z.B. ScanEZ sehr gut. Wir haben allerdings keine lokalen Repliken, da heißt es in der Tat aufpassen.

Viele Grüße

Christian
Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: Hartie am 17.02.11 - 11:33:42
@Christian:

Ich bin 100% d'accord mit Deinem Vorschlag, wenn es nur serverbasierte Repliken gibt.

ABER:

Wie verhinderst Du, dass sich ein Notes-Anwender eine lokale Replik zieht? Das bekommst Du doch gar nicht mit?

Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: CarstenB am 17.02.11 - 11:40:15
Zitat von: Hartie am 17.02.11 - 11:33:42
Wie verhinderst Du, dass sich ein Notes-Anwender eine lokale Replik zieht? Das bekommst Du doch gar nicht mit?


ACL Eintrag "Dokumente replizieren und kopieren"
Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: MCPvsTron am 17.02.11 - 11:40:43
Hallo,

das ist richtig verhindern kann man das zwar nun über einen Flag in der ACL den wir aber auch nicht benutzen. Aber da wir unsere Home Verzeichnisse im Netzwerk liegen haben würden die MS-Kollegen schnell wach werden je nach Größe der DB.
Aber 100% verhindern kann man es nicht, es müßte aber jemand mit Admin Rechten durchgeführt haben und die hat kein Anwender bei uns, auch nicht auf seine Mail-DB.

Viele Grüße

Christian
Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: Norton am 17.02.11 - 13:20:18
Je nachdem, ob für ein kurzes Weilchen auf die Datenbank verzichtet werden kann oder nicht, löschst du alle Repliken und spielst dann die Datensicherung zurück und legst die Repliken neu an. Kommt natürlich auf Größe der Datenbank und auf Standorte und Netzverbindungen derselben an.

Ist jetzt nicht gerade der Traum eines Admins, würde aber das manuelle rumbasteln mit Tools in jeder Replik verhindern und lässt sich relativ bequem per Admin-Client bewerkstelligen.
Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: CarstenB am 17.02.11 - 13:22:18
und auch dann steht man wieder vor dem Problem der lokalen Repliken...

Ich denke Speichern der Dokumente ist die sinnvollste Lösung.
Titel: Re: Nach Restore einer Datenbank - wie mit Deletion Stubs umgehen?
Beitrag von: cg-home am 17.02.11 - 16:55:22
Hallo,

bitte auch nicht vergessen das seit dem Löschen der Dokumente
bestimmt auch wieder neue hinzugekommen sind. Wenn Du jetzt
die aktuelle DB wegnimmst und die aus der Sicherung einfügst
kann es sein das Dir neue Dokumente fehlen. Diese sollten dann über
die Replikation dann aber wieder reinkommen.

Was ich auch schon mal gemacht habe (aber mit Bauchschmerzen):
Man kann in den DB Eigenschaften bei den Replizierparametern
im Tab Platzsparer den Wert "90" bei "Dokumente aus Repliken entfernen"
auf "0" oder "1" setzt. ABER Du darfst auf keinen fall den
Haken davor setzen, den dann sind alle Dokumente weg.
Dieser Wert wird auch für das Löschen der Deletion stubs mit verwendet.
Wenn diese Eigenschaft repliziert wird (weiß ich jetzt nicht genau) dann würde
das auch bis zu den möglichen Lokalen Repliken durchschlagen.
Dann köntest Du Dir die DB aus dem Archiv Lokal kopieren und mit dem Server
replizieren. Dann sollten die fehlenden Doks wieder reinkommen und die neuen
bleiben drinn. Natürlich vorher nachsehen ob die Deletion Stubs weg sind
und am besten erst mal Testen und nicht gleich auf die produktive DB losgehen.
Wenn natürlich ein User dabei ist der erst in einem Monat wieder repliziert
ist das ganze wieder hinfällig. Am besten nach dem wiederherstellen die
ganzen Dokumente noch mal neu speichern.
Aber vom Gefühl her ist es einfacher die Sicherung Lokal abzulegen, die Dokumente
ein paarmal zu refreshen und dann mit dem Server zu replizieren.