[gelöst] Partition aus Image wiederherstellen

[OsunSeyi]

Hi,
sitze hier vor meinem Laptop, Festplatte ist verreckt und ich habe nun eine neue eingebaut.
Die alte Xfs-formatierte Systempartition (Salix) ist in eine Iso-Datei gesichert worden und diese lässt sich auch problemlos mit 'mount -o nouuid SALIX-19-05-28.img $PWD/ISO' einhängen.

Die neue Partition ist in etwa mit der selben Größe wie die alte mit Xfs formatiert worden.

Kann ich die Daten einfach aus dem gemounteten Iso in die neue Partition kopieren, oder muss ich dafür spezielle Optionen für 'ls' verwenden? Muss evtl. mit 'dd' kopiert werden?

viele grüße, tom

 

[josef-wien]

Systempartition (Salix) ist in eine Iso-Datei gesichert

Auf welchem Weg ist das passiert? Systempartitionen zeichnen sich unter anderem dadurch aus, daß bestimmte Verzeichnisse und Dateien bestimmte Berechtigungen aufweisen müssen und daß es jede Menge hardlinks gibt. Wenn die Berechtigungen nicht passen, brauchst Du mit einer Wiederherstellung gar nicht erst anzufangen. Wenn die hardlinks nicht berücksichtigt wurden, gibt es "nur" eine wundersame Datenvermehrung.

rsync -AHPSXavx --delete /einhängepunkt/iso/ /einhängepunkt/neue_systempartition/

 

[OsunSeyi]

Das ist mit 'Pudd' geschehen, einem Puppy-Linux Tool zum Sichern von Partitionen in ein komprimiertes Iso. Dazu wird 'dd' verwendet, mit welchen Optionen ist mir aber nicht bekannt!

 

[josef-wien]

dd kopiert die Partition vom ersten bis zum letzten Bit (und kümmert sich nicht um Verzeichnisse und Dateien). Wenn Du beim Wiederherstellen mit dd eine kleinere Zielpartition hast, bekommst Du beträchtliche Probleme.

Siehe auch: https://linux-club.de/wiki/opensuse/Dd#dd_auf_Partitionen_und_ganze_Festplatten_anwenden
https://linux-club.de/wiki/opensuse/Dd#einzelne_Partitionen_und_ganze_Platten_mit_dd

 

[OsunSeyi]

Die Ausgangspartition (aus der das Iso gemacht wurde) hat 14,65 GiB und die neu angelegte 14,66 GiB laut GParted.

one[SALIX]$ sudo dd if=/run/media/one/ssd/BAK/SALIX/SALIX-19-05-28.img of=/dev/sda1 bs=8K

1920767+1 Datensätze ein
1920767+1 Datensätze aus
15734928384 bytes (16 GB, 15 GiB) copied, 458,94 s, 34,3 MB/s

"bs=8k" ist geraten aus dem Linupedia-Artikel übernommen.

Pfad-zu-"if" (Iso) natürlich gemountet,
"if" und "of" beide nicht gemountet.

Wohin 'dd' kopiert hat, weiß ich nicht. '/dev/sda1' ist jedenfalls leer geblieben...
Wie kann das denn sein?

EDIT:

Habe "of" '/dev/sda1' nochmals formatiert und 'dd' ohne die Option "bs=8k" wiederholt.
Diesmal sind die Daten auf sda1 gelandet. Eine anschließende Dateisystemprüfung und Reparatur mit GPartet führt zu meinem großen Ärgernis zu über 600 Dateien (53,6 MB) in "lost+found".

Damit als System weiterarbeiten zu wollen, kann ich wohl vergessen.
Der erste Schritt wäre jetzt wohl, das Iso zu überprüfen... frage nur wie...

Auffallend ist, daß die Schnipsel (überwiegend oder alle?) offenbar aus einer Abiword-Datei stammen.
Abiword hat auf Salix immer genervt wegen Absturz mit der Meldung "Schreibfehler".
Möglicherweise ist also das System nicht korrupt, sondern es sind Reste von Abiword-Schreibversuchen. Aber gleich 54 MB??

Wollte nun aber testen, ob ich das System trotzdem hochfahren kann:

Ebenfalls nicht geglückt ist es, Lilo in den Bootsektor zu schreiben.
Habe die alte lilo.conf in das laufende Life-System übernommen, die Laufwerksbezeichnungen sind korrekt, und Lilo ausgeführt:

# gekürzt:

	lba32
	boot = /dev/sda

# (weitere Angaben vga usw)

	  image    = /boot/vmlinuz
	  root     = /dev/sda1
	  label    = SALIX
          append   = "quiet  vt.default_utf8=1"
	  read-only

sudo lilo
Fatal: Trying to map files from unnamed device 0x0011 (NFS/RAID mirror down ?)

 

[towo]

1. das ist kein ISO, sondern einfach ein dd Image
2. wenn da irgendwas komprimiert wurde, muss das beim rückschreiben natürlich auch dekomprimiert werden
3. das Image sollte tunlichst nicht gemountet sein, wenn man es perr dd zurückschreiben will.
4. ein Image einer Partition ist relativ sinnfrei, da man hier ganz schnell ein Problem mit einer gültigen Partitionstabelle hat.

 

[OsunSeyi]

Die Punkte 2-3 sind wie beschrieben.
Frage zu Punkt 3:

ein Image einer Partition ist relativ sinnfrei, da man hier ganz schnell ein Problem mit einer gültigen Partitionstabelle haben

Bedeutet das, daß ich das System aus dem dd-Image nicht wieder herstellen kann?

 

[Gräfin Klara]

Bedeutet das, daß ich das System aus dem dd-Image nicht wieder herstellen kann?

Das bedeutet es nicht unbedingt aber mit dd wirst du keinen Erfolg haben.
Mounte dein image, untersuche es, beschäftige dich mit "find -xtype", prüfe alle toten Links und
entferne alles aus den mountpoints mit speziellen Filesystemen .. sofern vorhanden.
Formatiere sda1 nocheinmal und lies den Beitrag von @josef-wien über rsync.
Leider ignorierst du seine Erklärungen, die dir eine Chance zur Wiederherstellung zeigen.

 

[josef-wien]

War die Systempartition fehlerfrei und ausgehängt, als Du die Image-Datei erzeugt hast? Wenn zumindest eine dieser Voraussetzungen nicht erfüllt war, wundert mich ein defektes Dateisystem nicht. In diesem Fall solltest Du zuerst eine Kopie der Image-Datei erzeugen. Mit dieser Kopie arbeitest Du dann, d. h. Du führst zuerst eine Dateisystemprüfung durch (und das nicht mit irgendwelchen grafischen Programmen, von denen man nicht weiß, was sie tun, sondern mit Konsolbefehlen, zu denen ich bei xfs nichts beitragen kann).

P. S. Bei einer primären Partition teile ich die Bedenken von towo nicht. Eine Erfolglosigkeit von dd sehe ich auch nicht (auch wenn ich mich nicht mit Behältern, sondern mit deren Inhalt befasse).

 

[OsunSeyi]

Die Systempartition war nicht gemountet, da bin ich mir schon sicher, weil Pudd sonst nicht anfängt. Ob sie auch fehlerfrei war, kann ich nur vermuten. Zu dem Zeitpunkt, als das Image erzeugt wurde, hat das System vollkommen fehlerfrei gearbeitet. Ich würde annehmen, das Journal recovering ggF im Verlauf des Bootvorganges "on the fly" vorgenommen werden, und darum von einem konsistenten System ausgegangen werden kann (hätte ich gedacht). Und das Pudd wie auch immer mit 'dd' und komprimieren vom Image großartig Fehler macht, kann ich mir auch nicht vorstellen.

Das Problem ist, dass ich nicht weiß, wie ich ein Image auf Konsistenz prüfen kann! Hab schon ein bisschen gegoo... aber noch nichts gefunden.

Zum Prüfen von Xfs gibt es Beiträge.

 

[josef-wien]

komprimieren vom Image

Von Komprimieren kann keine Rede sein, sonst hättest Du die Image-Datei nicht mit

mount -o nouuid SALIX-19-05-28.img $PWD/ISO

einhängen können, sondern vorher De-Komprimieren müssen.

ein Image auf Konsistenz prüfen

Zum Beispiel die nicht eingehängte Kopie der Image-Datei mit

fsck.xfs dateiname

prüfen bzw. mit

xfs_repair parameter dateiname

(Parameter siehe manpage) reparieren.

 

[OsunSeyi]

xfs_repair SALIX-19-05-28.img
Phase 1 - Superblock finden und überprüfen...
Cannot get host filesystem geometry.
Repair may fail if there is a sector size mismatch between
the image and the host filesystem.
Phase 2 - ein internes Protokoll benutzen
        - Null-Protokoll...
        - freier Speicher und Inode-Karten des Dateisystems werden
gescannt...
agi unlinked bucket 11 is 3179979 in ag 3 (inode=53511627)
...(jede Menge)
agi unlinked bucket 63 is 4673535 in ag 1 (inode=21450751)
        - Wurzel-Inode-Stück gefunden
Phase 3 - für jedes AG...
        - agi unverknüpfte Listen werden gescannt und bereinigt...
        - bekannte Inodes werden behandelt und Inode-Entdeckung wird
durchgeführt...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - neu entdeckte Inodes werden behandelt...
Phase 4 - auf doppelte Blöcke überprüfen...
        - Liste mit doppeltem Ausmaß wird eingerichtet...
        - es wird geprüft ob Inodes Blocks doppelt beanspruchen...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - AG-Köpfe und Bäume werden erneut gebildet...
        - Superblock wird zurückgesetzt...
Phase 6 - Inode-Verbindbarkeit wird geprüft...
        - Inhalte der Echtzeit-Bitmaps und Zusammenfassungs-Inodes werden zurückgesetzt
        - Dateisystem wird durchquert ...
        - durchqueren beendet ...
        - nicht verbundene Inodes werden nach lost+found verschoben ...
nicht verbundener Inode 1033253, gehe zu lost+found
...(jede Menge)
nicht verbundener Inode 53635682, gehe zu lost+found
Phase 7 - Verweisanzahl wird geprüft und berichtigt...
erledigt

(Doch, natürlich habe ich vorher mit gzip -d -k dekomprimiert.
Aber hier nicht ausgeführt, weil es ja eigentlich nicht zur Sache gehört.)

Vielen Dank für den Hinweis, einfacher ging's ja nicht.

691 Objekte der Gesamtgröße 53,6 MB in "lost+found" (gemountetes Image)
691 Objekte der Gesamtgröße 53,6 MB in "lost+found" (Zielpartition, erst mit 'dd' kopiert und dann repariert)

Das ist aber ärgerlich, also habe ich kein unbeschadetes Backup!

Repair may fail if there is a sector size mismatch between
the image and the host filesystem.

Gemountet ist auf ext3, falls das eine Rolle spielt.

Schade, daß es nicht möglich ist zu schauen, welche Dateien genau geschreddert wurden.
Vielleicht ist es ja nicht von Bedeutung.

EDIT

Hatte ja schon geschrieben, daß Abiword zu Abstürzen neigt mit der Fehlermeldung "Schreibfehler...". Wenn ich nun eine der ersten Bruchstücke öffne, dann ist das der Head einer Abiworddatei (xml). Inode 14795938

Öffne ich eines der letzten Bruchstücke 26379999 ist es *dieselbe* Datei.
Desgleichen zig mal den Ausschnitt einer in der Abiworddatei eingebundenen Grafik.

Vielleicht ist ja nicht das ganze Dateisystem korrumpiert, sondern nur diese eine Datei?

Darum meine ich, man sollte mal versuchen, das ganze hochzufahren!

 

[josef-wien]

also habe ich kein unbeschadetes Backup

Normalerweise wird beim Systemstart nur geprüft, ob des Journal konsistent ist. Eine eingehende Dateisystemprüfung findet nicht statt. Bei ext4 kann man einstellen, wann sie ausgeführt werden soll (sofern das in /etc/fstab aktiviert ist), zu xfs kann ich nichts sagen. Vor einer Datensicherung wäre eine manuell auszulösende Prüfung durchaus angebracht.

sollte mal versuchen, das ganze hochzufahren

Ja. Du kannst das System mit der "Super Grub2 Disk" starten (eventuell wirst Du dort unter "Boot manually / Operating Systems / e" den Namen der initrd ausbessern müssen) und Lilo dann im laufenden System neu einrichten.

 

[OsunSeyi]

Die fstab trägt den Eintrag:

/dev/sda1 /  xfs   defaults   1 1

Ich weiß aber nicht, inwiefern das '1 1' bedeutet, daß beim letzten Systemstart (aus dem mein reguläres Backup der eigenen Dateien stammt) das Dateisystem tatsächlich geprüft wurde.

In diesem Arch-Wiki ist (leider nur auf englisch) beschrieben, wie sich korrupte Dateien mittels 'find -inum' identifizieren lassen. Evtl. werde ich das nachholen.

Nach dieser Beschreibung Slackwiki - Reinstalling Lilo war es kein Problem, mittels 'chroot' Lilo zu installieren und das System wieder zu booten.

Was ich jetzt tatsächlich ein bisschen vermisse, wäre irgendwie zu prüfen, ob das System tatsächlich noch 100% ok ist oder eben nur das Dateisystem wieder hergerichtet. Noch dringender gilt das für meine persönlichen Daten, weil zuletzt alles via rsync "in einem großen Pott" landet und ich nicht möchte, daß irgendwelche fehlerhaften Dateien in zwei Jahren unversehens auftauchen!

Gibt es eine Möglichkeit, das zu prüfen? Die alte Festplatte war ja möglicherweise schon länger defekt, wer kann das wissen, wenn es evtl bis dahin einfach nur nicht aufgefallen ist?

Ps
Vielen Dank für Eure Geduld!
Eine weitere Frage ist, ob 'dd' im Fall eines neuen Datenträgers das geeignete Werkzeug ist, oder die von Gräfin Klara beschriebene Vorgehensweise besser ist:

"find -xtype", prüfe alle toten Links und entferne alles aus den mountpoints mit speziellen Filesystemen

Danach rsync..

rsync -AHPSXavx --delete /einhängepunkt/iso/ /einhängepunkt/neue_systempartition/

Also wie oben beschrieben!
Wie verhält es sich denn, wenn mit 'dd' in eine deutlich größere Partition als die Ausgangspartition kopiert wird?

 

[josef-wien]

Wenn Du absolut sicher sein willst, daß das Betriebssystem in Ordnung ist, mußt Du es auf einer frisch formatierten Partition neu installieren. Theoretisch ist es denkbar, daß auf der defekten Platte einige Bits oder Bytes falsch waren, auch wenn die Wahrscheinlichkeit gegen Null tendiert. Merken würdest Du es vermutlich an Programmabstürzen. Bei einer auf RPM-Paketen basierenden Distribution kannst Du prüfen, ob die installierten Dateien dem Paketinhalt entsprechen (mühsam ist es trotzdem, da Konfigurationsdateien ja korrekt verändert sein können), bei einfachen Tar-Archiven ist diese Möglichkeit eher zu bezweifeln.

Anders sieht es bei Benutzerdaten aus, da merkst Du es frühestens dann, wenn Du die Datei bearbeitest.

Wie verhält es sich denn, wenn mit 'dd' in eine deutlich größere Partition als die Ausgangspartition kopiert wird?

Das Dateisystem nimmt eben nicht den gesamten Platz in Anspruch.

 

[OsunSeyi]

Das Dateisystem nimmt eben nicht den gesamten Platz in Anspruch.

DH, 'dd' ist schon korrekt und ich könnte das Dateisystem mit zB GParted nach dem Kopiervorgang noch so vergrößern, daß die Partition ausgefüllt ist? Taucht der verbliebene Platz unter 'allocated' auf?

Ähem, falsch, ich kopiere ja in eine bereits formatierte Partition... :???:

 

[josef-wien]

:???:

Wenn Du mit dd kopierst, ist es völlig irrelevant, welche Bedeutung die Bits und Bytes vorher gehabt haben, der alte Inhalt wird mit dem neuen überschrieben. Der "überzählige" Platz bleibt zwar unverändert (und Du kannst die Sektoren z. B. mit hdparm ansprechen), aber das neue Dateisystem kennt ihn nicht. Wie grafische Partitionierungsprogramme diesen Bereich darstellen, mußt Du selbst herausfinden, vermutlich kümmern sie sich nicht um die Dateisystemgröße.

 

[Anonymous]

Das Dateisystem nimmt eben nicht den gesamten Platz in Anspruch.

DH, 'dd' ist schon korrekt und ich könnte das Dateisystem mit zB GParted nach dem Kopiervorgang noch so vergrößern, daß die Partition ausgefüllt ist? Taucht der verbliebene Platz unter 'allocated' auf?

Ähem, falsch, ich kopiere ja in eine bereits formatierte Partition... :???:

Fast richtig: Du kopierst ein Dateisystem (mit seinen Rohdaten) in eine Partition.
Wenn die Zielpartition größer als dein Dateisystem ist, kannst du anschließend die Dateisystemgröße an die Partitionsgröße anpassen. Dafür gibt es Kommandozeilenprogramme und Grafische.
Bei GParted wird das normalerweise automatisch durchgeführt, wenn man den Menüpunkt: Partition → Überprüfen / Check aufruft.

Angenommen, das Dateisystem ist nur halb so groß wie die Partition, und das Dateisystem ist halb voll:
Dann zeigt GParted die rechte Hälfte der Partition mit einem grauen Feld.
Und die Nutzdaten stellt GParted links als gelben Bereich dar, der halb so groß ist, wie das weiße Feld.
Etwa so:

Partition———————————→|
Dateisystem—→|
Daten→|
████████████

Dateisystemgröße = Partitionsgröße:

Partition———————————→|
Dateisystem —————————→|
Daten→|
████████████

 

[OsunSeyi]

Cool, wie hast Du die Graphik da rein bekommen?
Wo Du das sagst, erinnere ich mich, daß GParted sowas wie "...auffüllen" oder ähnlich als letzten Punkt nach dem check aufruft, wenn man sich die Details anzeigen lässt.
Da das Image ja kleiner sein muss als die Zielpartition, ist das Auffüllen der Partition auf jeden Fall sehr sinnfällig!

Übrigens schreibe ich von meinem wiederhergestellten System!

Vielen Dank für Eure Hilfe!

Nachtrag:
Auf der zweiten Partition der defekten Platte ist Tiny Core Linux in zwei Verzeichnissen 'tce' und 'home' installiert, daß (im Ggs zu gleichfalls dort installierten Puppy) nach einem 'normalen' Kopieren mit 'cp' nicht mehr booten wollte.
Nun konnte ich dort 'dd' nicht anwenden, es sei denn, nur speziell auf diese beiden Verzeichnisse. Ich weiß aber nicht, ob das überhaupt geht. Es ist ja ('dd --help') ausdrücklich von Festplatten, Partitionen und Dateien die Rede und nicht von Verzeichnissen. Gibt es etwas vergleichbares, was 1:1 Kopien erstellen kann? Klar, wohl rsync...
Lösung war, die Ausgangspartition mit GParted soweit wie möglich zu verkleinern, 'dd' nach Imagefile ausführen, eigene Zielpartition auf der neuen Platte dafür eingerichtet, mit 'dd' in Zielpartition kopiert, Partition aufgefüllt, Lilo angepasst, TC bootet wieder...

 

[Geier0815]

Entschuldige die evtl. dusselige Frage: Warum arbeitest Du heutzutage noch mit Lilo?