[DE] Siduction als Rettungspartition für Windows (Image erstellen/zurückspielen)

[bluelupo]

@pit: Sorry, da hast du recht. Bei der Übergabe an eine Pipe gibt es für das dd-Kommando kein of (Ouputfile), denn das wird ja via Pipe weitergereicht an lzop und der wiederum ist für den Output zuständig. Als deine Variante ist korrekt.

Was hast du denn für eine Kompressionsrate?

[pit]

@bluelupo:

Partition: 4,9 GB
Benutzt: 157 MB
LZO: 109 MB

Rechnen musste selbst (das kann ich nicht so gut) ;-)

[der_bud]

Hallo pit, sieht ja gut aus soweit. Nur zur Vervollständigung: wenn Du wie im Beispiel (und angekündigt für Dads notebook) /dev/sda1 sichertst, ist das genau die Partition. Damit sicherst Du noch nicht MasterBootRecord mbr, bestehend aus dem Bootloader (in den ersten 446 Bytes) und die Partitionstabelle (64 Bytes). Zur Sicherheit solltes Du also nacher auf dem realen System einmal (nach Ubuntuwiki):

Code: [Select]

dd if=/dev/sda of=mbr_sicherung bs=512 count=1durchführen und bei Partitionsänderungen aktualisieren.

Und noch ein Zusatztipp, wir hatten hier im Forum ein paarmal was zum Thema "Fortschritt von dd mit pipeview (pv). Wenn Du pv nachinstallierst, kannst Du das noch zwischen Eingabe und Ausgabe setzen und kriegst eine Fortschrittsanzeige. Die Syntax wäre z.B.

Code: [Select]

dd if=/dev/sdb1 | pv -petra | lzop -1 -o /mnt/sdc1/150129-slitaz.img.lzo

[ayla]

Hallo pit, sieht ja gut aus soweit. Nur zur Vervollständigung: wenn Du wie im Beispiel (und angekündigt für Dads notebook) /dev/sda1 sichertst, ist das genau die Partition. Damit sicherst Du noch nicht MasterBootRecord mbr, bestehend aus dem Bootloader (in den ersten 446 Bytes) und die Partitionstabelle (64 Bytes).

Hi,

deswegen schlug ich das Sichern von sda mit Counter statt sda1  vor, dann ist der MBR etc. mit drauf und das Restore kann aus einer Datei erfolgen. Und solange man darauf achtet daß das Ende der 1. Partition beim Sichern leer ist ist es auch nicht so wichtig wo genau die Sicherung endet, solange sie nahe des Endes innerhalb! des leeren Bereichs der ersten Partition endet.

Zur Sicherheit solltes Du also nacher auf dem realen System einmal (nach Ubuntuwiki):
Code: dd if=/dev/sda of=mbr_sicherung bs=512 count=1durchführen und bei Partitionsänderungen aktualisieren.

Das macht natürlich Sinn wenn man Partitionsänderungen vornimmt und sich anschließend eine komplette Sicherung der Partiton 1 sparen kann, allerdings darf dann auch nicht mehr ein früher gesichertes sda zurück gespielt werden, sondern dann ein sda1.



Interessanter Thread übrigens.

Gruß
ayla

[pit]

deswegen schlug ich das Sichern von sda mit Counter statt sda1  vor, dann ist der MBR etc. mit drauf und das Restore kann aus einer Datei erfolgen.

Ich kann deine Argumentation nachvollziehen. Da ich aber nicht weiß, ob ich ein solches Image nur einmal - quasi initial nach mustergültiger Installation - erstellen werde, oder z.B. auch mein Vater Zwischenstände konservieren möchte, klingt mir das zu riskant. Nicht auszuschließen also, dass der Füllstand der zu sichernden Partition die voreingestellte Grenze dorch irgendwann überschreitet. Am Ende hat mein ein unvollständiges und in dieser Form vermutlich nicht verwendbares Image erstellt. MBR u. Partition in gesonderten Backups zu speichern, klingt für mich wie ein vertretbarer Kompromiss.

[bluelupo]

Hi pit,

ich würde dringend raten folgende Backupstrategie (aus leidvoller Erfahrung) ans Herz legen. Aus der Rettungspartition heraus würde ich per Shellscript (auf dem Desktop anklickbar) folgende Partitionen sichern (alles per dd):

* MBR
* Windows Systempartition
* Windows Datenpartition

...davon würde ich die letzten 5-10 Backupsätze aufbewahren. Somit stellst du sicher das keine Windows-Partition (pus MBR) nicht mehr ersetzbar ist. Im Idealfall hast du die Rettungspartition auf einer eigenen Festplatte, dann bist bei einem HW-Defekt der Windows-Disk auch noch auf der sicheren Seite.

Ich gehe im Prinzip bei dem Rechner meiner Freundin genauso vor, d.h. Systemartition (siduction) liegt auf einer SSD (sda) und die Backup-Sätze liegen auf einer zweiten HDD (sdb) auf der ich nur die Sicherungen ablege.

[pit]

Code: [Select]

dd if=/dev/sdb1 | pv -petra | lzop -1 -o /mnt/sdc1/150129-slitaz.img.lzo
Ähm - blöde Frage: Wie spiele ich das zurück? So?

Code: [Select]

dd if=/mnt/sdc1/150129-slitaz.img.lzo | pv -petra | lzop -x -o /dev/sdb1
Das würde ja bedeuten, dass lzop gleichermaßen entpacken und blockorientiertes Kopieren kann. Letzteres doch sicher nicht oder? Hieße, dass man das in zwei Schritten machen müsste? Dann hätte ich im Zweifel aber schon wieder ein Platzproblem.

[der_bud]

Moin pit, die Anleitungen die ich mir abgespeichert haben fangen bei komprimierten Images den Rückspielbefehl mit dem Unpacker an, dessen Ausgabe wird zu einem 'dd of=' gepiped. Hier mehrere Syntaxvarianten mit gzip, für lzop anzupassen:

Code: [Select]

gunzip -c /media/sdb1/backup.img | dd of=/dev/hda bs=1M

Code: [Select]

gzip -dc image.dump.gz | dd of=/dev/sdb

Code: [Select]

cat /home/user/image_sda1.img.gz | gunzip -c - | dd of=/dev/sda1
Kommt mir jetzt beim Nachdenken auch logisch vor, da Du beim Rückspielen ja nicht ein Blockdevice ausliest, aber zu einem schreibst. Mit dd beginnen würde das Rückspielen bei einem 1:1-kloning Device-auf-Device.

[convbsd]

Hello

Another idea is to use ntfsclone.to clone and restore a windows partition.

to make an image
ntfsclone --save-image -o - /dev/$dev | gzip -c > /usr/local/$dev.gz

and for restoring an image
gunzip -c /usr/local/$dev.gz | ntfsclone --restore-image --overwrite /dev/$dev -

ntfsclone is very quick and clones only used sectors.
Maybe if it's used lzo instead of gzip the process will be faster.
To use ntfsclone input and destination partitions should have same sizes.

If dest partition has a different size it can be used fsarchiver instead.

to make an image
fsarchiver  -v savefs /usr/local/${dev}.fsa /dev/$dev

to restore an image
fsarchiver  -v restfs /usr/local/${dev}.fsa id=0,dest=/dev/$dev

fsarchiver works at files level and is able to understand ntfs and linux ext4 if I am not wrong.

[pit]

@der_bud

Was klappt: lzop-komprimiertes Image erstellen (habe ein Script gebaut, um Trouble mit sudo und Pipes zu umschiffen).
Was nicht klappt: Restore in einem Rutsch.

Probiert habe ich

Code: [Select]

sudo sh -c 'lzop -d bla.img.lzo | dd of=/dev/sda3'
Habe zwischenzeitlich statt sda3 auch mal in ein File schreiben lassen - das hat aber immer 0 Byte.

Packe ich die *.img.lzo gesondert aus (lzop -d ....), wird korrekt entpackt. Wo ist mein Denkfehler?

(Wer oben mitgelesen hat und sich jetzt wundert, warum ich statt sda mit sdaN operiere: Auf dem Zielrechner wurden bei der Windows-Installation (SSD = sda) gleich drei Partitionen angelegt. sda1 = UEFI, sda2 = WindowsBoot, sda3 = Win-C.)

[der_bud]

Hi pit, ich glaube ich habe neulich in einem Forum genau die selbe "Falle" gesehen die ich bei Dir zu erkennen glaube: wenn Du root-Rechte bzw sudo benötigst, dann für jeden Befehl einzeln, also auch nach der Pipe.

Code: [Select]

sudo sh -c 'lzop -d bla.img.lzo | sudo dd of=/dev/sda3'könnte eher klappen.
__
Edit:  ^ falsch, siehe unten.

[melmarker]

äh nee - dat is gruselig, der_bud, so solltest Du dat mit den Hochkommas nich mixen

Code: [Select]

sudo su -c "lzop -d bla.img.lzo | dd of=/dev/sda3"

dürfte passen, weil als Befehl das in den Hochkommas eingeschlossene betrachtet wird. sudo ist eigentlich immer gruselig.

[der_bud]

   aaiihh - ich hatte komplett die Hochkommas übersehen...

[pit]

@melmarker
Du meinst, ich soll die Hochkommata schlicht gegen Anführungszeichen austauschen? Ich bin jetzt nicht so der Fachmann in Sachen Shellscripts: Macht das in diesem Fall einen Unterschied? Ich finde dazu z.B. das hier, lese daraus aber keinen Unterschied.

Meine Version (die nicht funktioniert):

Code: [Select]

sudo sh -c 'lzop -d bla.img.lzo | dd of=/dev/sda3'
Deine Version (die ich noch nicht testen konnte)

Code: [Select]

sudo su -c "lzop -d bla.img.lzo | dd of=/dev/sda3"

[melmarker]

ob du in diesem speziellen Fall einfache oder doppelte Hochkommata benutzt, ist recht wurst, witzig wird der Unterschied erst, wenn Du Variablen und solch Zeug expandieren musst:

Der Unterschied zwischen einfachen und doppelten Anführungszeichen ist, dass bei doppelten Anführungszeichen eine Variablenerweiterung stattfindet. Einfache Anführungszeichen gewährleisten, dass die Zeichenfolge von der Shell buchstäblich interpretiert wird.

Und wenn Du mir jetzt noch erklärtst, was Du mit "sudo sh" erreichen willst ...