read only file system

Wenn du nicht das letzte Backup einspielen willst, dann musst du bei reicht SSD und diesem Dateisystem halt dir die Zeit nehmen.

fsck steht für file system crunch kill - das ist kein Datenrettungstool sondern ein Dateisystemzerstörer.

Wenn fsck anfängt Fragen zu stellen wird es haarig, da muss man im Prinzip sofort abbrechen und erstmal testen was da überhaupt passiert mit einem Snapshot, oder Copy-On-Write Overlay wie hier : https://raid.wiki.kernel.org/i…nly_using_an_overlay_file : oder ganz klassisch 1:1 Kopie ( unausweichlich bei Festplattenfehlern, erstmal ddrescue - man kann auf einer defekten Platte keine Dateisysteme reparieren )

Erst wenn man so ein Sicherheitsnetz hat, das alle Veränderungen jederzeit wieder rückgängig macht, kann man mal fsck drüberbügeln lassen. Und wenn das nicht klappt, muss man eben was anderes probieren (mit Backup-Superblocks, mit debugfs, zur Not mit photorec, ...). Darüber hinaus dreimal prüfen ob /dev/sda2 wirklich das richtige Gerät war und nicht noch LVM, RAID, oder sonstwas dazwischen.

Wenn du Pech hast, dann ist nach fsck das Dateisystem 100% OK aber auch 100% leer. Und von diesem Zustand kommst du nicht mehr weg, da fsck ja die ganze Zeit munter lustig (womöglich unter falschen Annahmen) auf die Festplatte geschrieben und alles irreversibel verändert hat. Und in einer Datenrettungssituation ist alles was man schreibt eben erstmal zusätzlicher Schaden...

Ich hab da leider auch keine Musterlösung für, sorry.

Viel Glück...

STRG+C drücken, im Rescue-System dann den Eintrag aus der fstab nehmen und später per Hand mounten. Oder direkt vom Rettungssystem drauf schauen. Idealerweise mit -o ro mounten.

Durch STRG+C kann natürlich noch mehr kaputt gehen, aber ob das jetzt von Relevanz ist...

akonopka: Sofern die Dimensionierung des neuen virtuellen Servers es zulässt, würde ich nach der Datenrettung anregen, je nach Nutzungsart des Plattenplatzes zumindest mittelfristig zu prüfen, inwieweit ein Umstieg auf ZFS möglich ist, um einen derartigen Vorfall in der Zukunft zu vermeiden. (Im Falle eines "managed servers" müssen entsprechende Kenntnisse auch auf Dienstleisterseite vorhanden sein; andererseits können sich Mehrkosten für eine entsprechendes Angebot in diesem Fall wirklich rentieren!)

Die Zugriffszeiten (aufgrund hierarchischer Prüfsummengeneration bei allen Schreibzugriffen) und der benötigte Plattenplatz werden steigen (mindestens 15%, besser 20% des Speicherplatzes müssen aus Leistungsgründen leer/reserviert bleiben), gegebenenfalls sogar deutlich – aber im schlimmsten Fall ist die Behebung von Fehlern drastisch besser/schneller möglich als bei allen anderen Dateisystemen, welche nicht über entsprechende Prüfsummen verfügen[*]. Von besonders wichtigen Dateien lassen sich sogar mehrere Kopien speichern, so dass auch "umkippende Bits" auf den Speichermedien deutlich an Schrecken verlieren (diese ZFS-Fähigkeit verwende ich selbst beispielsweise seit mehreren Jahren für mehrere 100.000 E-Mails). Und mit Momentaufnahmen (snapshots) lassen sich augenblicklich aktuelle Kopien von Datensätzen (datasets) anfertigen.

[*] (sofern der physikalische Zustand des Speichermediums und die Ursache des Problems dies zulassen – gegen Schadprogramme, welche mit Administratorrechten im Direktzugriff nennenswerte Teile der Platte überschreiben, hilft nur ein externes Backup mit aktuellen Daten)