nsf-Dateidatum

[jr]

Hallo,

ich habe eine kleine Frage.
Wenn ein Server mit einem anderen Server eine Datenbank repliziert, dann ändert sich auch das Datum der nsf-Datei. Dies passiert leider auch, wenn überhaupt nichts zu replizieren ist. Vermutlich wird das Replizierdatum gespeichert und damit die Datei geändert.

Gibt es eine Möglichkeit, dass das Dateidatum nicht geändert wird, wenn nichts repliziert wird?

Hintergrund: Die Standard-Backupprogramme reagieren nur auf geänderte Größe und Datum. Damit sind die Datenbanken praktisch jeden Tag neu und müssen vollständig gesichert werden.

Gruß,

Joachim

[Glombi]

Kurz und knapp: Nein.

Wenn repliziert wird, wird zumindest das Replizierprotokoll geändert.

Andreas

[hallo.dirk]

Hintergrund: Die Standard-Backupprogramme reagieren nur auf geänderte Größe und Datum. Damit sind die Datenbanken praktisch jeden Tag neu und müssen vollständig gesichert werden.

..das passiert ja selbst beim updall oder compact....
Du solltest Dir das Thema Transaktionsprotokollierung mal anschauen.....hoffe euer Backup unterstützt dies....

[jr]

Danke für die schnellen Antworten.

Schon klar, dass es Backupmöglichkeiten gibt, die nur die Änderungen übertragen. Aber hier geht es halt um reine Dateibackups.

Schade das es nicht geht, aber da kann man halt nichts machen.

Gruß,

Joachim

[Tode]

alles in Notes basiert mehr oder weniger auf Timestamps.

Und diese Timestamps werden nun mal in der Datenbank selbst abgelegt.
Das Filesystem- Änderungsdatum einer nsf- Datei ist für die Entscheidung "sichere ich oder nicht" also in etwa so nützlich wie die Information ob in China gerade ein Sack Reis umgefallen ist.

Tja, nicht umsonst gibt es entsprechende Sicherungs- Agenten für Domino...
Über den Sinn/Unsinn bzw. die Risiken einer "dummen" Filesicherung will ich jetzt gar nicht diskutieren, solche Diskussionen werden sowieso immer mit "ham wir kein Geld für" abgewürgt, ein Argument, gegen das es leider kein ziehendes Gegenargument gibt. So lange jedenfalls bis die maildatei des Geschäftsführers nicht korrekt gesichert wurde genau in dem Augenblick wo der aus versehen seine wichtigste Mail seines wichtigsten Geschäftspartners gelsöcht hat....

Gruß
Tode

[tschroeder]

da kann man nur hoffen, daß wenigstens der Server runter gefahren wird, bevor die Sicherung startet 

VG Thorsten

[jr]

Hallole,

die meisten Sicherungssysteme, die keine Filesicherung machen, sichern Daten. Das ist ja auch gut so, denn wenn die verloren gehen, dann sind sie nur schwer wieder herzustellen. Und in den meisten Firmen kommt es wohl in erster Linie auf die Daten an... 

Ich bin aber Entwickler. Und in diesem Fall geht es mir nicht um die Daten, sondern vor allem um die Design-Elemente. Wenn ich irgend wann einmal Murks gemacht habe, dann möchte ich eine ältere Version der Datenbank haben; die Datendokumente selbst sind dann nicht relevant, weil das eh nur Testdaten sind. Und die Backupsysteme, die ich kenne, machen das halt nicht. Aber vielleicht kennt da ja jemand was...

CVS ist da üribens auch nur bedingt sinnvoll, weil ich da auf ähliche Probleme stoße wie bei der Filesicherung. Geringste Änderungen ergeben zum Teil riesige CVS-Änderungen.

Den Server runter fahren brauch ich auch nicht, weil das Backup zuvor eine Client-Replikation auf einen Nicht-Notes-Server macht und dann die Repliken gesichert werden. Da greift also definitiv niemand drauf zu.

Und natürlich, die Geld-Frage ist eine ganz Wesentliche. Bei dutzenden von Servern und tausenden Clients spielt das sicher keine so große Rolle, aber ich habe nur eine kleine Firma und da kommt es auf jeden Cent an. So lange man es nicht selbst bezahlen muss, denkt man da wohl doch etwas anders, als wenn man jeden Cent den man ausgibt auch selbst verdienen muss. Deswegen ist für mich die "dumme" Filesicherung derzeit die einzige Möglichkeit, und wenn es eine Chance gibt, dies zu optimieren (auch wenn ich es selbst programmieren muss) dann nutze ich die.

Aus all den oben genannten Gründen ist für mich eine Filesicherung derzeit die einzig sinnvolle und kostengünstigste Möglichkeit, verschiedene Versionen eines Entwicklungstemplates zu sichern. Wenn da jemand Alternativen kennt bin ich ein dankbarer Abnehmer. 

Nochmals Danke für Eure Antworten und viele Grüße,

Joachim

[smoki]

Das die Datenbanken zuvor via Client-Replikation lokal gesichert werden, war vorher nicht erkennbar und ist in der Tat eine Kostengünstige Lösung.

Allerdings wird bei Sicherungstools, die via Transaktionsprotokoll gesichert werden, auch das Design mitgesichert, da es hierbei um eine Note handelt (ein Dokument ist auch eine Note). Du kannst dann auch immer die Datenbank zu einen beliebigen Zeitpunkt wiederherstellen. Leider bietet die IBM, das nicht für Lotus Domino alleine an, sondern man braucht ein "Teures" Tool, wie TSM/TDP.

Ich kann nicht beurteilen, ob eine Vollsicherung billiger in deiner Umgebung kommt, als mit einen Tool.

Zu einer Änderung in den Dateien muss es allerdings immer kommen bei einer Replikation, da das Replikationsprotokoll aktualisiert wird (was prinzipell auch eine Note ist), daher wurde die Datei geändert.

Ich weiß nicht, wie die API-Funktionen aussehen, die für die Transaktionssicherung verwendet werden. Allerdings habe ich ähnliche Probleme, aber aus ganz anderen Gründen -> Weltweit verteilte Server mit teilweise "engen" Leitungen. Vielleicht finde ich ja mal die Muse, die funktionen anzusehen, allerdings vermute ich mal, dass es viel zu komplex wird, um da alleine eine eigene Lösung stricken kann. (Da der Recovery-Prozess auch funktionieren muss!)

Deltas mittels CVS oder ähnlichen zu machen, halt ich für nicht sinnvoll, da es viel zu dumm ist die Binaries zu verstehen. Die Datenbanken zuvor mittels DXL zu dumpen und dann zu vergeleichen ist sicherlich eine Möglichkeit, aber ich habe die Erfahrung gemacht, dass hier nicht alle Datenvollständig sind. Zudem braucht man dann eine Versionsverwaltung die XML-Deltas vergleichen kann, bisher kenne ich nur Ansätze aber nichts das wirklich produktiv verwendbar wäre.

Vermutlich musst du daher bei der Vollsicherung bleiben.... Auch wenn es viele Bänder kostet.

Gruss
Chris

[smoki]

Es lohnt sich ja tatsächlich manchmal die Dokumentation der C-API anzusehen!!

Es gibt dort ein Sample "Admin\Backup" (Zumindest in der Lotus Domino C API 6.5).

Es kann auch Archive Logs sichern(!) in eine Datei! und anscheinend auch zurückspeichern? 

Ob das Beispiel Praxistauglich ist, insbesondere für deine Anforderungen weiß ich allerdings nicht!

Hier findest du denn Link zur API -> http://www-128.ibm.com/developerworks/lotus/downloads/toolkits.html

Wäre interessant zu wissen, ob es dir etwas bringt, wie gesagt ich suche auch noch nach Lösungen

Gruss
Chris

[smoki]

Hallo!

Ich habe mal Zeit gefunden, die beiden Tools zu Compilieren....

Der dbbackup scheint wirklich die Datenbanken sauber zu sichern... Mit den Transaktionslogs hab ich es noch nicht probiert.

Vielleicht findest du ja auch mal Zeit damit rumzuspielen

Ein Feedback würde mich freuen!

Gruss
Chris

[jr]

Hallo Chris,

vielen Dank für die ausführliche Hilfe. Habe mir das Ganze einmal angesehen und Dein compilierten Code herunter geladen.

So wie es für mich aussieht macht "dbbackup" einfach nur eine Kopie der zu sichernden Datenbank. Das Ziel ist eine exakte Kopie der Datenbank inkl. aller Ansichtsindizes und sonstigen Zusatzdaten. Die Dateigröße ist exakt mit der Originaldatenbank identisch. Interessanterweise ändert das Programm den Zeitstempel der Originaldatenbank!?!? Also irgend etwas muss da auch passieren, der Zeitstempel von Original und Backup ist dann identisch. Mit dem Backup kann man wie mit jeder anderen Datenbank auch umgehen, sogar ganz normal damit arbeiten...

Mit dem "dbrecs" komme ich aber nicht klar. Sowohl "dbrecs NOTE datenbank.nsf" als auch "dbrecs RESTORE datenbank.nsf ziel.nsf" liefern bei mir Fehlermeldungen. Aber im Prinzip ist das gar nicht notwendig, weil das Backup ja die volle Datenbank ist und man im Zweifelsfall die Datenbank einfach per Copy And Paste wieder einfügen kann.

Zum Sichern von göffneten Datenbank ist das Tool ideal, ich könnte also auf die vorherige Client-Replikation verzichten. An der Vollsicherung ändert sich aber nichts und wenn ich Versionen brauche muss ich auch wieder komplette Datenbanken sichern.

Im Moment bin ich relativ stark ausgelastet, aber wenn ich wieder etwas mehr Zeit habe, werde ich mich mal um ein Backup für Design-Elemente kümmern. Das müsste ja mit Noteseigenen- und API-Funktionen machbar sein, so dass man auch verschiedene Versionen in einer Datenbank vorhalten kann. Wie gesagt kann das aber noch ein Weilchen dauern...

Mit dem DXL-Ex- und Importer habe ich schon experimentiert, aber bereits eine importierte Maske sieht nicht mehr so aus wie die ursprünglich exportierte. Das scheint also noch nicht richtig ausgereift zu sein. Zum Suchen von bestimmten Elementen (z. B. Display-Felder, wie in einem anderen Thread von mir) ist das Ideal, aber für Sicherungen kann man es derzeit noch nicht nutzen.

Gruß,

Joachim

[smoki]

Hallo!

Ja das mit dem "dbbackup" hat bei meinen Tests immer gut funktioniert und er löst dein Vorgehen mit lokalen Repliken sicherlich gut ab. Ggf. werde ich den dbbackup noch aufbohren, damit man das ganze Data-Verzeichnis auf einen Schlag sichern kann.

Zum Test des "dbrecs" bin ich auch noch nicht gekommen. (Es versteht sich ja von selbst dass man damit nicht in der Produktion einfach rumspielt!...)

Wichtig ist aber, dass im Serverdokument. Archivierende Logging aktiviert ist und der Server anschließend neu gestartet wird, dann legt er auch die Logs an. Ich weiß nicht, ob du dass schon getan hast?

----
Allerdings:
habe ich mir weiterführende Gedanken gemacht, allerdings kann es sein, dass diese Lösung für dich praktikabel bleibt, da du nur "einen" Server an "einen" Standort hast. Oder?

Für archivierendes Logging ist nämliches folgendes Vorgehen notwendig:

Regelmäßiger Full backup (zum Beispiel einmal Sonntags)
Mehrmals täglich ein Backup der archivierenden Logs.
Jede Nacht eine inkrementelle Sicherung aller Datenbanken, die neu sind bzw. eine neue DBID bekommen haben.

Das mit der inkrementellen Sicherung wirft das Problem auf, dass du irgendwo speichern musst, welche Datenbanken schon gesichtert wurden, bzw. mit welche DBID.

Dieser Datenspeicher kann natürlich auch eine Notes-Datenbank sein, die auf dem selben Server liegt. Allerdings wird dann ein Restore bei einem Hardware-Ausfall unmöglich. Daher muss dieser Datenspeicher auf einer anderen Maschine stehen (je nach Sicherheitsanforderungen auch in einem anderen Raum oder gar ein anderer Standort!).

Die archivierenden Logs müssen auch noch protokolliert werden im Datenspeicher.

Denn wir machen es ja nicht aus Langeweile, sondern wir wollen den Restore fahren können und das relativ einfach.

Daher:

Letztes Full Backup der Datenbank und dann zurückspielen der Logs.
Ggf. zu verschiedenen Sicherungszeitpunkten (Tagen/Stunden je nachdem...). Da muss irgendwo stehen, welches Log für welchen Zeitraum gilt.

Soweit gehen diese Tools allerdings nicht und man muss quasi alles Händisch machen.

Das ist vermutlich der Grund, warum es "teure" Tools gibt.

So... ich werde dieses Thema momentan nicht weiterverfolgen können, da ich mich in ein verlängertes Wochenende ohne Computer verziehen werden

Gruss
Chris

[smoki]

Hier eine kleine "Einführung" in den dbrecs und was auf dem Server zu tun ist

-> http://smoki.atblogs.de/index.php?op=ViewArticle&articleId=827&blogId=82

Kurz auch hier ohne Einzelheiten und Bilder:

Zunächst ist "Archivierendes Loggen" zu aktivieren und der Server neu zu starten!

Anschließend sind die zu sichernden Datenbanken nochmals mit "dbbackup" zu speichern, da diese eine neue DBIID bekommen haben.

Wenn genug Änderungen auf dem Server durchgeführt wurden (<64MB), kann man die Logs mittels "dbrecs archive" speichern!

Den Sicherungsstand zurückspielen kann man anschließend damit, dass man die letzte Sicherung von "dbbackup" wieder ins dataverzeichnis kopiert und anschließend die Logs mit "dbrecs recover" nachfährt!

Gruss
Chris

[jr]

Hallo,

wow, da hast Du ja einen richtigen Roman in Deinem Blog geschrieben und einiges an Zeit investiert. Das mit dem Backup funktioniert einwandfrei, wenn man weiß, wie das Tool arbeitet. Trotzdem habe ich noch eine Frage:

Wenn ich alles richtig verstanden habe, dann wird das neue Transactionlog-File erst dann archiviert, wenn es größer als 64 MB ist. Was passiert, wenn diese Schwelle nicht überschritten wird und nur wenige Änderungen stattgefunden haben? Auch wenn man "nur 50 MB" geändert hat, braucht man ja trotzdem ein sauberes Backup. Nun, mit Transactionlogging habe ich noch keine echte Erfahrung und muss mir das in einer ruhigen Minute mal genauer zu Gemüte führen, ob das für meinen Einsatz sinnvoll ist oder nicht.

Die Sicherung hat die gleiche Größe wie das Original und wenn die Logs nur bei mehr als 64 MB archiviert werden, dann muss man doch jedes mal ein volles Backup fahren, oder habe ich das falsch verstanden?

Eine weitere Schwierigkeit sehe ich mit der DBIID. Die meisten meiner Kunden lassen jede Nacht den Compact laufen und da wäre dann immer wieder ein vollständiges Backup notwendig. Bei mir läuft der Compact nur wenn ich ihn manuell anstoße, da habe ich also keine Probleme mit.

Gruß,

Joachim

[smoki]

Hallo!

Ja, es artet langsam richtig in Arbeit aus, obwohl ich es vermutlich beruflich gar nicht benötige!

Hier noch ein Link zu einem Redbook, dass man lesen sollte:

http://www.redbooks.ibm.com/redbooks/pdfs/sg245247.pdf

Es geht zwar um TSM, aber teilweise sind das auch generelle Guidelines!!

Beispielsweise:

Kapitel 4.1.3.2!
Hier wird empfohlen den "compact -B" nur einmal wöchentlich zu fahren! (Also logischerweise vor dem Fullbackup!)

Zu der 64 MB Geschichte:

Ich vermute, und bitte um Korrektur falls ich falsch liege, dass diese verloren gehen, wenn man einen Hardware-Defekt hat und die aktiven Logs auch hopps gehen!

Wenn nur die Datenbank zurückgespielt werden muss, dann ist das kein Problem, da dann die Logs immer noch aktiv im Logging Verzeichnis vorhanden sind und halt noch nicht auf dem Backup!

Ich bastle zu Hause(!!!) gerade an einen Tool, dass die Anwendung erleichtern soll.

Etwa:

load backup -F (Für ein Fullbackup in ein definiertes Verzeichnis)

Mikkel Heisterberg will noch weitere Features:
http://lekkimworld.com/lekkimworld/2006/08/25/smokis_notesblog_performing_on_line_backup_using_the_c_api.html

Es artet also tatsächlich in Arbeit aus.

Da alles nur Hobby ist, verspreche ich aber nichts!!!

Insbesondere... weiß ich nicht, ob man dass Produktiv bei Kunden einsetzen soll!!!!? (Stand heute: NEIN)

Gruss
Chris