dd over ssh

N

NetRat

Member
Guten Morgen liebe Community,

ich verwende KVM für meine virtuellen Maschinen, als Storage verwende ich LVMs. Ich habe gestern eine virtuelle Maschine via dd over ssh auf einen neuen Host kopiert.

Code: 
dd bs=4k if=/dev/vg0/vm1 | ssh root@10.10.10.10 dd of=/dev/vg0/vm1 bs=4k

Der Vorgang war erfolgreich; Die virtuelle Maschine läuft nun auf dem neuen Host.

Zu meinen Fragen:
* Ist es sinnvoll O_SYNC und O_RSYNC zu verwenden, wenn via SSH kopiert wird?
* Muss ich mit Problemen ( z.B. Fehlern beim kopieren ) rechnen, wenn ich O_SYNC und O_RSYNC nicht verwende?

Ich freue mich über jegliche Erfahrungsberichte ;)

Liebe Grüße
NetRat
 
Soweit ich die manpage von dd verstehe, macht osync nur Sinn, wenn man conv verwendet, da dann die Blocksize zwischen input und output abweichen kann und somit ggf. output gepaddet werden muss.

Ich denke, dass das in deinem Usecase völlig unerheblich ist und somit keinen Unterschied macht.
Wenn du sicher gehen willst, dass keine Kopierfehler auftreten, dann vergleiche einfach einen Hash von Quell- und Zieldatei.

Ich habe jahrelang diverse "Bytestream over SSH"-Geschichten für Backups benutzt und nie erlebt, dass dabei Überragungsfehler aufgetreten wären.
 
Es macht allerdings Sinn, die "-C" -Option von SSH zu verwenden - damit wird die Verbindung komprimiert, was bei mir so manche Kopierdauer schon durchaus um gut 30% verkürzt hat.
 
Mal doofe Frage. Kann man das mit rsync nicht besser, schneller und effizienter machen? DD ist nicht intelligent und kopiert auch die leeren Sektoren. Selbst wenn der Lesevorgang so schnell ist, dass er vernachlässigbar ist und durch die Kompression auch Daten gespart werden, müssen am Ende die leeren Sektoren immer noch geschrieben werden.

Wenn es das gleiche Schema der Partitionstabelle sein soll, dann:

Code: 
sfdisk -d /dev/sda | sfdisk /dev/sdb #msdos partitionstabelle
#gpt mit sgdisk
#ggf. MBR  mit dd übertragen

Auf jeden Fall ist man mit RSync felxiebler, weil auch das Zeildateisystem ein anderes sein kann.
 
Last edited by a moderator:
Die KVM Instanzen werden wohl eigene Logical Volumes (LVM wie im ersten Beitrag vermerkt) haben. Wie willst du ein Device via rsync syncen? ;)
Bei Linux mag das mit etwas Frickelei (auf dem Host mounten, syncen, auf dem Ziel Bootloader schreiben, usw) noch recht "einfach" möglich sein, aber bei Windows VMs wirds schon deutlich schwieriger.

In dem Fall würde ich auch bei der dd Variante bleiben. ;)
 
Vielen Dank für eure Antworten!

Vielen Dank für eure Antworten!

Ich werde dann wohl so verfahren wie auch bisher. Wenn elias5000 jahrelang keine Probleme "Bytestream over SSH" hatte wird es mir wohl kaum anders gehen und für den Worst-Case gibt es ja immer noch Backups ;)

@Lord Gurke
Danke für den Hinweis mit der Komprimierung, hatte ich gar nicht in dran gedacht ;)

@DeaD_EyE
Wie Firewire2002 bereits geschrieben hat benutze ich logische Laufwerke, daher bietet sich rsync nicht wirklich an ;)
 
Bei Linux kann ich die RSYNC-Methode nur empfehlen. Habe auf meinen Hosts Xen, ebenfalls mit LVM. Habe die dann einfach auf dem Host mounted, auf den anderen Host rsynced, die VM gestartet. Ging einiges schneller als dd..
 
Ein alternativer Ansatz wäre CloneZilla zu verwenden - das kommt auch mit LVM klar, man erhält komprimierte Image-Files die auch nur die tatsächlich belegten Blöcke/Daten enthalten. Beim Restoren kann man so auch bequem eventuelle Größen anpassen.
 
Wieso ich die Methode vorgeschlagen hab, schrieb ich ja bereits. Das es sich um Windows-VMs handelt, wusste ich nicht.

CloneZilla wäre ein Ansatz. Zumindest setzt es recht bekannte tools ein, um ntfs und andere Dateisystem effizient zu klonen. Es ging mir um die Zeitersparnis.
 
You must log in or register to reply here.
Back
Top