Comment pourrais-je accélérer un disque plein?

Je fais un ddsur deux lecteurs identiques avec cette commande:

 dd if=/dev/sda of=/dev/sdb bs=4096

Les deux disques durs portent exactement le même numéro de modèle et disposent chacun de 1 To d'espace de stockage. /dev/sda utilise une taille de bloc de 4096. /dev/sdaest un lecteur local et /dev/sdbun caddy distant. Je pourrais peut-être utiliser les protocoles suivants:

• USB 2.0 Haute Vitesse (actuellement le plan)
• Clone Gigabit Over-The-Network (vous ne voulez même pas essayer cela)
• USB3.0 (si je trouve mon autre caddy)
• eSATA (si je trouve / achète un câble)
• SATA (si je trouve / achète un câble, je dois aimer les lecteurs de CD pour ordinateurs portables)

Existe-t-il un moyen d’exécuter cette copie de disque en moins de 96 heures? Je suis ouvert à l’utilisation d’outils autres que dd.

J'ai besoin de cloner les partitions suivantes (y compris les UUID)

• Partition Fat32 EFI (*)
• Partition Windows NTFS (*)
• Partition HFS + OSX
• Partition EXT4 Ubuntu (*)
• Partition Swap (*)

* Soutenu par Clonezilla

J'ai essayé Clonezilla (et c'était BEAUCOUP plus rapide), mais il ne prend pas en charge la copie intelligente HFS +, ce dont j'ai besoin. Peut-être que la nouvelle version prend en charge cela?

Lorsque j'ai fait mon premier clone, j'ai créé toutes les partitions sauf HFS + et tout s'est passé très vite. (Pas plus de 3 heures au total)

D'après mon expérience, je ne pense pas qu'il y ait quelque chose de plus rapide dans la ligne de commande que dd. Le réglage du bsparamètre peut augmenter la vitesse. Par exemple, j'ai deux disques durs dont je sais qu'ils ont une vitesse de lecture / écriture supérieure à 100 Mo / s.

dd if=/dev/sda of=/dev/sdb bs=100M

Il y a aussi pv(Doit être installé en premier) qui vérifie la vitesse la plus rapide sur les deux disques puis procède au clonage. Cela doit être fait bien sûr à partir de la racine:

pv < /dev/sda > /dev/sdb

Avec le PV, j'ai 156 Mo / s

La bonne chose à pvpart la vitesse, c’est qu’elle indique la progression, la vitesse actuelle, le temps écoulé depuis le début et l’ETA. En ce qui concerne HFS +, je ne le saurais pas. J'essaie simplement d'aider sur la partie "rapidité". Avec pvun bsparamètre très optimisé , vous pouvez réaliser un disque de 4 To en moins de 7 heures (6 heures 50 minutes à une vitesse actuelle de 150 Mo / s).

J'ai fait quelques tests avec les types de connexion que vous utilisiez et d'autres que j'avais disponibles. J'utilisais l'Asus Z87 Pro et l'Intel DZ68DP. C’était mes résultats, mais nous devons d’abord savoir que les vitesses théoriques de nombreux taux de transfert (vitesses brutes) ne sont que la théorie . Faire de vrais tests a révélé qu'ils représentent entre 40% et 80% de cette vitesse brute. Ces tests peuvent varier en fonction du périphérique utilisé, du type de connexion, de la carte mère, du type de câble de connexion, du type de système de fichiers, etc. Dans cet esprit, voici ce que j’ai eu (j’ai seulement testé la vitesse d’écriture sur le périphérique, la lecture est généralement plus élevée):

Connected Device  -  Connection Type  -  Speed (Write Speed)
  USB 2.0                 USB 2.0              25 MB/s
  USB 3.0                 USB 2.0              35 MB/s
  USB 3.0                 USB 3.0              73 MB/s
  eSata                   eSata                80 MB/s
  Sata 2G HDD             Sata 2G              120 MB/s
  Sata 3G HDD             Sata 2G              140 MB/s
  Sata 3G HDD             Sata 3G              190 MB/s
  Sata 2G SDD             Sata 2G              170 MB/s
  Sata 3G SDD             Sata 2G              210 MB/s
  Sata 3G SDD             Sata 3G              550 MB/s 

Pour copier une partition en gros, utilisez catplutôt quedd . J'ai exécuté des tests de performance il y a quelque temps, en copiant un fichier volumineux plutôt qu'une partition, entre deux disques (sur le même disque, les timings relatifs sont différents):

dd bs=64M    51.3
dd bs=1M     41.8
dd bs=4k     48.5
dd bs=512    48.9
cat          41.7
cp           45.3

La conclusion de ce point de référence est que le choix de la taille de bloc pour les ddquestions (mais pas tant que ça), et cattrouve automatiquement le meilleur moyen de faire une copie rapide: ddne peut que vous ralentir. Avec une petite taille de bloc, vous ddperdez du temps en perdant des lectures et écritures minuscules. Avec une taille de bloc importante, un disque reste inactif pendant que l’autre lit ou écrit. Le taux optimal est atteint lorsqu'un disque lit pendant que l'autre disque écrit.

Pour copier une partition, il peut être plus rapide de copier les fichiers avec cp -a. Cela dépend du nombre de fichiers et de la quantité d'espace disponible du système de fichiers. La copie de fichiers entraîne une surcharge à peu près proportionnelle au nombre de fichiers, mais la copie d’espace libre vous fait perdre du temps.

Le débit de données maximum pour USB2 est un peu inférieur à 50 Mo / s, ce qui donne un délai de transfert de 1 To entre 6 et 7 heures. Cela suppose un disque dur suffisamment rapide pour saturer le bus USB; Je pense que les disques plus rapides à 7 200 tr / min peuvent le faire, mais que 5900 tr / min peut ne pas être aussi rapide (peut-être sont-ils destinés aux écritures linéaires?).

Si l’un des disques est utilisé en parallèle, cela peut ralentir considérablement la copie car les têtes de disque doivent se déplacer.

Le problème est votre type de connexion et votre taille de bloc. Pour des résultats plus rapides, la taille de votre bloc doit être deux fois moins rapide que la vitesse d'écriture la plus faible. Cela vous donnera une marge de sécurité, tout en permettant un nombre élevé; Bien entendu, vous devez également disposer de suffisamment de RAM pour stocker les données.

Usb 2.0 est de 12 mégabits par seconde (Mbps), Usb 2.0 haute vitesse est de 480 Mbps. C'est bien sûr la vitesse brute; avec 8 bits dans un octet et une surcharge de cadrage, la vitesse utilisable en Mo / s correspond généralement à une décimale. Ainsi, par exemple, 480 bruts deviennent 48 Mo utilisables. N'oubliez pas que c'est le meilleur calcul mathématique, dans le monde réel, il sera un peu plus bas. Pour les connexions haut débit USB 2.0, vous pouvez vous attendre à une vitesse d’écriture maximale d’environ 30 à 35 Mo, à condition que le périphérique de stockage réel puisse égaler ou dépasser les vitesses de connexion.

Je conviens que la vitesse brute d'une commande bien réglée dd("pv") ou "cat" est difficile à battre, mais s'il y a un problème avec la copie (secteur défectueux, coupure de courant, erreur de l'utilisateur, etc.), vous devez commencer plus de.

Je voudrais suggérer ddrescue - un outil FOSS qui a toute la vitesse de dd, mais il permet de contourner les erreurs de disque et de le reprendre ultérieurement en cas de défaillance.

Je déplace Windows 7 d'un disque dur vers un disque SSD et trouve ceci et quelques autres réponses ... Quelque chose que j'ai appris qui pourrait aider les autres. Dans mon cas, le lecteur source est plus gros, sinon j'aurais travaillé au niveau du périphérique / dev / sda -> / dev / sdb.

Win7 et ses 3 partitions ... J'ai utilisé Xbuntu 14.04 live cd sur un usb. J'ai sorti le DVD de l'ordinateur gagnant et mis le SSD à sa place. Partclone installé et essayé ceci:

partclone.ntfs -b -N -s /dev/sda3 -o /dev/sdb3

Partclone a vomi sur les ntfs nécessitant l'exécution de chkdisk sous Windows, donc une solution rapide a rendu partclone heureux:

ntfsfix -b /dev/sda3
ntfsfix -d /dev/sda3

Toutes les commandes sont exécutées en tant que root. L'interface utilisateur ncurses de Partclone (l'option -N) indique que le transfert a été effectué à 7 Go / min et qu'il s'est terminé à 5 Go / min, ce qui équivaut à 83 Mo / s. La bonne partie est que partclone ne copie pas l'espace inutilisé, ce qui a rendu le clone remarquablement rapide.

Gotchyas potentiels supplémentaires:

• Si le lecteur sur lequel vous effectuez le transfert a déjà été utilisé, il peut contenir des traces d'un TPG. Les installations d’usine de Windows 7 sont généralement des tables de partitions msdos / mbr. Vous devrez supprimer les fragments GPT du lecteur de destination. Ce QA Unix et Linux m'a aidé avec cela. Vous devez utiliser gdisksur le périphérique, utilisez x puis z et oui pour zapper les données GPT et vous assurer de GARDER le MBR.

• Et n'oubliez pas que si vous ne faites pas un dd de niveau périphérique, vous devrez copier le MBR en utilisant
  dd if=/dev/sdb of=/dev/sda bs=446 count=1
  sdb comme source ou ancien lecteur et sda comme destination ou nouveau lecteur ( source ).

J'ai récemment créé une image d'une partition de 100 Go (disque dur) et je l'écris sur le nouveau disque SSD.

Voici un conseil qui peut considérablement accélérer le processus :)

Fractionner le fichier en parties plus petites (plus le fichier est gros, plus il fonctionne lentement)

sudo dd if=/dev/sda3 conv=sync,noerror bs=2M | split -a 3 -d -b 1G - /maindisk.img

Pendant le processus, vous pouvez vérifier la vitesse en utilisant (dans un terminal séparé)

pgrep -l '^dd$' #to find PROCESSID
kill -USR1 PROCESSID #to check the speed

Ensuite, lorsque vous avez un répertoire plein de fichiers de résultats (maindisk.img000, maindisk.img001, etc.), utilisez

sudo cat maindisk.img* | sudo dd of=/dev/sda1

pour "graver" l'image dans la nouvelle partition de SSD (la taille doit être de la même taille que l'ancienne)

Pour moi, cela a fonctionné plus vite que d'habitude (sans se fendre). La vitesse moyenne de création de l’image était d’environ 13 Mo / s. Lorsque j'utilise la méthode "normale", elle commence à ~ 15 Mo / s, puis diminue à 1 Mo / s.

Pour ceux qui trouvent ce fil, il est beaucoup plus facile et rapide d’utiliser un outil conçu pour la récupération de données, comme ddrescue . Il essaie d'abord de récupérer les bonnes parties en cas d'erreur de lecture. Aussi, vous pouvez interrompre le sauvetage à tout moment et le reprendre plus tard au même moment.

Exécutez-le deux fois:

Tout d’abord, copiez chaque bloc sans erreur de lecture et enregistrez les erreurs dans rescue.log.

sudo ddrescue -f -n /dev/sdX /dev/sdY rescue.log

Deuxième tour, copiez uniquement les blocs défectueux et essayez 3 fois de lire à partir de la source avant d'abandonner.

sudo ddrescue -d -f -r3 /dev/sdX /dev/sdY rescue.log

Maintenant, vous pouvez monter le nouveau disque et vérifier le système de fichiers pour la corruption.

Plus d'infos:
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html

Id recommande que le disque d'entrée / lecture-fichier / disque soit sur SATA pour augmenter les vitesses de lecture. L’USB 2.0 haut débit est bon aussi, car j’obtiens des débits moyens de 33 816 kb / s avec ddrescue par rapport au mode de configuration USB 2.0 vers SATA à 2014 kb / s.

Utilisez une taille de bloc différente. C'est la quantité de données qui se ddlit à la fois. Si vous lisez trop peu, vous passerez plus de temps dans la logique du programme et si vous en lirez trop, vous passerez beaucoup de temps à déplacer les grandes données.

Pour mesurer la vitesse à différentes tailles de bloc, utilisez le bashscript suivant :

• mis $devà l'appareil
• correction cbtotalpour être au moins 5 fois plus rapide que votre vitesse de lecture

    (set -o errexit; skip=0; cbtotal=$((120*1024**2)); bs=256;
    for power in `seq 10`; do
      bs=$((bs*2)); skip=$((skip/2)); count=$((cbtotal/bs));
      if [ "$count" -lt 1 ]; then break; fi;
      echo $bs;
      dd if=$dev of=/dev/null skip=$skip bs=$bs count=$count
      skip=$((skip+count))
    done)

Le résultat peut être biaisé en faveur d'une taille plus grande en raison de la lecture anticipée du disque - c'est pourquoi il est important de définir une cbtotaltaille suffisante.