Mail- Datenbanken "zerstört"...

[Tode]

Wir haben hier einen Server, der sporadisch Mail- Datenbanken "zerstört",
und ich habe keine Ahnung, wie das kommt.

Protokoll:

Dienstag, tagsüber: Die Datenbank enthält über 8000 Dokumente, hat eine Grösse von ca. 3GB.
Dienstag, 21:00 : Der Benutzer arbeitet mit seinem Blackberry am Kalender: Alles noch OK.
Dienstag, 22:00 : Symantec Backup Exec 11d startet die Sicherung des Servers
Dienstag, 22:38 : Der Server meldet eine korrupte Datenbank.
Mittwoch 01:00 : Der Designer- Task aktualisiert alle Design- Elemente in der Datenbank (nur in dieser, die Schablone ist aber noch die gleiche wie am Dienstag)
Mittwoch 02:00 : Der catalog- task protokolliert die Anzahl der Dokumente in der Datenbank mit 30, die Grösse mit immer noch 3GB, und die % verwendet mit 99% - Irgendwas passt nicht zusammen.
Das Datenbank- Aktivitätslog zeigt keinerlei verdächtige Schreib- Vorgänge.
Mittwoch gegen 8:00: Der Benutezer öffnet seine Datenbank. Alles ist weg bis auf wenige Mails und Kalendereinträge.

notespeek zeigt keine hohe Anzahl DeletionStubs, zeigt ausserdem die gleichen Zahlen: 40 Dokumente, 3GB Grösse...


Frage 1: Der Verdacht liegt natürlich nahe, dass die Sicherung die Datei zerstört... Hat jemand schon mal so was erlebt ?

Frage 2: Seht Ihr irgend eine Chance, die Datenbank zu "reparieren", um die verschwundenen aber nicht gelöschten Dokumente wieder zu kriegen ?
Fixup habe ich natürlich schon probiert....


Thanx
Tode

Edit: Server ist 7.0.2FP1 auf Windows 2003

[WernerMo]

Hallo,

Frage 1: Der Verdacht liegt natürlich nahe, dass die Sicherung die Datei zerstört... Hat jemand schon mal so was erlebt ?

Das hätte ich auch als erstes vermutet, wie sichert Symantec? mit einem eingen Notes-agent, oder über Filesystem? (kenne nur CA)

Gruß Werner

[eknori]

spontaner Gedanke: Aktualisiere mal das Design der Datenbank mit dem einer leeren Datenbank. Wenn die Docs noch da sind, dann sollten die sich auch dort zeigen. Danach das Design der Mailschablone drueberbuegeln.

[Tode]

@Werner: Der Notes- Agent sieht keine Datenbanken, was wohl ein bekanntes Problem ist, deshalb sichern wir -auf Empfehlung von Veritas- mittels OpenFileAgent, auch wenn mir persönlich das nicht wirklich passt...

@EKnori: Die Datenbank- Eigenschaften und auch ein "show database mail\user.nsf" zeigt, die Datenbank hat nur noch 40 Dokumente... In einem Windows- File- System würde ich sagen, da hats die FAT zerschossen...

Design- Update hat demzufolge auch nix gebracht.

Wir haben inzwischen einen neuen Anhaltspunkt: Scheinbar hat der Blackberry- Server genau zu dem Zeitpunkt versucht auf die Mailfile zuzugreifen, als diese gerade gesichert wurde... Eventuell hängt damit die Korruption zusammen...

Habt Ihr weitere Vorschläge (ausser den Server runterzufahren während man sichert, was wir jetzt erst mal machen, bis Veritas einen Patch rausbringt).

Tode

[MartinG]

  @Werner: Der Notes- Agent sieht keine Datenbanken, was wohl ein bekanntes Problem ist, deshalb sichern wir -auf Empfehlung von Veritas- mittels OpenFileAgent, auch wenn mir persönlich das nicht wirklich passt... 

Wir haben bei uns 6Jahre lang mit Veritas OpenFile Agent gesichert, und das ganze hat immer gut funktioniert, bis es dann auf einmal immer bei den zwei grössten Maildatenbanken Probleme gegeben hat (Job hatte diverse Fehlermeldungen). Wir haben dann den Backupjob aufgeteilt auf drei Jobs (restliche Datenbanken, Maildatenbanken Teil1 und Maildatenbanken Teil2) danach lief es immer wunderbar.

Seit knapp zwei Jahren sind wir allerdings auf den Notes Agent von Veritas umgestiegen (Version 10d inkl aller Servicepacks), und ich bin mit diesem sehr zufrieden. Was mich vor allem gewundert hat, dass die Speed nochmals deutlich zugelegt hat und dieser arbeitet -zumindest bei uns- astrein. Habe auch schon öfter eine Rücksicherung gemacht.

Hast Du schon in der Veritas KnowledgeBase geschaut? Diese ist wirklich absolut erstklassig...

[michael-r]

Zitat:
In einem Windows- File- System würde ich sagen, da hats die FAT zerschossen...

Ist aber kein Fat oder? Weder Client noch Server.

MFG Michael

[koehlerbv]

Wenn es auf OS-Ebene etwas zerstört hätte, würde Notes die DB als total defekt deklarieren und mit dem Ding gar nichts mehr machen. Das ist aber nicht der Fall: Die "Zerstörung" muss also "Notes-konform" verlaufen sein.
Insofern spricht also alles dafür, dass es ein Programm gemacht haben muss, dass "Notes kann", also der Domino selber, die Backup-Software (mein Favorit), der BES.

In praxi habe ich das aber noch niemals erlebt.

Bernhard

[hallo.dirk]

Eine Frage: Läuft noch irgendwann ein compact?

[Tode]

Danke für die vielen Anregungen.

Das mit der "FAT" war nur ein Beispiel, wie ich den Fehler übertragen auf einen anderen Kontext beschreiben würde: Es ist als ob die Zuordnungstabelle der Datenbank fehlen würde: Die Dokumente sind physikalisch noch da, aber die Zuordnung dazu ist verloren, sie können nicht mehr gefunden werden.

Die Datenbank ist also OS- seitig nicht zerstört, sondern tatsächlich irgendwie "inwendig corrupt".

Ein Compact läuft nicht, der Verdacht erhärtet sich aber, dass Blackberry die Korruption verursacht.

Im Moment fahren wir den Blackberry zur Sicherung runter und hatten seither keine Probleme mehr.

Wir haben übrigens den Notes- Agent installiert, aber wir sehen keine Notes- Datenbank auf dem Backup- Server. Dieses Problem ist beim Hersteller bekannt (an den haben wir uns natürlich auch schon gewendet) und wird vielleicht irgendwann mal gefixt...

Danke an alle...
Tode

[ossigo]

Hallo Tode,

wir haben immer mal wieder das gleiche Problem. Wir sichern mit BackUp Exec 9 und es ist bei uns die Sicherung, die schuld ist.
Ablauf bei Auftreten des Fehlers in etwa so:
- Sicherung startet
- log.nsf bzw. Event-Monitoring meldet bei einigen wenigen DB während des Sicherungslaufs: File is in use by another program (es werden z.B. versucht Mails zuzustellen oder Kalenderinformationen auszulesen für Gruppenkalender)
- dieser Vorgang verursacht einen Defekt in der Datenbank, Dokumente und Designelemente gehen in unbekannter Anzahl defekt
- die Einstellung/Aktivierung im Serverdokument --> Transaktionsprotokollierung --> "automatisches FixUp von beschädigten DB" bzw. der notes.ini Eintrag TRANSLOG_AutoFixup=1 löscht dann defekte Designelemente und viele Dokumente
- der Designertask korrigiert das Design wieder, dabei werden viele Designelemente hinzugefügt (Adding...) und nicht geupdated.

Ergebnis ist immer eine Datenbank, die für den Maileingang wieder funktioniert, weil Design wieder OK, aber nur noch einen Bruchteil der Dokumente enthält, aber noch die ursprüngliche große Größe hat. Reparaturversuche zwecklos, wenn Eigenschaften --> Datenbank sagt, dass da nur noch die wenigen Dokumente vorhanden sind, geht da auch nichts mehr. Wir können dann immer nur aus dem letzten BackUp wiederherstellen.

Wir haben mal eine Nacht die Einstellung "automatisches FixUp von beschädigten DB" abgeschaltet, nächsten Tag Chaos! Fünf Datenbanken waren defekt, aber etwas "anders". Diese DB tauchten nachts wieder während der Sicherungszeiten (paßte genau) im log auf mit dem Hinweisen (jeweils Mail-Routing-Ereignisse):
07.08.2007 23:42:03 Error delivering to Mailserver/Firma/DE mail\maildb; File is in use by another program
07.08.2007 23:43:12 Unable to open 'mail\maildb.nsf'. Skipping database: Recovery Manager: Database is damaged and requires Fixup -j or Media Recovery" (auch Verschiedene Ereignisse)
Diese Datenbanken waren dann mit einem einfachen fixup -J -F -O wieder zu korrigieren, aber eben mit der Zulassung Dokumente während des Fixups zu löschen. Wahrscheinlich wurden dabei sehr wenige defekte Dokumente gelöscht, sofort konnte man die DB wieder öffnen.

Der Notes-Agent brauchte keine Abhilfe bei uns.

Nach Aussage unseren externen Supports kann eine versuchte Mailzustellung während des Sicherungsvorgangs ausreichen, um diesen Defekt zu verursachen. Von Version 11 wurde uns seitens dieses Supports abgeraten, weil schlechte Erfahrungen gemacht wurden. Wir sind dabei eine Lösung zu finden...

Auf einem anderen Mailserver sichern wir mit CA Arcserve 11.5, hatten aber auch mit älteren Versionen nie Probleme.

Wir sind auf einem unserer Lotus-CRM-Server wegen der Sicherungsprobleme dazu übergegangen den entsprechenden Domino Server für die Zeit der Sicherung herunterzufahren und anschließend wieder zu starten, ging nicht anders, nachdem wir auch dort mal Probleme hatten.

Siehe auch:
http://atnotes.de/index.php?topic=34908.0

Jens

[Tode]

Das deckt sich ziemlich genau mit unseren Erfahrungen / Meldungen hier... Und ob jetzt eine Mail per Router zugestellt wird oder vom Blackberry dürfte dabei wahrscheinlich keine Rolle spielen.

Dann werde ich mal weiter beobachten... Danke für die Hinweise...

Tode