Domino 9 und frühere Versionen > ND7: Administration & Userprobleme

nsf-Dateidatum

<< < (3/3)

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

Navigation

[0] Themen-Index

[*] Vorherige Sete