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

Begonnen von pit, 2015/01/28, 10:18:33

Vorheriges Thema - Nächstes Thema

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):
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.
dd if=/dev/sdb1 | pv -petra | lzop -1 -o /mnt/sdc1/150129-slitaz.img.lzo
Du lachst? Wieso lachst du? Das ist doch oft so, Leute lachen erst und dann sind sie tot.

ayla

Zitat von: der_bud in 2015/01/29, 17:14:56
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.

ZitatZur 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

Zitat von: ayla in 2015/01/30, 00:48:31deswegen 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

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?

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:

gunzip -c /media/sdb1/backup.img | dd of=/dev/hda bs=1M
gzip -dc image.dump.gz | dd of=/dev/sdb
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.
Du lachst? Wieso lachst du? Das ist doch oft so, Leute lachen erst und dann sind sie tot.

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

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.
sudo sh -c 'lzop -d bla.img.lzo | sudo dd of=/dev/sda3'
könnte eher klappen.
__
Edit:  ^ falsch, siehe unten.
Du lachst? Wieso lachst du? Das ist doch oft so, Leute lachen erst und dann sind sie tot.

melmarker

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


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.
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

der_bud

 :-[  aaiihh - ich hatte komplett die Hochkommas übersehen...
Du lachst? Wieso lachst du? Das ist doch oft so, Leute lachen erst und dann sind sie tot.

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):

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

Deine Version (die ich noch nicht testen konnte)

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:
ZitatDer 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 ...
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)