Nasman a écritJe suppose que le contenu de /dev/disk1 est recopié sur disk2 mais aussi sur disk3 et disk4 (les mêmes choses sont clonées). Il faut donc que disk2, disk3 et disk4 soient d'une taille au moins égales à disk1. A priori ce que tu appelles disk1, disk2, disk3 et disk4 seraient des partitions. N'y a-t-il pas un risque de perte de place entre le contenu copié (en-tête et contenu des partitions) et les tailles des partitions indiquées dans le mbr des disques de destination ?
En linux je fais ça depuis des années avec la commande 'dd', la taille du disque importe peu
Par exemple, pour faire du recyclage pc, je créé une partition "swap "de 512Mo et une partition racine de 19,5GO que je blinde à mort de logiciels et données. Ça peut se faire sur un disque de 350Go
Je récupère une image d'une partie de ce disque en mettant un fichier "image.img" en sortie (et non un périphérique), j'arrête la copie en gros à 20GO.
Pour la restauration c'est l'inverse, l'entrée est le fichier img, la sortie le périphérique
Peu importe la taille du disque, 'dd' copie bit à bit le disque et commence par la mbr, il faut que ce soit un disque de 20go minium (taille de la swap+partition). J'étends ensuite la partition "/" avec gparted, je n'ai jamais eu de soucis
Y a même moyen de piper à la commande 'dd' un "gzip" pour gagner du temps et de l'espace disque
Enfin pour ta première question, si je ne mets pas ces arguments, la commande ne connaît pas la taille du disque et donc ne peut pas afficher le % de progression. Elle n'affiche pas non plus le temps restant (logique)
edit : merci pour avoir vu l'erreur dans mon billet, c'est bien sda / sdb... (et pas sda1, on s'en fout de la partition, on prend tout le disque)
