Comment pourrais-je accélérer un disque plein?
Je fais un dd sur 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/sda est un lecteur local et /dev/sdb est un 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 (*)
* Pris en charge par Clonezilla
J'ai essayé Clonezilla (et c'était BEAUCOUP plus rapide), mais il ne prend pas en charge la copie intelligente HFS +, 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 fait d'ajuster le paramètre bs 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 existe également 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 à propos de pv (mis à part la vitesse) est qu’il affiche 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 pv ou un paramètre très optimisé bs, vous pouvez effectuer un lecteur 4 TB en moins de 7 heures (6 heures 50 minutes à la 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 cela, 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
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 devez 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.
Pour copier une partition en gros, utilisez cat au lieu de dd. J'ai lancé benchmarks 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 repère est que le choix de la taille de bloc pour dd (importe peu), et cat trouve automatiquement le meilleur moyen de faire une copie rapide: dd ne peut que vous ralentir. Avec une petite taille de bloc, dd perd du temps en perdant de minuscules lectures et écritures. 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 en revanche, la copie d’espace perd 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 les plus rapides à 7 200 tr/min peuvent le faire, mais que les 5900 tr/min ne sont peut-être pas aussi rapides (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.
Je conviens que la vitesse brute d'une commande dd ('pv') ou 'cat' bien réglée est difficile à battre, mais s'il y a un problème avec la copie (secteur défectueux, panne d'alimentation, erreur de l'utilisateur, etc.), alors vous devez recommencer.
Je voudrais suggérer ddrescue - un outil de logiciel libre 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 disque 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. Ceci nix & Linux QA m'a aidé avec cela. Vous devez utiliser
gdisksur le périphérique, utiliser 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 périphérique de niveau dd, vous devrez copier le MBR à l'aide de
dd if=/dev/sdb of=/dev/sda bs=446 count=1
où sdb est le lecteur source ou l'ancien et sda le destinataire ou le 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 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 tel que 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
Au second 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'informations:
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
Utilisez une taille de bloc différente. C'est la quantité de données que ddlit à la fois. Si vous lisez trop peu, vous passerez plus de temps dans la logique du programme et si vous lisez trop, vous passerez beaucoup de temps à déplacer les grandes données.
Pour mesurer la vitesse à différentes tailles de bloc, utilisez le script bashsuivant:
- définir
$devsur le périphérique - corrige
cbtotalpour qu'il soit 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 suffisamment cbtotalname__.
Id recommande que le disque d'entrée/lecture-fichier/disque soit sur SATA pour augmenter les vitesses de lecture. L’USB 2.0 haute vitesse est bon aussi car j’obtiens des vitesses moyennes de 33816 kb/s avec ddrescue par rapport à la date de le réglage était USB 2.0 à SATA à 2014 kb/s