Como clonar corretamente um SSD ligeiramente danificado em um novo

Question

Então, recentemente, meu antigo SSD (contendo partições / root + / home para meu sistema) quebrou (detalhes nesta questão ) e eu fui buscar uma nova. Agora eu queria clonar, mas encontrei os seguintes problemas:

$ pv /dev/sdd > /dev/sda
4.24GiB 0:00:18 [ 234MiB/s] [==>                          ]  7% ETA 0:03:55
pv: /dev/sdd: read failed: Input/output error

$ dd if=/dev/sdd of=/dev/sda bs=1M status=progress
dd: error reading '/dev/sdd': Input/output error
4397+1 records in
4397+1 records out
4611493888 bytes (4.6 GB, 4.3 GiB) copied, 22.0249 s, 209 MB/s

O velho SSD ainda funciona. Há muitos congelamentos do sistema devido a ele estar danificado, mas posso desbloqueá-lo, montá-lo e usá-lo ainda bem. Eu posso acessar todos os dados (AFAIK) e um backup completo usando tar funcionou bem também.

Os motivos pelos quais eu preferiria um clone direto sobre a cópia arquivo por arquivo (ou tar ) são:

1. Conveniência
2. Velocidade
3. Criptografia bastante complexa no disco, que eu prefiro não reinstalar novamente

Este site sugere usar conv=noerror com dd , mas não tenho certeza se isso é seguro ou não. Eu tenho as mesmas preocupações sobre dd_rescue e -rescue do clonezilla.

Pergunta : Como posso clonar com segurança meu antigo SSD no novo, e é uma md5sum suficiente para garantir que o clone tenha 100% de sucesso?

O site que eu vinculei acima sugere o uso do gparted para verificar se o clone foi bem-sucedido, mas o Gparted do AFAIK não funciona com as partições criptografadas do LUKS. (Para tornar as coisas mais complicadas: o cabeçalho LUKS é desanexado.)

Pergunta bônus : A decodificação do meu disco é feita na inicialização, usando o grub e o ID das partições (não o UUID). É o suficiente para eu atualizar o ID na configuração do meu crypttab e do grub ou preciso fazer mais?

Editar : Acabei de perceber que md5sum provavelmente não conseguirá ler a unidade também. Existe alguma outra maneira de dizer com segurança se o clone foi bem sucedido?

UPDATE: Então eu tentei o clonezilla com a opção -rescue . parecia funcionar e eu posso desbloquear o contêiner LUKS para revelar o LVM, mas quando tento montar a partição raiz, recebo o seguinte:

$ sudo mount /dev/mapper/vvg-root /mnt/sda
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vvg-root,
       missing codepage or helper program, or other error

Dados relevantes de dmesg :

[ 4686.401702] JBD2: no valid journal superblock found
[ 4686.401707] EXT4-fs (dm-3): error loading journal

Então, acho que não funcionou como planejado. Alguém tem uma ideia melhor, por favor?

UPDATE2: eu executei um fsck.ext4 -yv na partição da nova unidade. Eu fui inundado com erros. Nos milhões. Agora eu sou capaz de montá-lo, mas praticamente todos os meus arquivos estão faltando. O diretório / home, entre muitos outros, desapareceu completamente. Deve haver cerca de 30-35GB de dados nele. Agora são 53MB.

A minha única opção é realmente reverter o backup de tar que tenho? Eu estou pensando que talvez uma cópia rsync um-a-um seja melhor, já que isso informaria se um arquivo específico está danificado / ilegível, certo? Eu usei --verify quando fiz o arquivo tar e ele não relatou erros.

    

Answer 1

^{Depois de fazer o que afirmei na minha pergunta, acabei fazendo o seguinte: 1) Remova o LVM no novo SSD após a cópia falhada do CloneZilla.
2) Mantive a cripta dm externa intocada, pois funcionou bem.
3) Recriei um novo LVM e redimensionei tudo para caber no novo (maior) SSD.
(Isso só é relevante para o meu caso, daí a fonte menor, ver pergunta atualizações)}

Agora, para a clonagem:

1) Eu montei ambas as partições de raiz de SSDs normalmente em um sistema vivo depois de desbloqueá-las:

# unlock the LUKS containers with cryptsetup first
mount /dev/mapper/ovvg-root /mnt/oldssd
mount /dev/mapper/vvg-root /mnt/newssd

2) Eu usei o rsync para clonar os arquivos:

rsync -ahv --progress /mnt/oldssd /mnt/newssd

3) Confirmado que o tamanho de todas as pastas corresponde:

du -cs /mnt/oldsdd/* && echo " " && du -cs /mnt/newssd/*

4) Confirmado que todos os arquivos estão lá, para verificar novamente:

find /mnt/oldssd | cut -d "/" - f 4- | sort > oldssd.txt
find /mnt/newssd | cut -d "/" - f 4- | sort > newssd.txt
diff oldssd.txt newssd.txt

Oito arquivos não estavam presentes em newssd.txt , então presumo que os erros tenham sido lidos. Acabei deixando esses arquivos sozinhos pois tenho backups, vou copiá-los manualmente depois.

5) Satisfei minha paranóia, verificando checksums:

cd /mnt/oldssd && find . -type f -exec md5sum {} \; | sort > /root/oldssd_md5.txt
cd /mnt/newssd && find . -type f -exec md5sum {} \; | sort > /root/newssd_md5.txt
cd /root && diff oldssd_md5.txt newssd_md5.txt

Nenhuma saída - significa que cada arquivo é o mesmo!

Quanto à questão bônus:

1) Alterar o caminho do dispositivo (usando UUID) em /etc/fstab
2) Alterar o caminho do dispositivo (usando by-id ) em /etc/default/grub
3) Como não posso chroot no meu sistema agora, eu modifiquei o grub.cfg diretamente para refletir a mudança do by-id do disco - No entanto, a melhor prática é não fazer isso e, em vez disso, chroot no sistema raiz e configure o bootloader do GRUB. Eu imediatamente fiz isso depois de ser inicializado no sistema a partir do novo SSD.

Mais complicado do que eu gostaria que fosse, mas pelo menos funcionou, com segurança.

    

Answer 2

Primeiramente, eu recomendo não usar o SSD ou executar testes nele, pois isso pode fazer com que a unidade continue falhando. Tive uma vez uma unidade que estava sendo reparada e depois de executar algumas verificações de integridade nela, Deixe-se ler em tudo. Se você ainda é capaz de vê-lo a partir de um sistema separado, ele ainda pode ser salvo, embora o uso possa fazer com que os chips parem de ler, então eu tentaria um clone completo antes de fazer qualquer outra coisa. Eu recomendo usar o Clonezilla do USB para manter o SSD longe de leitura / escrita desnecessária durante a clonagem. Quando você clonou, o md5sum seria a melhor maneira de confirmar se tudo está lá, embora possa não ser confiável se falhar. Um bônus para usar um cloner OS ou cloner de hardware é que todos os dados são copiados setor por setor.