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.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
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”).