Sie können bashs "process substitution" zusammen mit dem tee-Befehl verwenden, um dies zu tun:
cat drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) | dd of=/dev/sdd
oder aus Gründen der Übersichtlichkeit (auf Kosten einer geringen Effizienz) können Sie die letzte machen dd benenne dich genauso wie die anderen und sende die stdout von tee nach / dev / null:
cat drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) >(dd of=/dev/sdd) | /dev/null
und wenn Sie es installiert haben, können Sie verwenden Pipe Viewer anstatt cat um eine nützliche Fortschrittsanzeige zu erhalten:
pv drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) | dd of=/dev/sdd
Dadurch wird das Quellimage nur einmal gelesen, sodass das Quelllaufwerk einem starken Druck ausgesetzt ist. Dies ist wahrscheinlich der Grund, warum Sie eine exponentielle Verlangsamung feststellen, wenn Sie versuchen, das Image mehrmals mit anderen Methoden zu kopieren. Verwenden tee Wie oben sollten die Prozesse mit der Geschwindigkeit des langsamsten Ziellaufwerks ausgeführt werden.
Wenn die Ziellaufwerke über USB verbunden sind, beachten Sie, dass sie möglicherweise alle die Busbandbreite gemeinsam nutzen, sodass das Schreiben vieler paralleler Laufwerke möglicherweise nicht schneller ist als das sequentielle Schreiben, da der USB-Bus zum Engpass und nicht zum Quell- oder Ziellaufwerk wird.
In den obigen Ausführungen wird davon ausgegangen, dass Sie Linux oder ein ähnliches Produkt verwenden (es sollte auch unter OSX funktionieren, obwohl die Gerätenamen möglicherweise unterschiedlich sind). Wenn Sie Windows oder etwas anderes verwenden, benötigen Sie eine andere Lösung.
Bearbeiten
Imaging über das Netzwerk hat ein ähnliches Problem wie das Imaging vieler Laufwerke über USB - der Transportkanal wird zum Engpass anstelle der Laufwerke - es sei denn, die von Ihnen verwendete Software unterstützt irgendeine Form von Broadcast- oder Multicast-Übertragung.
Für die dd Methode könnten Sie wahrscheinlich verketten netcat + tee + dd Prozesse auf jeder Maschine wie folgt:
- Quellmaschine
cat / pv / dd s die Daten durch nc zum Zielrechner 1.
- Zielmaschine 1 hat
nc Hören Sie auf die Daten von der Quellmaschine und leiten Sie sie weiter tee was wiederum sendet es an dd (und so auf die Festplatte) und eine andere nc Prozess, der zum Zielcomputer 2 sendet.
- Zielmaschine 2 hat
nc Abhören der Daten von der Zielmaschine 1 und Weiterleiten derselben tee was wiederum sendet es an dd (und so auf die Festplatte) und eine andere nc Prozess, der an den Zielcomputer 3 sendet.
- und so weiter bis zur letzten Maschine, die gerade hat
nc die Daten von der vorherigen Maschine aufnehmen und über auf die Festplatte senden dd.
Auf diese Weise nutzen Sie möglicherweise Ihre gesamte Netzwerkbandbreite, vorausgesetzt, Sie haben mit Ihrem Switch und Ihren Netzwerkkarten eine Vollduplex-Verbindung ausgehandelt. Anstatt dass der Quellcomputer 10 Kopien der Daten sendet (unter der Annahme von 10 Zielcomputern), wird jeder auf 1/10 der ausgehenden Bandbreite begrenzt, die er nur sendet. 1. Jeder Zielcomputer nimmt eine Kopie der Daten und sendet sie nochmal. Möglicherweise müssen Sie die Einstellungen für die Puffergröße von anpassen pv, nc und dd um der besten praktischen Leistung näher zu kommen.
Wenn Sie eine Software finden können, die nur Multicast unterstützt, wäre dies der Fall viel einfacher (und wahrscheinlich etwas schneller)! Aber das Obige ist die Art von Hacky-Lösung, für die ich vielleicht dumm genug bin, es zu versuchen ...
Erneut bearbeiten
Ein anderer Gedanke. Wenn das Abbild des Laufwerks gut komprimiert wird (was der Fall ist, wenn große Teile mit Nullen gefüllt sind), muss die ausgehende Bandbreite des Quellcomputers kein Problem darstellen, auch wenn an viele Ziele gleichzeitig gesendet wird. Komprimieren Sie einfach zuerst das Bild und übertragen Sie es mit an jeden Ort tee + ncund dekomprimieren Sie die Ziele (Netzwerk- & gt; nc - & gt; Dekomprimierer- & gt; dd - & gt; Festplatte).