Jump to content

Fantafisch

Members
  • Gesamte Inhalte

    98
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Fantafisch

  1. Hi nochmal,

     

    Da war doch mal was mit HDD´s einer gewissen Serie die getauscht werden sollten...

     

    Vielleicht find ich das Dokument noch.

     

    Da ging´s soweit ich mich erinnern kann darum das eine sehr kleine Anzahl an HDD`s Probleme verursacht und durch andere ersetzt werden sollten.

     

    Oder eventuell ein Disk FW Problem.

     

    lg

     

    Fantafisch

  2. Hi,

     

    Das klingt ja sehr schlimm... :confused:

     

    Wie sind den die Server SCSI mäßig verkabelt. Single BUS oder Split BUS?

     

    Mit welchen FW Ständen hast du das beobachtet?

     

    Schon mal das Array Diagnostic Utility angeworfen? Vielleicht kannst ja dort was über eventuelle SCSI Fehler rauslesen.

     

    Ansonsten kenn ich sowas nur von einem einzigen Server auf dem die Backplane defekt war. Vielleicht ne kaputte Serie?

     

    Wie fährt der Server leicht runter? Blue Screen und ASR oder wird der korrekt runtergefahren?

     

    lg

     

    Fantafisch

  3. Hi nochmals,

     

    Ja das ist schön und gut was Ihr damals auf meine Anfrage geantwortet habt.

     

    Es geht aber konkret darum das die falsche Zeit angezeigt wird wenn man nicht eingeloggt ist.

     

    Das man die Sommerzeit/Winterzeit im Profil einstellen kann ist mir schon klar. Es geht aber um die Zeit wenn man NICHT eingeloggt ist.

     

    Ich bin mir sicher das nicht alle Besucher des Boards immer eingeloggt sind bzw. einige vermutlich gar keinen Account besitzen und da macht die falsche Zeit halt einen komischen Eindruck.

     

    lg

     

    Fantafisch

  4. Hi nochmals,

     

    Aus irgendeinem Grund hat er mir grade vorher auf allen Seiten angezeigt das wir WEZ +2 haben. Nach dem einloggen hat es aber wieder gepasst.

     

    Nachtrag:

     

    Interessant. Wenn man nicht eingeloggt ist kommt WEZ +2 ???

     

    lg

     

    Fantafisch

  5. Hi,

     

    Bitte mich zu korrigieren falls ich falsch liege.

     

    Ich hatte das ganze so in Erinnerung:

     

    Variante 1:

     

    Backup Exec Komplettsicherung inkl. System State. Server tot. Neuinstallation OS. Installation Backup Exec Client. Komplettrücksicherung über das bestehende neu installierte OS drüber.

     

    Variante 2:

     

    Backup Exec Komplettsicherung mit zusätzlicher IDR Option. IDR Medien müssen nach jeder Sicherung passend abgelegt werden. Server tot. Einlegen der IDR CD. Starten des Servers. Komplettrücksicherung des Servers.

     

    So glaub ich war das...

     

    lg

     

    Fantafisch

  6. Hi,

     

    Also zu 1,

     

    Wäre mir neu das man für´s rebuilden einen extra Treiber benötigt?

     

    Klingt irgendwie für mich nach Unsinn. Entweder die Hardware (also der Controller) kümmert sich um das rebuilden dann sind die Rebiuld Funktionalitäten in der Firmware implementiert oder man macht ein Software RAID per Windows. Dann braucht´s aber auch keinen Treiber.

     

    Sollte hier tatsächlich ein Treiber notwendig sein dann dürfte sich ja das RAID garn nicht ohne Treiber erstellen lassen.

     

    Zu 2,

     

    Ja das kann vorkommen und ist eigentlich gar nicht mal so selten wie immer angenommen. Ich hatte den Fall erst Gottseidank einmal.

     

    Besonders bei HDD´s aus der selben Charge kann es schon vorkommen das diese dann "gemeinsam" oder in kurzen Abständen den Geist aufgeben.

     

    Es gibt da auch Berechnungen z.B. das ab einer bestimmten Anzahl an HDD´s ein Multi HDD´s Ausfall immer wahrscheinlicher wird.

     

    Siehe hier:

     

    http://docs.hp.com/en/J6369-90011/apcs01.html?btnPrev=%AB%A0prev

     

    Deshalb gibt´s hier verschiedene Möglichkeiten z.B: Online Spare Platten die sofort einspringen wenn eine andere Ausfällt und mit dem Rebuilden beginnt oder RAID ADG das den gleichzeitigen Ausfall von 2 HDD´s verkraftet.

     

    Und nochwas: So schmal ist die Zeitspanne die das Rebuild nicht benötigt. Im Extrmfall kann es sein das bei sehr hoher Auslastung und je nach Controller das Rebuild nicht mehr als 1 GB pro Stunde schafft.

     

    Mein Rekord liegt hier bei ca. 48 Stunden für ca. 70 GB Daten.

     

     

     

    lg

     

    Fantafisch

  7. Hi Data1701;

     

    Sorry das von vorher war nicht böse gegen Dich gemeint. Ich wollte einfach nur damit sagen das man die Vorschläge und Lösungen die ein Hersteller bietet nicht immer nur einfach so hinnehmen soll.

     

    Es geht mir darum das man sich einfach mit dem ganzen kritisch auseinandersetzt und sich ein Bild davon macht ob ein gewisser Lösungsweg überhaupt so Sinn macht und nicht vielleicht andere Probleme aufwirft.

     

    Meiner Meinung nach muß hier vom Hersteller eine klare Anweisung erfolgen. Entweder es ist auch technischer Natur einen Reboot durchzuführen oder eben nicht. Es würde die Sache sicherlich einfacher machen wenn Veritas zum Beispiel erklären würde warum hier der Reboot empfohlen wird. Vielleicht sind es ja wirklich Files die deswegen nicht gelöscht werden und erst durch einen Reboot freigegeben werden. Das könnte man dann aber ja auch mitteilen.

     

    So sieht die Sache natürlich nicht so toll aus den auf der einen Seite kann ich meinen Kunden mitteilen das aus technischer Sicht nichts dagegenspricht keinen Reboot durchzuführen andererseits sollte der Reboot trotzdem erfolgen und das kann ich mangels weiterer Informationen gegenüber dem Kunden nicht begründen.

     

    Vermutlich kann hier wirklich mit einer Case Eröffnung Licht in die Angelegenheit gebracht werden.

     

    Nochmals kurz zu dem BITS "Problem". Also ich für meinen Teil füge lieber einen Eintrag bezüglich einer Ausnahme des Ordners am Backup Server per Selection List hinzu als das ich den REG Key auf alle Server verteilen muß.

     

    Zumal wenn ich das noch richtig in Erinnerung habe werden Keys die man unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet setzt erst beim nächsten Reboot vom OS berücksichtigt. Oder?

     

    lg

     

    Fantafisch

  8. Ja den Artikel kenn ich.

     

    Aber es gibt Kunden da ist kein Reboot möglich (Server läuft schon mal 6-9 Monate durchgehend) und da funktioniert es ohne Probleme. Auch von 10 retour zu 9.1. Aheb auch das gleiche bei uns in der Firma ohne Reboot im Einsatz.

     

    Ich frage mich wenn kein Reboot technisch notwendig ist wozu dann Veritas einen Reboot überhaupt empfiehlt?

     

    Wir haben ungefähr 40 verschiedene Veritas Backup Exec Installationen bei Kunden im Einsatz und bei keiner einzigen habe ich bis jetzt einen Reboot benötigt und man sollte ja bekannterweise bei (fast) jedem Hotfix bzw. Service Pack ALLE Remote Agents updaten.

     

    Außerdem gibt die Veritas Knowledge Base meiner Meinung nicht immer Sinnvolle Vorschläge.

     

    Konkret es um das Beispiel da die Datei qmgr0.dat und qmgr1.dat vom BITS (Background Intelligent Transfer Service) während eines Backups gelockt sind. Backup Exec kann daher die Dateien nicht sichern und bringt eine Fehlermeldung. Diese beiden Dateien sind aber für ein Restore nicht notwendig.

     

    Der von Veritas vorgeschlagene Weg ist daher den Ordner in dem sich die Dateien befinden über einen Registry Key auszunehmen.

     

    http://seer.support.veritas.com/docs/269411.htm

     

    Wird jetzt zum Beispiel das Backup von jemand anderem übernommen da sieht er normalerweise in den Selection Lists nach was im Backup alles drinnen ist auch die Ausnahmen. Wenn man sich hier an den offiziellen Veritas Weg hält über den Registry Key dann hat man keine Möglichkeit über die Selection Lists zu sehen was hier ausgenommen wurde.

     

    Eine Ausnahme bezüglich des Ordners hingegen in den Selection Lists hinzuzufügen hat das gleiche technische Ergebniss und ist für alle sofort nachvollziehbar und nicht irgendwo über die Registry verstreut.

     

    Meiner Meinung nach ist der offizielle Veritas Weg hier nur beschränkt sinnvoll.

     

    Das selbe gilt meiner Meinung nach für den Reboot bei den Remote Agents. Entweder ich brauch den Reboot oder nicht. Den das Statement von Veritas lautet ja in dem Fall eigentlich brauchst du keinen Reboot es wäre aber besser du machst einen.

     

    Da klingt für mich so ungefähr als wenn eine Frau sagt ich bin einen bißchen Schwanger.

     

     

    lg

     

    Fantafisch

  9. Hallo,

     

    Start mal einen der "verdächtigen" Rechner im Abgesicherten Modus mit Netzwerktreibern und Besuch mal nacheinander die folgenden Links:

     

    http://www.bitdefender.com --> links unten auf den Scan Online Button klicken

    http://www.pandasoftware.com/products/activescan/com/activescan_principal.htm

    http://support.f-secure.com/enu/home/ols.shtml

     

    Schau mal ob die einzelnen Online Scanner was verdächtiges entdecken.

     

    lg

     

    Fantafisch

  10. Nochmals zur HP Insight Agents Problematik:

     

    Das Problem besteht mit der entgültigen Version von SP1 weiterhin.

     

    Die Agents 7.11 (wurde nur für diesen Bug erstellt) und die Agents 7.20 beheben das Problem.

     

    Somit sind als Minimum die Agents der Ver. 7.11 auf einem Proliant Server mit SP 1 zu verwenden.

     

    lg

     

    Fantafisch

×
×
  • Neu erstellen...