web-dev-qa-db-fra.com

Passer à ssd: faire une nouvelle installation; ou "dd" du vieux disque dur est-il "assez bon"?

notre direction généreuse envisage de distribuer des disques SSD pour remplacer les disques durs de nos ordinateurs portables.

On me dit que les disques SSD auront la même taille que les disques durs; je me demande donc maintenant: devrais-je simplement utiliser "dd" pour copier mon installation existante de xubuntu 14.04 (et peut-être ensuite, les réglages indiqués pour cette question connexe )?

Ou y a-t-il des avantages "techniques" majeurs à effectuer une installation "complètement nouvelle" de xubuntu sur ce disque SSD?

En d'autres termes: une telle copie "complète binaire" aura-t-elle des effets négatifs sur les performances des disques SSD, la mise en cache ...?

EDIT no. 2: mon installation actuelle a été créée à l'aide du programme d'installation ubuntu "par défaut"; ce qui signifie qu'il utilise LUKS et LVM. Fournir des informations de bas niveau:

Sudo pvs 

  PV                     VG         Fmt  Attr PSize   PFree 
  /dev/mapper/sda5_crypt xubuntu-vg lvm2 a--  465,52g 44,00m

Sudo lvs 

  LV     VG         Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
  root   xubuntu-vg -wi-ao--- 449,83g   
  swap_1 xubuntu-vg -wi-ao---  15,64g

Sudo fdisk -lu 

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00079ee9
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      499711      248832   83  Linux 
/dev/sda2          501758   976771071   488134657    5  Extended
Partition 2 does not start on physical sector boundary.
/dev/sda5          501760   976771071   488134656   83  Linux

Disk /dev/mapper/sda5_crypt: 499.8 GB, 499847790592 bytes
255 heads, 63 sectors/track, 60769 cylinders, total 976265216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/sda5_crypt doesn't contain a valid partition table

Disk /dev/mapper/xubuntu--vg-root: 483.0 GB, 483003465728 bytes
255 heads, 63 sectors/track, 58721 cylinders, total 943366144 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/xubuntu--vg-root doesn't contain a valid partition table
Disk /dev/mapper/xubuntu--vg-swap_1: 16.8 GB, 16793993216 bytes
255 heads, 63 sectors/track, 2041 cylinders, total 32800768 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/xubuntu--vg-swap_1 doesn't contain a valid partition table

cat/etc/fstab 

...
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/xubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=b58b2697-1bf2-4ad3-80bd-4dee61e63fe4 /boot           ext2    defaults        0       2
/dev/mapper/xubuntu--vg-swap_1 none            swap    sw              0       0
hard-drivessd
3
GhostCat

Si les deux lecteurs ont la même taille, le clonage du lecteur source sur le lecteur cible à l'aide de dd aura exactement le même impact qu'une écriture complète du disque cible aurait.

Avant même de commencer à considérer s'il s'agit d'un problème ou non, si vous avez besoin de tout ce que vous avez déjà sur l'ancien disque et que celui-ci est "suffisamment plein", il ne devrait même plus y avoir de questionnement: dd vous fera économiser beaucoup de temps sans épuiser le lecteur cible beaucoup plus que ce qu’aurait fait une installation propre.

Cela dit, une écriture complète du disque cible effectuée ne fois est non significative. Pas même un deuxième et un troisième ne le seraient.

Un MLC SSD commercial va survivre entre 2000 et 3000 écritures complètes. Sans parler de SLC SSD.

Ce qui est pertinent à la place, c'est comment vous utiliserez le nouveau disque au fil du temps. Si le disque SSD doit être soumis à un grand nombre de cycles de programme/suppression (par exemple, création/suppression/création de fichiers), sa durée de vie va considérablement diminuer.

Donc, pour résumer, je choisirais aveuglément la solution dd et préférerais plutôt savoir comment ne pas réduire sa durée de vie en en faisant un usage intelligent au fil du temps.

3
kos

Il y a une bonne chance de déplacer toutes les données en utilisant des outils LVM. Il y a de courtes informations sur la façon de le faire:

  1. Obtenez un connecteur USB pour votre disque SSD et attachez-le à votre ordinateur portable avec SSD connecté

  2. Repartitionnez vos périphériques de la même manière que votre disque actuel (peu importe la méthode, mais votre nouvelle partition LUSK doit être identique ou supérieure à celle de votre partition LUKS actuelle.

  3. Copiez votre partition de dossier de démarrage sur une nouvelle partition SSD. Si votre disque SSD détecté est/dev/sdb, procédez comme suit:

    Sudo mkfs.ext2 /dev/sdb1

    Sudo mount /dev/sdb1 /mnt

    Sudo rsync -a /boot/* /mnt/

    Sudo umount /mnt

  4. Installez la partition cryptée sur votre/dev/sdb2 (deuxième partition du nouveau disque SSD) et attachez-la à votre VG actuel (groupe de volumes LVM)

    Sudo cryptsetup -y luksFormat /dev/sdb2

    Sudo cryptsetup luksOpen /dev/sdb2 crypt_ssd

    Sudo vgextend xubuntu-vg /dev/mapper/crypt_ssd

  5. Déplacez les données physiques de votre partition physique actuelle vers la nouvelle partition physique SSD (assurez-vous que la connexion peut être longue, assurez-vous que la connexion USB est établie avec votre SSD, aucune interruption ne devrait se produire)

    Sudo pvmove /dev/mapper/sda5_crypt

Toutes les données seront automatiquement déplacées vers votre partition physique cryptée SSD gratuite.

  1. Puisque tout le déménagement sera en ligne, vous devriez vérifier le nouvel UUID de la partition de démarrage

    Sudo blkid

Recherchez-y/dev/sdb1 (votre nouvelle partition de démarrage) et modifiez l’entrée UUID/etc/fstab/boot en conséquence (oui, tous les fichiers déjà présents sur le nouveau disque SSD, vous ne pourrez démarrer que lorsque ce disque est connecté)

  1. Supprimer l'ancien disque du groupe de volumes

    Sudo vgreduce xubuntu-vg /dev/mapper/sda5_crypt

  2. Croisez les doigts et redémarrez (j'ai effectué une dizaine de mouvements de ce type, mais sans utiliser LUKS, car je vois que vous devez entrer un mot de passe au démarrage pour ouvrir vos périphériques.

Ne le faites pas si vous ne connaissez rien à LUKS ou à LVM, ce ne sont que des recommandations, n'hésitez pas à demander autre chose ou à consulter votre ingénieur. Je ne veux pas que vous perdiez des données. Je suggère de cette façon parce que dd pour un périphérique 500G vraiment pas bon. Il y a presque la même question ici Comment migrer une installation LVM chiffrée sur un nouveau disque mais ils ont créé un nouveau LVM VG et copient les données à l’aide de rsync (pvmove déplacer les données à l’aide de blocs, et non de fichiers - dans En d'autres termes, pvmove est vraiment plus rapide et ne corrompra aucune autorisation, aucun bit, etc.). Et je pense qu’il sera nécessaire de modifier le fichier/etc/crypttab, mais je pense qu’il n’est pas nécessaire de le faire. S'il vous plaît sauvegarder toutes les données nécessaires et obtenir live-cd ou usb avant ce déménagement.

MODIFIER:

En passant, en réponse à votre question principale, je peux dire qu’il ya un bogue il y a environ deux ans qui détruisait les données avec pvmove sur SSD link . Si vous n’avez pas de problème et que vous n’êtes pas obligé de faire une nouvelle installation, c’est aussi une façon de vous protéger de tout désastre.

2
user3417815