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

Auflösung DAOS

(1/2) > >>

Sommersprosse:
Hallo zusammen,

ich bräuchte mal einen Rat von Euch.
Wir wollen bei uns DAOS auflösen, da wir mit der Datensicherung für DAOS große Probleme haben.

Folgende Umgebungsvariablen haben wir für den Archivserver auf dem wir DAOS im Einsatz haben.
Serverversion ist 8.5.3 FP4. Die Partition auf dem die Archive liegen ist 2TB groß und kann nicht erweitert werden, da wir die Partition auf dynamisch umwandeln müssten.
Auf der aktuellen Harddisk kann ich DAOS nicht auflösen, da mir der Platz nicht ausreicht.

Wir haben jetzt eine zusätzliche Harddisk über die VM zur Verfügung gestellt die 4TB groß ist. Ich würde jetzt gerne die Datenbanken auf diese Harddisk umziehen und in diesem Fall gleich DAOS auflösen und dann einen entsprechenden Verzeichnis link im Domino Directory einrichten.
Ich hatte das ganze Verzeichnis schon per File Copy kopiert, aber ich bin mir nicht sicher ob das dann mit den .nlo files noch funktioniert.
Am liebsten wäre mir eine Replikation auf die zweite Platte.
Wie kann ich das am besten ohne Datenverlust auflösen und die User davon so wenig wie möglich davon mitbekommen?

ronka:
Da wird etwas mehr information benötigt.

Reichen den geplannten 4 TB für alle datenbanken INKLUSIVE DAOS ?

Daos NLO dateien sind für den Lokale server einmalig, und sollten in das passenden verzeichnis stehen. NSF dateien bekommen vom Servern den passenden NLO datei beliefert, egal wo die nsf datei steht. NLO dateien verschieben würde ich von abraten.

Fragen:

1. Betriebsystem ? Windows oder Linux ?
Wenn Linux kannst du es sofort machen, und den directory link mit gross/klein buchstaben so anpassen das beides funktioniert.
Dann den datenbanken verschieben, und den link richtig benennen. Ist ein Risiko bei direkten zugriffe
Bei windoze nur mit downtime

2. ist es "gestattet" den Domino Server runter zu fahren, auch wenn es sich dabei nur um wenige minuten handelt ?
Dann könnte mann das Data verzeichnis einfach komplett auf den neue laufwerk kopieren (NICHT VERSCHIEBEN!) und dann dort komplett weiterarbeiten.
Mit verschieben habe ich schon mehrfach problemen gehabt, weil dabei u.u. sachen kaputt bzw verloren gehen können.

letzte frage.. Welche probleme gibt es mit den DAOS Sicherungen ? Vielleicht das einen lösung dort einfacher ist, also den DAOS abschaffen.

Sommersprosse:
Also die 4 TB reichen für die Datenmenge aus.

Das ganze läuft auf einem Windows2008 R2. Den Server kann ich auch mal einen Tag außer Betrieb nehmen, der Kopiervorgang dauert allerdings ein paar Stunden.
Das Data Verzeichnis liegt momentan auf E:, die Platte dann einfach mit anderem Laufwerksbuchstaben versehen, oder per Link?

Wir sichern mit Backup Excec, die haben aber die Unterstützung für IBM Notes eingestellt. Aufgrund der Datenmenge haben wir immer wieder Abbrüche bei der Sicherung gehabt, es war ein Glücksspiel die Daten zu sichern, wir haben die Timeouts hoch gesetzt, auch den DAOSmgr gestoppt, alles ohne Erfolg.

Die Strategie ist aber weiterhin mit der neuen Backup Excec Version zu sichern, man hat sich verschiedene Hersteller angeschaut, die auch IBM unterstützen, hat aber die Schwerpunkte auf andere Funktionalitäten gelegt.
Wir haben damals DAOS eingeführt um Plattenplatz zu sparen, das spielt mittlerweile keine Rolle mehr.

Andrew Harder:
Ich würde das folgendermaßen machen, vielleicht sieht ja noch ein Kollege drüber und hat noch die eine oder andere Idee dazu, oder ich habe jetzt auf die Schnelle etwas übersehen...

Erst:
- Platte mit neuem Laufwerksbuchstaben versehen (z. B. F)
- User über Downtime informieren
- Im Serverdokument die DAOS setttings anpassen, z. b. Filegröße auf 65536 und Purge auf 8.
Dann kommt nicht mehr viel ins DAOS rein und was drinne ist ist nach dem auflösen auch relativ schnell wieder aus dem DAOS raus, ohne das man manuell ein Purge hinterherschiessen muss.

dann in der Downtime:
- Server runterfahren
- mail Verzeichnis nach F verschieben
- Directory Link per Hand anlegen --> siehe Edit
- Server hochfahren

Am Schluss kann man dann für die Mailfiles das DAOS auflösen z. B. mit "load compact -c -daos off mail".
Wäre gut, wenn der compact am Wochenende läuft und eine Prüfung im Administrator, wo der compact das DAOS nicht auflösen konnte, sollte selbstverständlich auch gemacht werden.
Ich persönlich bin kein Freund davon, solche Aktionen gleich auf 100e von Mailfiles zu schießen, wenn Ihr also zufällig Unterordner unter mail habt, dann nimm besser die als Ziel.

Vergiss nicht das Backup Tool - wenn notwendig - hinterher entsprechend umzustellen, die Daten liegen dann ja auf einem anderen Laufwerk.
Wenn Backup Excec kein Domino mehr unterstützt, dann ist Euch schon klar, das Ihr für jedes Backup vorher den Domino - offene Files und so - runterfahren müsst und wenn das Backup fertig ist, muss anschließend der Domino wieder hochgefahren werden?

[EDIT]
Ich sehe gerade Rudi hat geschrieben, man könne das ganze data Verzeichnis verschieben.
Das ist eine gute Idee, dann könnte man das data Verzeichnis einfach nach F kopieren und anschliessend einfach das Verzeichnis in der notes.ini anpassen.
Wenn dann was schief geht, hat man immer noch ein Fallback :)

Tode:
Also ich würde ähnlich wie Andrew vorgehen, aber die Laufwerksbuchstaben vertauschen.

Ich benutze mal folgende Laufwerke:

Altes DATA: D:
Neues DATA: E:

Und so würde ich es tun:

1. lo compact -c -DAOS OFF auf alle Mailfiles (oder über erweiterte Eigenschaften im Admin- Client): keine neuen DAOS- Files werden angelegt, die alten bleiben bestehen.
2. Im Serverdokument das DAOS - Laufwerk auf E: umkonfigurieren
3. Server runterfahren
4. Komplettes Data- Verzeichnis (OHNE DAOS) von D: nach E: kopieren (wird ne Weile dauern bei 2 TB, auch ohne DAOS)
5. Laufwerksbuchstaben vertauschen: Das neue E: wird zu D: und E: wird zu D:
6. notes.ini auf "altes"- Daos- Verzeichnis durchsuchen und Verweise ändern / entfernen
7. Server neu starten

8. dbmt oder compact -c schedulen, um nacheinander alle Mailfiles zu komprimieren, und die Attachments wieder reinzuziehen

Navigation

[0] Themen-Index

[#] Nächste Seite