none
Hyper-V Cluster - Probleme beim Backup - VSS? RRS feed

  • Frage

  • Hallo Forum,

    ich betreibe einen 3 Knoten Hyper-V Failovercluster mit WIndows Enterprise 2008R2 SP1. Seit kurzem habe ich - aus dem Nichts - Probleme mit dem Backup meines File-Servers. Das Backup läuft über einen dedizierten physikalischen Server mit Backup Exec 2010 R3. Gesichert wird der komplette Cluster.

    Beim Fileserver (bestehen aus c:\ e:\ f:\) habe ich das Problem dass sobald das Backup angestoßen wurde, der Server nur noch "halb" da ist. Schwer zu erklären. Der Fileserver antworter auf Pings, und zeigt mit auch teilweise Freigaben von an, hier jedoch nicht alle Daten, es werden schlichtweg Ordner und Dateien nicht angezeigt. Ein Checkdisk innerhalb der VM auf dem betreffenden Volume scheitert mit "chkdsk kann keine RAW Dateisysteme prüfen". Wenn in der Zeit des Sicherungsversuchs neue Dateien auf dem File abgelegt werden funktioniert das scheinbar auch - ABER: Nach einem Neustart des File werden alle Dateien / ORdner wieder korrekt angezeigt, jedoch sind neue Daten NICHT mehr vorhanden. Checkdisk läuft dann ebenfalls Fehlerfrei durch.Innerhalb der VM habe ich diverse Fehler im Eventlog:

    Protokollname: System - Quelle: DIsk - ID: 51 - Text:

    Bei einem Auslagerungsvorgang wurde ein Fehler festgestellt. Betroffen ist Gerät \Device\Harddisk2\DR2.

    und: Protokollname: System - Quelle: NTFS - ID: 57 - Text:

    Die Daten konnten nicht in das Transaktionsprotokoll verschoben werden. Die Daten sind möglicherweise beschädigt.

    Protokollname: Anwendung - Quelle: VSS - ID: 40961 Text:

    ASR-Warnung: Fehler beim Sammeln von Datenträgerinformationen für die ASR-Sicherung.  Ursache:    Es können keine Datenträgerinformationen für Gerät "2" abgerufen werden (Win32-Fehlercode 0x2).

    Protkollname: Anwendung - Quelle: VSS - ID: 8193 - Text:

    Volumeschattenkopie-Dienstfehler: Beim Aufrufen von Routine "IVssAsrWriterBackup::GetAsrMetadata" ist ein unerwarteter Fehler aufgetreten. hr = 0x80042411, Auf einem Datenträger, für den keine Sicherung erstellt werden kann, befindet sich ein für die Sicherung ausgewähltes kritisches Volume.

    Vorgang:

       PrepareForBackup-Ereignis

    Kontext:

       Ausführungskontext: ASR Writer

       Ausführungskontext: Writer
       Generatorklassen-ID: {be000cbe-11fe-4426-9c58-531aa6355fc4}

       Generatorname: ASR Writer

       Generatorinstanz-ID: {45433485-b348-4567-bc9b-c9b10e4ec0fe}

    Fehlerspezifische Details:

       ASR Writer: Auf einem Datenträger, für den keine Sicherung erstellt werden kann, befindet sich ein für die Sicherung ausgewähltes kritisches Volume. (0x80042411)

    Protokollname: Anwendung - Quelle: VSS - ID: 12290 Text:

    Volumeschattenkopie-Dienstwarnung: ASR writer Error 0x80042411. hr = 0x00000000, Der Vorgang wurde erfolgreich beendet.

    Vorgang:

       PrepareForBackup-Ereignis

    Kontext:

       Ausführungskontext: ASR Writer

       Ausführungskontext: Writer

       Generatorklassen-ID: {be000cbe-11fe-4426-9c58-531aa6355fc4}

       Generatorname: ASR Writer

       Generatorinstanz-ID: {45433485-b348-4567-bc9b-c9b10e4ec0fe}

    Fehlerspezifische Details:

       ASR Writer: Auf einem Datenträger, für den keine Sicherung erstellt werden kann, befindet sich ein für die Sicherung ausgewähltes kritisches Volume. (0x80042411)

    Es ist dabei auch egal auf welchem Knoten der Fileserver ausgeführt wird, der Fehler tritt jedesmal auf wenn die gesamte VM gesichert werden soll. In Backup Exec erhalte ich die Meldung:

    Verfassername: Microsoft Hyper-V, Verfasserkennung: {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}, Letzter Fehler: Der VSS-Verfasser ist fehlgeschlagen, der Vorgang kann jedoch wiederholt werden (0x800423f3), Status: Warten auf eine Benachrichtigung über den Abschluss eines Backups (5).

    Ein checkdisk der VM sowie des CSV wo der Fileserver liegt habe ich bereits durchgeführt. Alle fehlerfrei durchgelaufen. Wo kann ich noch ansetzen? Die Sicherung hat seit Juli fehlerfrei funktioniert, und dann auf einmal nicht mehr. Und irgendwann bekomm ich das hier mit der Textformatierung auch noch hin :-)

    Montag, 26. März 2012 19:53

Alle Antworten

  • Hi Paul,

    zuerst ich habe keine Ahnung was da schieft läuft. Deswegen mal gefragt: sind von BackupExec Updates oder Fixe kurz vor den Fehlern installiert worden?


    Grüße/Regards Carsten Rachfahl | MVP Virtual Machine | MCT | MCITP | MCSA | CCA | Husband and Papa | www.hyper-v-server.de | First German Gold Virtualisation Kompetenz Partner ---- If my answer is helpful please mark it as answer or press the green arrow.

    Dienstag, 27. März 2012 21:28
    Moderator
  • Hallo Carsten,

    nein, es gab keine (wirklich) keine Veränderungen - weder Updates, noch Fixes, wirklich absolut keine Veränderung.....

    Mittwoch, 28. März 2012 20:02
  • Hallo Paul,

    verstehe ich es richtig das du den Fileserver "von außen" sicherst und nicht mit einem Agent innerhalb der VM?

    Gruß, Jan


    MCITP Windows Server 2008 R2 Virtualization Administrator, MCITP Server & Enterprise Administrator, MCITP Exchange 2010, Blogger @ technikblog.rachfahl.de ,Blogger @ www.hyper-v-server.de & DJ

    Freitag, 30. März 2012 14:12
    Moderator
  • Auf dem Hyper-V Host und innerhalb der VM ist der BackupExec Agent installiert.

    Ich habe mittlerweile aber eine Idee woranmein Problem liegen könnte.....  Die Datenpartiton des Fileservers (Laufwerk E: unf F: in der VM ) befinden sich zusammen auf einem CSV. Sobald das Backup startet erhalte ich auf den Hosts folgende Fehler:

    Quelle: Microsoft-Windows-FailoverCluster ID: 1038 Text: Dieser Knoten hat unerwartet die Besitzrechte für den Clusterdatenträger "File-DatenPart" verloren. Führen Sie den Konfigurationsüberprüfungs-Assistenten aus, um die Speicherkonfiguration zu prüfen.

    und

    ID: 1069 Text: Bei der Clusterressource "FileDatenPart" im geclusterten Dienst oder in der geclusterten Anwendung "adf8aa9d-ae89-4251-85c9-b6d96156485f" ein Fehler aufgetreten.

    Aber nur bei dem einen Clustershared-Volume

    Samstag, 31. März 2012 07:40
  • Hi,

    hast du evtl. ein Zuordnungsproblem bei den LUNs? Sind die LUNs in der VM direkt per iSCSI angebunden oder hast du die VHDs auf einem CSV liegen oder hast du die LUNs direkt als Festplatte angehangen (Physische Festplatte)? Der Fehler sieht danach aus als wenn der Backup-Agent Zugriff auf ein LUN will, das er eigentlich nicht besitzt. Jede LUN darf, wenn sie nicht als CSV eingebunden ist, nur einmal verbunden sein.

    Gruß, Jan


    MCITP Windows Server 2008 R2 Virtualization Administrator, MCITP Server & Enterprise Administrator, MCITP Exchange 2010, Blogger @ technikblog.rachfahl.de ,Blogger @ www.hyper-v-server.de & DJ

    Montag, 2. April 2012 07:40
    Moderator
  • Hallo,

    es handelt sich um ein CSV welches per SAS direkt angebunden ist.

    Ich habe insgesamt 7 Volumes (LUNs) auf meinem Storage erstellt, welche alle identisch eingerichtet sind, nur eben dieses eine verabschiedet sich sobald der gesamte Cluster gesichert werden soll.

    Montag, 2. April 2012 17:29
  • Hallo zusammen,

    ich habe ein ähnlichen Problem mit Hyper-V und BackupExec 2010 R3 SP2.

    Wir haben ein Hyper-V Cluster welches aus 4 physikalischen Knoten besteht, welche die LUNs von einer IPStor Lösung erhält.

    Nach der Einführung der Sicherung mit BackupExcec ist es so, dass eine LUN immer wieder nicht verfügbar ist und die VMs abschmieren.

    Dieses Phanomän tritt nicht nur zum Zeitpunkt eines Backups auf sondern auch im normalen Betrieb der Umgebung.

    Hat jemand von euch eine Idee wo das Problem her resultieren kann.

    Folgende Meldungen habe ich im Ereignislog des Clusters gefunden.

    ID: 5120 19:01 18.06.12

    Das freigegebene Clustervolume "DatastoreSAS" ("DatastoreSAS") ist auf dem Knoten aufgrund von "STATUS_CONNECTION_DISCONNECTED(c000020c)" nicht mehr verfügbar. Alle E/A-Aktivitäten werden vorübergehend in eine Warteschlange aufgenommen, bis wieder ein Pfad zum Volume eingerichtet ist.

    ID: 5242 20:06 Uhr 18.06.12

    Auf das freigegebene Clustervolume "DatastoreSAS" ("DatastoreSAS") kann aufgrund von Fehler "ERROR_TIMEOUT(1460)" nicht mehr von diesem Clusterknoten aus zugegriffen werden. Behandeln Sie das Verbindungsproblem zwischen diesem Knoten und dem Speichergerät sowie Probleme mit der Netzwerkverbindung

     Vielen Dank

    Christian

    Donnerstag, 21. Juni 2012 19:23