Skip to content
 

Wie wir uns von einem Festplattenausfall erholt haben

Gentlents praxisorientierter Ansatz zur Bewältigung eines Festplattenausfalls in unserer Serverkonfiguration. Dieser Beitrag behandelt die Schritte, die wir unternommen haben, um das Problem zu identifizieren, zu beheben und unser System zu aktualisieren, um zukünftige Probleme zu vermeiden, ohne unsere Kunden zu beeinträchtigen.

Tom Kleinvon Tom Klein · 4 min Lesezeit
Gentlents praxisorientierter Ansatz zur Bewältigung eines Festplattenausfalls in unserer Serverkonfiguration. Dieser Beitrag behandelt die Schritte, die wir unternommen haben, um das Problem zu identifizieren, zu beheben und unser System zu aktualisieren, um zukünftige Probleme zu vermeiden, ohne unsere Kunden zu beeinträchtigen.
Gentlents praxisorientierter Ansatz zur Bewältigung eines Festplattenausfalls in unserer Serverkonfiguration. Dieser Beitrag behandelt die Schritte, die wir unternommen haben, um das Problem zu identifizieren, zu beheben und unser System zu aktualisieren, um zukünftige Probleme zu vermeiden, ohne unsere Kunden zu beeinträchtigen.
 

Während einer routinemäßigen Serverüberprüfung vor einigen Tagen bemerkten wir ein beunruhigendes Muster: Eine unserer Festplatten war zum zweiten Mal in einem Monat aus dem RAID-Array herausgefallen. Es wurde klar, dass diese Festplatte ausfiel, was den kleinen RAID-Array des Servers in einen degradierten Zustand versetzt hatte.

Das Potenzial für Datenverlust oder Ausfallzeiten in solchen Situationen ist eine Sorge für jedes IT-Team. Jedoch haben wir schon immer die Datenintegrität und Systemzuverlässigkeit priorisiert. Dank unserer regelmäßigen, sicheren Backup-Protokolle und Echtzeit-Replikation für Kerndatenbanken waren wir vorbereitet. Dieser Ansatz stellte sicher, dass selbst mit dem Risiko für den Server unsere Operationen ohne Unterbrechungen fortgesetzt werden konnten und, was noch wichtiger ist, ohne das Risiko von Kundendaten.

Als wir das Problem erkannten, verschwendeten wir keine Zeit. Wir beschafften schnell zusätzliche SSDs und begannen mit dem Upgrade der RAID-Arrays auf unseren Maschinen. Der Upgrade-Prozess verlief reibungslos für den zweiten Server, den wir nur zur Sicherheit aufrüsteten, aber wir stießen auf ein Problem mit dem ersten: Seine Boot-Partition befand sich auf der fehlerhaften Festplatte.


Die Lösung

Die Behebung dieses Problems erforderte einen praktischen Ansatz. Wir begaben uns vor Ort, ersetzten die problematische Festplatte und konfigurierten das RAID-Array neu. Dieser Prozess dauerte einige Stunden, aber am Ende lief der Server wieder normal, als wäre nichts geschehen.

Als wir die fehlerhafte Festplatte identifizierten, lag unser unmittelbarer Fokus darauf, die Integrität unseres RAID-Arrays sicherzustellen und die volle Funktionalität wiederherzustellen. Hier ist ein kurzer Überblick über die technischen Schritte, die wir unternommen haben:


1. Das Problem Identifizieren

Zuerst verwendeten wir mdadm, um den Status unserer RAID-Arrays zu untersuchen:

sudo mdadm --detail /dev/md0

Dieser Befehl half uns zu bestätigen, welche Festplatte ausfiel. Beim Versuch, sie wieder zum Software-RAID-Array hinzuzufügen, bemerkten wir einen signifikanten Abfall der Schreibgeschwindigkeit in Echtzeit.


2. Von Live-Image Booten - Der Ubuntu Weg

Unser erstes Hindernis bestand darin, Zugang zum Dateisystem des Servers zu erhalten, ohne von der kompromittierten Festplatte zu booten. Dies erreichten wir mithilfe eines Live-Ubuntu-Server-ISOs, was ziemlich unkompliziert ist:

  1. Live-Medien Vorbereiten: Wir luden das Ubuntu-Server-ISO herunter und erstellten ein bootfähiges USB-Laufwerk.
  2. In Live-Umgebung Booten: Wir steckten das USB-Laufwerk ein und starteten den Server neu. Während des Boot-Vorgangs wählten wir das USB-Laufwerk als Boot-Gerät aus.
  3. Shell der Live-Session Eingeben: Sobald die Ubuntu-Server-Live-Installation geladen war, klickten wir auf die Schaltfläche "Hilfe" oben rechts auf dem Bildschirm und wählten "Shell eingeben", um auf ein Terminal zuzugreifen, ohne das Image tatsächlich zu installieren.
  4. Die Notwendigen Dateisysteme Mounten: Befehle wie mount und chroot wurden durch diese Anleitung verwendet, um auf das Dateisystem des Servers zuzugreifen. Dies ermöglichte es uns, Änderungen an der Serverkonfiguration und dem RAID-Array vorzunehmen. Diese Befehle könnten so aussehen:
    for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
    sudo chroot /mnt


3. Die Neue Festplatte Vorbereiten

Mit Zugang zu einer Shell gingen wir dazu über, die neue Festplatte für die Integration in das RAID-Array vorzubereiten:

  1. Die Neue Festplatte Identifizieren: Wir benutzten lsblk, um alle Blockgeräte aufzulisten und die neue Festplatte zu identifizieren.
  2. Die Neue Festplatte Partitionieren: Mithilfe von fdisk auf der neuen Festplatte (/dev/sdX) erstellten wir eine neue Partitionstabelle und Partitionen, die denen der vorhandenen RAID-Festplatte(n) entsprechen.
    sudo fdisk /dev/sdX


4. Die Festplatte in das RAID-Array Integrieren

Mit der partitionierten Festplatte war der nächste Schritt, sie in das RAID-Array zu integrieren:

  1. Die Neue Partition dem RAID Hinzufügen: Wir benutzten mdadm, um die neue Partition dem bestehenden RAID-Array hinzuzufügen.
    sudo mdadm --manage /dev/md0 --add /dev/sdX1
  2. Den RAID-Wiederaufbau Überwachen: Wir behielten den Wiederaufbauprozess im Auge, um sicherzustellen, dass er ohne Probleme voranschritt.
    cat /proc/mdstat


5. Die Boot-Partition Ansprechen

Das Fehlen der Boot-Partition auf der überlebenden Festplatte war ein kritisches Problem, das wir lösen mussten:

  1. Erstellen einer Neuen EFI-Partition: Wir benutzten fdisk, um eine neue EFI-Systempartition auf der überlebenden Festplatte zu erstellen.
    sudo fdisk /dev/sdY
  2. Formatieren der EFI-Partition: Als Nächstes formatierten wir die neue EFI-Partition als FAT32.
    sudo mkfs.vfat -F 32 /dev/sdY1
  3. EFI-Partition Mounten: Wir mounteten die neue EFI-Partition auf /mnt/efi.
    sudo mount /dev/sdY1 /mnt/efi
  4. GRUB Neuinstallieren: Wir installierten GRUB auf der EFI-Partition neu, um die Boot-Funktionalität wiederherzustellen.
    sudo grub-install --target=x86_64-efi --efi-directory=/mnt/efi --bootloader-id=Ubuntu


6. fstab Aktualisieren

Der letzte Schritt bestand darin sicherzustellen, dass das System die neue EFI-Partition beim Booten automatisch mounten konnte:

  1. UUID der Neuen EFI-Partition Finden: Wir verwendeten blkid zur Ermittlung der UUID.
    blkid /dev/sdY1
  2. /etc/fstab Bearbeiten: Wir fügten eine neue Zeile für die EFI-Partition unter Verwendung der von blkid erhaltenen UUID hinzu.
    UUID=<new-efi-partition-uuid> /boot/efi vfat umask=0077 0 1


7. Die Wiederherstellung Überprüfen

Nach Abschluss dieser Schritte starteten wir den Server neu, um zu überprüfen, ob die Wiederherstellung erfolgreich war. Das System startete normal und alle RAID-Arrays funktionierten wie erwartet.


Naherzu Nahtloser Service

Während dieser ganzen Angelegenheit war unser Hauptanliegen, die Service-Kontinuität für unsere Kunden aufrechtzuerhalten. Dank unserer präventiven Maßnahmen und schnellen Reaktion gelang es uns genau das zu tun. Keine Kundendaten waren gefährdet und unsere Services blieben online und voll funktionsfähig.

Angesichts dieser Herausforderung wurde uns die Bedeutung regelmäßiger Systemüberprüfungen, zuverlässiger Backup-Strategien und der Fähigkeit, schnell auf unvorhergesehene Probleme zu reagieren, erneut bewusst. Es sind diese Praktiken, die uns helfen, unser Versprechen eines zuverlässigen Service gegenüber unseren Kunden zu halten.


Artikel teilen


Tom Klein
Founder & CEO
Gentlent UG (haftungsbeschränkt)

Gentlent
Kundendienst
support@gentlent.com



Aktuelle Artikel

Sie wollen mehr erfahren?
Kontaktieren Sie uns noch heute.

 
GentlentEine offizielle Gentlent Website. Offizielle Gentlent Websites sind immer von unserer Website gentlent.com verlinkt oder enthalten ein erweitertes validiertes Zertifikat.
Skyline Dusseldorf