• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Partition aus Image wiederherstellen

A

Anonymous

Gast
OsunSeyi schrieb:
Cool, wie hast Du die Graphik da rein bekommen?
Mit dem UFT8-Zeichen "full block" und etwas Farbe.
 
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!
Auf jeden Fall darf die Zielpartition nicht kleiner sein als das per dd zurückzukopierende Dateisystem.
 
Übrigens schreibe ich von meinem wiederhergestellten System! :thumbs:
XFS ist ein sehr robustes Dateisystem,
hat aber den kleinen Nachteil, dass ein Bootloader nicht in der XFS-root bzw. XFS-boot-Partition installiert werden darf, weil XFS exakt bei "0" beginnt, d.h. von Haus aus kleinen Platz dafür frei lässt.
 
Nachtrag:
[…] 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...
Wenn du mit der Kommandozeile klar kommst, schaue dir mal FSArchiver an.
Damit wird ein Dateisystem incl. aller seiner Metadaten gesichert, was per rsync oder tar nicht möglich ist.
Mit FSArchiver kannst du auch eine XFS-Partition quasi 1:1 verkleinern, indem du das XFS-Dateisystem sicherst, eine neue, kleinere Partition erstellst und die Sicherung zurückspielst. FSArchiver erstellt selbst das neue XFS-Dateisystem.
Außerdem kann FSArchiver beim Zurücksichern ein anderes Dateisystem verwenden als es ursprünglich war. So kann man z.B. von ext4 auf ext3 oder von ext3 auf xfs usw. wechseln. (habe ich alles schon gemacht)

Nachteilig bei dd ist, dass das gesamte Dateisystem roh kopiert wird, unabhängig davon, ob überhaupt Nutzerdaten vorhanden sind. Dadurch ist die Sicherungsdatei immer so groß wie die Partition, weil der irrelevante "Müll" auf der Platte auch mitgeschleppt wird.
 
OP
OsunSeyi

OsunSeyi

Hacker
Geier0815 schrieb:
Entschuldige die evtl. dusselige Frage: Warum arbeitest Du heutzutage noch mit Lilo?
Naja :???:
Ist halt Standard bei Slackware und auch Salix...
Das müsste ich ja nach der Standard-Installation extra ändern. Und ich kann damit TCL und Puppy frugal installiert auch ohne weiteres booten. Der Grund für die Verwendung bei Slackware wird sein, daß Lilo ohne Rückbeziehung auf eine Konfigurationsdatei im System klar kommt, also tatsächlich nur aus dem Bootsektor heraus.

Wenn du mit der Kommandozeile klar kommst, schaue dir mal FSArchiver an.
Danke für den Tip! Ist als Slackbuild erhältlich!

BTW
Nach den jetzigen Erfahrungen glaube ich, daß ein frugal installiertes kleines System, möglichst in einer eigenen kleinen primären Partition, fast ideal als "Retter in der Not" ist:
Wenn es dann noch aus dem Arbeitsspeicher heraus läuft, wird es eine angedötschte Festplatte kaum beanspruchen und als einzelne Datei mit einer höheren Warscheinlichkeit nicht kompromitiert sein.
Von dort aus ist ein Zugriff auf den Rest der Platte schnell möglich.
Auch für Backupzwecke. Wer hat schon ein Rettungssystem auf Stick oder CD parat?
Wenn man dann keinen Zweitrechner 'zur Hand' hat, kann man hausieren gehen...
Ich habe von meinem Slacko aus eine neue Festplatte gekauft...
 

josef-wien

Ultimate Guru
OsunSeyi schrieb:
Wer hat schon ein Rettungssystem auf Stick oder CD parat?
Wahrscheinlich jeder, der Datensicherung ernst nimmt. Wenn die Partitionentabelle beschädigt ist, kannst Du von der Platte nicht mehr starten. Und ohne gesicherte Daten wirst Du dann ohne Kenntnis der in der Partitionentabelle gespeicherten Informationen nur mehr mühsam mit Programmen wie TestDisk an Deine Daten herankommen.



OsunSeyi schrieb:
nur aus dem Bootsektor heraus
Mit den dort zur Verfügung stehenden 440 Bytes findet kein Bootloader das Auslangen. Im Prinzip steht dort nur ein Sprungbefehl zu jenem Sektor der Festplatte, an der der Bootcode (der manchmal in die Sektoren nach dem MBR kopiert wird) beginnt. Ein vernünftiger Bootloader kommt immer ohne Konfigurationsdatei aus, aber die Menschen vor dem PC brauchen sie, denn sonst müßten sie bei jedem Systemstart die notwendigen Angaben eintippen.



OsunSeyi schrieb:
Tiny Core ... mit 'cp' nicht mehr booten wollte.
Es ist anzunehmen, daß auch hier die Konfiguration nicht mehr gepaßt hat.
 
OP
OsunSeyi

OsunSeyi

Hacker
Eine Frage habe ich noch...

Betreffs des Mountens des Images gibt es sowohl die Angabe im Netz:

Code:
mount -o nouuid image directory 
als auch...
mount -o loop image directory
loop
Einbinden eines Loop devices, also eines Blockgerätes, welches keinem physischen Gerät entspricht, sondern als zugrundeliegenden Speicher eine Datei nutzt, z.B. ein als Datei vorliegendes Dateisystem-Abbild wie ein CD-Image.


Ok, verstanden.
Aber die Option '-o nouuid' habe ich nicht verstanden..

Was ist denn nun richtig?
Und muss ich ggF das im Image verwendete Dateisystem mit zB '-t ext4' spezifizieren?
 

josef-wien

Ultimate Guru
nouuid gibt es meines Wissens nur bei xfs (siehe man xfs). loop (siehe man losetup bzw. https://de.wikipedia.org/wiki/Loop_device) und die Angabe des Dateisystems können bei modernen Systemen schon weggelassen werden.
 
Oben