Hi Timothy, Am Fr 2.September 2005 09:16 schrieb Timothy Kesten:
Bevor der zuständige Mitarbeiter Abends sein Büro verläßt ruft er ein Programm zum Backup auf. Dabei werden per afio die Daten auf dem Server komprimiert und anschließend mit growisofs auf eine DVD-RW gebrannt. Das klappt auch zu 90%. Zu beachten ist, dass während dieses Vorgangs diverse Dateien durchaus noch geöffnet sein können. Zum Beispiel die Outlook-Pst Dateien, die auf dem Server gelagert sind.
Für Lookout gibt es ein plugin was selbstständig (beim Schliessen) nach n Tagen eine Sicherung anlegen kann, damit umgeht man auch das Problem das der Zugriff von x Leuten auf jeweils dieses File die Netzwerkperformance versaut (sofern die mails dort lagern). Wenn dann was ist fehlt maximal der Tag im pst dieses MA. Zusammen mit einer imap Lösung idr. völlig ausreichend. Wo das plugin her ist weis ich nimmer, mglw. direkt von M$. Was gibt es noch was eine sicherung um 0:00 verhindert?
Manchmal nun passiert des, das der Rechner sich beim abarbeiten von afio, also beim Komprimieren (nicht beim Brennen) sich komplett verabschiedet. Nichts geht mehr. Nur noch Kaltstart. Kann das an o.g. Verfahren liegen? Oder könnte es etwas anderes sein. Wo, also in welcher Log-Datei könnte ich Informationen auslesen. In /var/log/messages steht nichts Verwertbares. Oder ist eher ein Hardwarefehler (Platte) zu vermuten? Wenn ja, wie könnte ich das überprüfen?
Wenn ein Rechner sowas macht liegt es nach meiner Beobachtung zu 80% an der Hardware (RAM - defekt oder gerne auch einfach nur zuwenig davon, Festplatte(n), Board, Kühlung) und zu 20% am Kernel, es gibt ab und an mal Exemplare die auf bestimmten Rechnern sowas machen. zb. hab ich eine Büchse mit 4 XEONs für die ich ein 4tel Jahr lang immer wieder den neuesten 2.4er Kern mit minimalkonfig getestet habe bis sie stabil war, jetzt läuft sie seit 2,5 Jahren ohne Probleme. Sowas ähnliches hatte ich auch mal in Verbindung mit tapeware, da war es dann das Board. Latente Plattenfehler tauchen nahezu immer auch im normalen Betrieb auf (Drive seek error in der/var/log/messages), Board und RAM Fehler verhindern leider viel zu oft das man in der messages oder der warn noch irgend welche Spuren davon findet. Meine Empfehlung deshalb immer zuerst überlegen wann genau passiert es? Wie warm war es da? Dann in der messages nachschauen ob da was verdächtiges steht, wenn nicht dann schauen ob ein aktueller vanilla kernel aus der gleichen serie einsetzbar ist und den testen, wenn das zum gleichen Ergebnis führt anfangen mit anderem/mehr RAM zu probieren und zum Schluss kurzerhand das Board ersetzen. Das Ganze ist sehr zeitaufwändig und daher ein nebenbei job mitunter muss man ja wochenlang auf den Fehler warten.
Was das Backup angeht ist mir schon klar, dass ein Sichern um Mitternacht, wenn also niemand arbeitet, besser wäre. Aber dann fehlt immer ein ganzer Arbeitstag, wenn genau in dieser Nacht was passiert.
was ist an einem abgestürzten Backup um 17:00 besser? oder versteh ich dich einfach net? Gruss Falk