Você pode usar a "substituição de processo" do bash junto com o comando tee para fazer isso:
cat drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) | dd of=/dev/sdd
ou para maior clareza (às custas de um pouco de eficiência), você pode fazer com que o último ddseja chamado da mesma maneira que os outros e enviar o stdout do tee para / dev / null:
cat drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) >(dd of=/dev/sdd) | /dev/null
e se você o tiver instalado, poderá usar o visualizador de tubos em vez de catobter um indicador de progresso útil:
pv drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) | dd of=/dev/sdd
Isso lê a imagem de origem apenas uma vez, para que a unidade de origem sofra um golpe de cabeça, o que provavelmente será o motivo pelo qual você vê uma desaceleração exponencial ao tentar copiar a imagem várias vezes por outros métodos. Usando teecomo acima, os processos devem ser executados na velocidade da unidade de destino mais lenta.
Se você tiver as unidades de destino conectadas via USB, lembre-se de que todas podem compartilhar a largura de banda do barramento, portanto, gravar muitas em paralelo pode não ser mais rápido do que gravá-las sequencialmente porque o barramento USB se torna o gargalo e não as unidades de origem ou de destino.
O item acima pressupõe que você esteja usando Linux ou similar (ele também deve funcionar no OSX, embora os nomes dos dispositivos possam ser diferentes); se você estiver usando o Windows ou algo mais, precisará de uma solução diferente.
Editar
A criação de imagens na rede tem um problema semelhante ao de muitas unidades via USB - o canal de transporte se torna o gargalo em vez das unidades - a menos que o software que você utiliza suporte a alguma forma de transmissão de difusão ou multicast.
Para o ddmétodo, você provavelmente poderia encadear processos netcat+ tee+ ddem cada máquina da seguinte maneira:
- Máquina de origem
cat/ pv/ dds os dados até nca máquina de destino 1.
- A máquina de destino 1
ncescuta os dados da máquina de origem e os canaliza através dos teequais, por sua vez, os envia para dd(e assim para o disco) e outro ncprocesso que envia para a máquina de destino 2.
- A máquina de destino 2
ncescuta os dados da máquina de destino 1 e os teeencaminha através da qual os envia para dd(e assim para o disco) e outro ncprocesso que envia para a máquina de destino 3.
- e assim por diante até a última máquina que apenas
nccoleta os dados da máquina anterior e os envia para o disco via dd.
Dessa forma, você está potencialmente usando toda a largura de banda da rede, supondo que seus comutadores e placas de rede tenham negociado um link full-duplex. Em vez de a máquina de origem enviar 10 cópias dos dados (assumindo 10 máquinas de destino), portanto cada uma delas é limitada a 1/10 da largura de banda de saída, está enviando apenas 1. Cada máquina de destino está pegando uma cópia dos dados e enviando-os para fora novamente. Talvez seja necessário ajustar as configurações de tamanho do buffer de pv, nce ddpara se aproximar de melhor desempenho prático.
Se você puder encontrar algum software que apenas suporte multicast, isso seria muito mais fácil (e provavelmente um pouco mais rápido)! Mas o exposto acima é o tipo de solução hacky que eu posso ser idiota o suficiente para tentar ...
Editar novamente
Outro pensamento. Se a imagem da unidade compactar bem (o que ocorrerá se grandes partes estiverem cheias de zeros), a largura de banda de saída da máquina de origem não precisará ser um problema, mesmo que seja enviada para vários destinos ao mesmo tempo. Apenas comprima a imagem primeiro, transmita-a para qualquer lugar usando tee+ nce descompacte nos destinos (rede-> nc-> descompressor-> dd-> disco).