Movendo para o ssd: faça uma nova instalação; ou é "dd" do antigo hdd "bom o suficiente"?

Question

nossa administração generosa considera distribuir SSDs para substituir os HDDs em nossos laptops.

Disseram-me que os SSDs terão o mesmo tamanho que os HDDs; então eu estou agora querendo saber: eu deveria simplesmente usar "dd" para copiar minha instalação 14.04 do xubuntu existente (e talvez depois, faça as afinações listadas para essa questão relacionada )?

Ou existem grandes vantagens "técnicas" em fazer uma instalação "completamente nova" do xubuntu naquele SSD?

Em outras palavras: uma cópia tão "binária completa" terá algum efeito negativo sobre o desempenho do SSD, o armazenamento em cache ...?

EDIT no. 2: minha instalação atual foi criada usando o instalador do ubuntu "padrão"; o que significa que usa LUKS e LVM. Fornecendo algumas informações de baixo nível:

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

    

Answer 1

Se as duas unidades tiverem o mesmo tamanho, clonar a unidade de origem na unidade de destino usando dd terá exatamente o mesmo impacto que uma gravação completa do disco de destino teria.

Antes mesmo de começar a considerar se isso é um problema ou não, se você precisa de tudo que já tem na unidade antiga e isso é "completo o suficiente", não deve haver mais perguntas: dd irá salvá-lo muito tempo sem desgastar a unidade de destino muito mais do que uma instalação limpa teria feito.

Dito isso, uma gravação completa do disco de destino uma vez é não significativa. Nem mesmo um segundo e um terceiro seria.

Um SSD comercial de MLC vai recuperar entre 2000-3000 gravações completas. Não falar sobre SLC SSDs.

O que é relevante é como você usará a nova unidade ao longo do tempo. Se o SSD for submetido a um grande número de ciclos de Programa / Apagar (por exemplo, criação / exclusão / criação de arquivos), sua vida útil diminuirá drasticamente.

Então, para resumir, eu procuraria cegamente a solução dd e, em vez disso, prestaria atenção em como não diminuir seu tempo de vida fazendo uso inteligente dela ao longo do tempo.

    

Answer 2

Há uma boa chance de mover todos os dados usando as ferramentas do LVM. Há breves informações sobre como fazer isso:

1. Obtenha o conector USB do disco SSD e conecte-o ao laptop com o SSD conectado

2. Reparticione seus dispositivos da mesma forma que seu disco atual (na verdade, não importa como, mas sua nova partição LUSK deve ser igual ou maior que sua partição LUKS atual

3. Copie sua partição de pasta de inicialização para a nova partição SSD. Se o seu SSD foi detectado como / dev / sdb, você pode seguir estes passos:

   sudo mkfs.ext2 /dev/sdb1

   sudo mount /dev/sdb1 /mnt

   sudo rsync -a /boot/* /mnt/

   sudo umount /mnt

4. Configure a partição crypt no seu / dev / sdb2 (segunda partição do novo disco SSD) e anexe-a ao seu atual VG (grupo de volume LVM)

   sudo cryptsetup -y luksFormat /dev/sdb2

   sudo cryptsetup luksOpen /dev/sdb2 crypt_ssd

   sudo vgextend xubuntu-vg /dev/mapper/crypt_ssd

5. Mova os dados físicos da sua partição física atual para a nova partição física do SSD (certifique-se de que pode ser longa, verifique se você tem uma strong conexão USB com o seu SSD, NÃO haverá INTERRUPÇÕES)

   sudo pvmove /dev/mapper/sda5_crypt

Ele moverá automaticamente todos os dados para sua partição física criptografada em SSD livre.

6. Como toda a movimentação estará on-line, você deve verificar o novo UUID da partição de inicialização

   sudo blkid

Encontre lá / dev / sdb1 (sua nova partição de inicialização) e edite a entrada / etc / fstab / boot UUID de acordo (sim, todos os arquivos já no novo disco SSD, da próxima vez você pode inicializar apenas com este disco anexado)

7. Remover disco antigo do grupo de volumes

   sudo vgreduce xubuntu-vg /dev/mapper/sda5_crypt

8. Cruze os dedos e reinicie (eu fiz cerca de dez mudanças, mas sem usar o LUKS, pois vejo que você deve digitar a senha na inicialização para abrir seus dispositivos

Não faça isso se você não sabe nada sobre LUKS ou LVM, são apenas recomendações, sinta-se à vontade para perguntar algo ou consultar seu engenheiro. Não quero que você perca dados. Eu sugiro assim porque dd para o dispositivo 500G realmente não é bom. Há quase a mesma questão que Como migrar uma instalação criptografada do LVM para um novo disco mas eles criaram o novo LVM VG e copiam dados usando rsync ( pvmove move dados usando blocos, não arquivos - em outras palavras, pvmove muito mais rápido e não corromperá nenhuma permissão, bits e etc ). E eu acho que vai precisar de alguma edição do / etc / crypttab, mas acredito que não há necessidade de fazer isso. Por favor, faça o backup de todos os dados necessários e obtenha o live-cd ou usb antes desta mudança.

EDITAR:

A propósito, respondendo à sua pergunta principal, eu posso dizer que houve um bug há dois anos atrás que rasgando dados com o pvmove no SSD link . Se você não tem problemas e você não está com licença para fazer novas instalações, na verdade também, para protegê-lo de qualquer desastre.