Windows: Drive Snapshot und eine vermeintlich intakte Festplatte

Ein Kunde brachte seinen betagten Server zu uns, da dieser nicht mehr bootete. Neben einer eindeutigen Meldung vom RAID-Controller, das eine Festplatte an einem bestimmten Port ausgewechselt werden sollte kamen bei näherer Betrachtung weitere Punkte hinzu.

Der Server ist mit vier Festplatte zu je zwei RAID-1 bestückt. Der Kunde merkte zudem an, das er monatlich “chkdsk <LW:> /R laufen lässt, ohne das es bislang zu Fehlern gekommen sei.

Alle Platten wurden ausgebaut und an einem Werkstatt-Computer zunächst mittels CrystalDiskInfo überprüft. Dabei zeigten drei von vier Festplatten bereits S.M.A.R.T.-Warnungen an. Die vierte Festplatte sei angeblich in Ordnung. Interessanterweise, neben dem Umstand das der RAID-Controller die bereits eindeutig fehlerhaften Festplatten nicht monierte, war das ausgerechnet die vierte angeblich intakte Festplatte diejenige ist die beim Booten seitens des RAID-Controllers mit Port-Fehler “angemeckert” wurde.

Jedenfalls wurde von allen Festplatten mit Drive Snapshot eine Sicherung erstellt. Bei den Dreien mit den S.M.A.R.T.-Warnungen lief das ohne weiteres durch, es wurden keine fehlerhaften Sektoren im belegtem Speicherbereich erkannt. Bei der Vierten angeblich intakten Festplatte klappte die Sicherung zwar ebenfalls, allerdings fand sich im Protokoll folgendes:

20:02:20 2 sectors need more than 200ms to read
20:02:20 8 sectors need more than 100ms to read

So ganz in Ordnung ist also doch nicht. Lange Rede, kurzer Sinn: Alle Festplatten wurden ausgetauscht, die RAIDs neu aufgebaut und die Daten wiederhergestellt.

Schön zu sehen, einmal mehr, das Drive Snapshot auch in solchen Situationen nützliche Informationen liefert und einen dabei unterstützt herauszufinden was ggf. mit einer Festplatte los ist.

8 Kommentare

  • Pingback: The good & the bad with S.M.A.R.T. – Andy's Blog

  • Das einige Sektoren mehr als 100 / 200 ms zum Lesen brauchten habe ich bei mir ebenfalls regelmäßig im Log meiner täglichen Sicherung. Mal mehrere Einträge, an anderen Tagen auch mal gar keine.
    Diese Meldungen hatte ich allerdings von Anfang an auf meinem damals *neuen* Server, der zwei HDD’s als Raid1 betreibt. Fand ich schon immer beunruhigend, aber seit 2 Jahren läuft das System bisher ohne Probleme. %-)

    Vielleicht gibt es ja noch eine andere Erklärung für diese Meldungen von Drive Snapshot als sich ankündigende Hardware-Defekte…

  • Eine grundsätzliche Frage zu Drive Snapshot oder robocopy:
    Bei einem laufenden System wird meines Wissens ständig die Festplatte gelesen und beschrieben; auch dann, wenn wenn keine Anwendungen (bis auf Drive Snapshot oder robocopy) aktiv sind.
    Kann es sein, daß
    Wenn jetzt vom laufende System ein Abbild erstellt wird könnten doch ein inkonsistendes Abbild eintstehen oder wird dies von Drive Snapshot und robocopy berücksichtigt?

  • Dafür gibt es die Funktion der Schattenkopien (VSS) oder im Falle von Drive Snapshot hat man die Wahl entweder den integrierten Treiber oder VSS zu verwenden um ein konsistentes Abbild zu erstellen:

    Wikipedia – Volume Shadow Copy Service
    Drive Snapshot – VSS Volume Shadow Copy Service
    Windows: VSS-Fehler mit Drive Snapshot vermeiden

    Robocopy an sich kann kein VSS o.ä. das muss man mit weiteren Befehlen oder Tools dann umsetzen, siehe:

    Windows: Robocopy mit VSS (Schattenkopie)
    Windows: Kommandozeilen-Tools für das Erstellen und Nutzen von Schattenkopien

  • Könnte man denn nicht auf einen USB-Stick linux-Knopix installieren,
    den Rechner mit dem installierten Linux-Knopix hochlaufen lassen,
    dann mit den Linux-Comand “dd” eine gesamte Partition oder die gesamte Festplatte clonen.
    Auf diese Art könnte man doch das Problem, daß ein inkonsistendes Abbild beim Kopieren entsteht umgehen, VSS könnte man sich sparen.
    Spricht da was dagegen?

  • Klar, kann auch so machen. Das geht dann nicht im laufenden Betrieb (relevant wenn es um ein Backup geht). Extra Knoppix installieren braucht man nicht. Mit Ventoy den Stick bootfähig machen und ein Live-Linux.iso drauf kopiert. Geht natürlich auch mit WinPE-basierten Systemen wie heiße c’t Notfall-Windows und Co.

  • Wie oben beshrieben habe ich meinen Laptop über einen USB-Stick mit Knoppix gestartet,
    über einen USB-Port und eine SATA Docking Station habe ich eine zweite SSD mit einer Speicherkapazität von 2TB angesteckt.
    Mit dem Linux-Befehl
    sudo dd if=/dev/sda of=/dev/sdc bs=1M status=progress
    habe ich dann den Inhalt der eingebauten SSD /dev/sda nach der externen SSD /dev/sdc kopiert.
    Bei der internen SSD /dev/sda war neben win 10 zusätzlich SUSE-Linux installiert,
    beim Start konnte ich mit dem boot-Manager GRUB zwischen Win 10 und Linux wählen

    Nach Beendigung des Kopiervorgangs habe ich die alte SSD mit der neuen 2 TByte SSD getauscht, der Rechner lief mit der größeren SSD problemlos.

    Da die neue SSD gegenüber der alten eine erheblich größere Speicherkapazität hat wurde in der Datenträgerverwaltung ein großer “Nicht zugeordneter Bereich” angezeigt.
    Ich wollte dann vom “nicht zugeordneten Bereich” 100 GB nutzen und habe den Block mit NTFS formatiert.
    Der nachfolgende Start hat dann nicht mehr geklappt, es kam folgende Meldung:

    Welcome to GRUB
    error not a Btrfs filesystem
    error unknow filesystem
    Entering rescue mode
    grub rescue

    Die Rettung des GRUB-Bootloaders hat allerdings nicht geklappt,
    ich habe daher wieder die alte SSD eingebaut und mit KNOPPIX den Inhalt der alten SSD über die SATA Docking Station nochmals auf die neue SSD übertragen.

    Meine Frage: Wie kann ich nach den Einbau der neuen SSD den nicht zugeordneter Bereich nutzen, was muß ich bei der Formatierung beachten?
    Soll ich evtl Linux und den Bootloader GRUB komplett löschen und dann Linux neu installieren?

    Im voraus vielen Dank für die Beantwortung.

  • Zu Grub und Multiboot kann ich nichts sagen. Zur Verwendung des ungenutzten Speichers würde ich eher zu einem Windows-Boot-Stick und MiniTool Partition Wizard oder GParted Live greifen, denn die Windows-Bordmittel funktionieren diesbezüglich nur, wenn hinter der C-Partition keine weiteren (teils versteckten) Partitionen mehr sind (die Datenträgerverwaltung zeigt das nicht unbedingt an und via diskpart ist das mitunter zu “fummelig”).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.