Bonjour,

Avant de faire n'importe quoi avec la commande 'dd' je viens vers vous avec quelques questions.

Imaginons que je dispose d'une machine avec une distrib Linux quelconque installé sur un disque de 1To, avec 3 partitions. Admettons que je rajoute un disque de 2To à la machine.

/dev/sda pointe vers le nouveau disque.
/dev/sdc vers celui de 1To.

• si depuis un liveCD je lance la commande suivante : 'dd if=/dev/sdc of=/dev/sda', que se passe-t-il ?

Je suppose que je peux permuter les deux disques, dans le sens ou si je modifie fstab et grub, je peut utiliser l'un ou l'autre disque pour booter avec le meme résultat. Correct Il me reste de plus de l'espace non alloué sur le disque de 2To.

• Puis-je copier une partition seulement ? Typiquement celle contenant la partion / par exemple. Admettons que je crée une table des partitions sur le disque vierge de 2To. Si je lance 'dd if=/dev/sdc1 of=/dev/sda1' est-ce que je peux démarrer mon système sur /dev/sda1 (au fstab et grub près ? )

Est-ce que ca marche également si /dev/sda1 et /dev/sdc1 n'ont pas la même taille ?

Merci pour vos réponses!

Salut,

Avant tout, soit le bienvenu.

Pour les manips de copie brute en disque à disque comme tu souhaites le faire, le mieux est d'utiliser un Live CD de Clonezilla.

C'est un outil de clonage de disque avec plusieurs modes disponibles dont la copie disque à disque ou encore la sauvegarde d'une partition / d'un disque dans une image compressée avec un taux de compression paramétrable.

Utiliser dd comme ça à la main c'est bien pour les flash de clé usb mais c'est bien plus chiant et moins clair à utiliser sur des trucs aussi sensibles que ce que tu souhaites faire.

Si tu oublie le paramètre bs de la commande dd, tu risque de devoir attendre une éternité le temps que la copie se fasse. Surtout pour du 1 To.

Donc, évite de t'emmerder pour rien et utilse des outils avec assistants pour éviter d'effacer le disque source par exemple.

Je n'utilise jamais "dd" tel quel pour cette raison.

Mais tu fais comme tu veux.

Bon bah, je retente un passage en testing

ShadowwF Tu fais allusion à ta carte Wi-Fi ?

| Ecrit par « Dakien », 25 août 2013 à 17:53:08
| « ShadowwF Tu fais allusion à ta carte Wi-Fi ? »

Exact, je pense faire ça ce soir, pour l'instant je me fais un énorme backup

Bon.

J'arrête d'aider sur le topic de Arch.

C'est un débutant à qui il manque énormément de notions de base.

Il va galérer comme pas deux.

« Si tu oublie le paramètre bs de la commande dd, tu risque de devoir attendre une éternité le temps que la copie se fasse. Surtout pour du 1 To. »

Bon j'aimerais juste casser ce mythe une bonne fois pour toutes.

bs = block-size. (cf. devices de type bloc pour la notion de bloc, enfin même sans ça, on peut comprendre normalement)

Cette option indique juste la quantité de bits qui sont copiés d'une traite, "bloc par bloc". Quand on lit des données depuis un device de type bloc par exemple, bah faut s'arranger pour utiliser le bon block-size.

Pour les sceptiques:
julien@Wheatley:~/ddtest$ /usr/bin/time -o 512.log dd if=../nomDeFichierCensuré.tar.gz of=fichier512.tar.gz bs=512
6181151+1 enregistrements lus
6181151+1 enregistrements écrits
3164749476 octets (3,2 GB) copiés, 117,048 s, 27,0 MB/s
julien@Wheatley:~/ddtest$ /usr/bin/time -o 8192.log dd if=../nomDeFichierCensuré.tar.gz of=fichier8192.tar.gz bs=8192
386321+1 enregistrements lus
386321+1 enregistrements écrits
3164749476 octets (3,2 GB) copiés, 120,735 s, 26,2 MB/s
julien@Wheatley:~/ddtest$ /usr/bin/time -o 32768.log dd if=../nomDeFichierCensuré.tar.gz of=fichier32768.tar.gz bs=32768
96580+1 enregistrements lus
96580+1 enregistrements écrits
3164749476 octets (3,2 GB) copiés, 118,557 s, 26,7 MB/s

Vous constatez que les durées et les débits sont les mêmes en moyenne.
La seule chose qui change c'est le nombre d'enregistrements lus et écrits, en toute logique. (notion de bloc, toujours)

Les fichiers de log sont moisis par contre (mal formatés, ça en devient peu lisible, et de toutes façons les durées sont sensiblement les mêmes d'une fois sur l'autre), donc je ne vais pas les coller ici. (sauf si vous insistez, mais quand je vous dis que c'est moche...)

PS: je censure le nom de fichier car ce sont des backups en rapport avec mon taff, donc pas besoin de divulguer ça ici.

Boarf c'est pas du méga-sensible non-plus (un backup de serveur pour être précis, enfin de /home de serveur), mais ça contient le FQDN de la machine donc j'ai préféré éluder ça. (d'autant plus que ça n'a aucun intérêt dans ce test, et que ça prend plus de place que le substitut en question )

Bref sinon, j'ai maintenant un autre mystère à résoudre, celui de bash qui possède manifestement sa propre commande time, sauf qu'elle ne gère pas l'option -o (ni les autres options du vrai /usr/bin/time , je suppose), donc ça fait un peu chier.

N3hxus, faut bien se faire les dents que j'dirais, si tu savais les conneries que j'ai fait avec mes systèmes...

Mais je comprends que tu trouves ça chiant à force.

Google: Backup avec tar et gunzip/bzip2? Ca, si c'est bien ça, fonctionne bien? Les gains de performances de bzip2 compensent-elles le temps nécessaire pour compresser?

Gzip, pas Gunzip

"Haut les mains, je suis armé d'un Gunzip!"

J'ai rien contre dd mais je me suis assez planté pour manier ça juste pour mes clé usb.

Je vais pas tenter le diable hein.

Sinon pour ta question sur la compression, faut juste choisir un algo pas trop moisi (genre le zip ) et savoir faire un compromis rapidité / taille de l'archive finale.

Pour compresser assez simplement, on peut remercier le système de pipeline bien connu ici

Genre :

$ dd if=foo of=bar | tar bar

m'enfin c'est pour schématiser

Il y manque pleins d'arguments.

Tu peux même rajouter un autre pipe qui finalise en faisant du chiffrement.

Au fait Knakis, ma commmande t'as aidé pour libxpcom ?

Nh3xus Ok , merci pour la précision, je note.

Par contre j'aime bien comprendre la théorie, donc si une ame charitable veux bien apporter les réponses à mes questions, je les lirai, même si je n'exploite pas.

Google_bot je suis surpris, sur des gros fichiers je pensais qu'effectivement un bs important réduisait le temps effectif de l'opération

Ouais, nickel, tout fonctionne, merci.

J'vais voir avec bzip2 si c'est pas "trop" lent.

Y0sheY; Tu cherches quoi?

Euh, juste en passant, tar ne compresse rien, il archive (=un fichier qui regroupe toute une section d'arbo), donc le pipe dans tar ne compresse pas vraiment.

tar cvf - monRepertoireAArchiver | gzip monArchiveCompressee.tar.gz

Là, ça compresse.

arsenicbottle Je ne sais pas d'où vient cette rumeur, ni le terme erroné de "byte-speed" pour bs.

Ah ben ça alors

J'en apprends aussi tous les jours.

Merci, je prends note.

Je peux même te donner une précision: tar tire son nom de "Tape ARchive", archive sur bande magnétique.
Car à l'époque d'UNIX (et encore de nos jours en fait...), on plaçait ces fameuses archives sur des bandes magnétiques.

Bon d'ailleurs je dis "l'époque d'UNIX" mais UNIX est toujours bien vivant en fait, donc on va dire "à l'époque de naissance d'UNIX", voilà.

Je passe mon tour, jamais utilisé systemd (et jamais rencontré cette erreur avec udev de manière générale d'ailleurs), je ne vois même pas pourquoi il essaie de renommer ton interface ce naze.
S'il n'arrive pas à le renommer, on devrait en conclure que ladite interface garde le nom "eth0" nope?

Que donne `ifup eth0` lancé en tant que root du coup?

bs me fait penser à block size