A cópia para um disco de tamanho idêntico causará problemas se o disco de saída tiver setores defeituosos?

1

Acabei de fazer uma cópia de um disco de 160GB para outro disco idêntico de 160GB, usando o comando

sudo dd if=/dev/sda of=/dev/sdb

(roda em um live CD do Ubuntu)

No entanto, o teste SMART em /dev/sdb mostra 20 setores defeituosos. Isso significa que existem 20 buracos nos dados que acabei de copiar de um disco para outro? Existe alguma coisa que eu possa fazer para corrigir isso copiando outra maneira?

Editar: saídas adicionadas:

sudo fsck -c -v / dev / sda1 /

fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
Checking for bad blocks (read-only test):   0.00% done, 0:00 elapsed. (0/0/0 errdone                                                 
Lubuntu: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

Lubuntu: ***** FILE SYSTEM WAS MODIFIED *****

  275092 inodes used (4.30%)
    1888 non-contiguous files (0.7%)
     583 non-contiguous directories (0.2%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 241132/283/2
 6505902 blocks used (25.41%)
       0 bad blocks
       1 large file

  208425 regular files
   28234 directories
      57 character device files
      25 block device files
       1 fifo
      41 links
   38340 symbolic links (33583 fast symbolic links)
       1 socket
--------
  275124 files

sudo fsck -c -v / dev / sdb1

fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
Checking for bad blocks (read-only test):   0.00% done, 0:00 elapsed. (0/0/0 errdone                                                 
Lubuntu: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

Lubuntu: ***** FILE SYSTEM WAS MODIFIED *****

  275092 inodes used (4.30%)
    1888 non-contiguous files (0.7%)
     583 non-contiguous directories (0.2%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 241132/283/2
 6505902 blocks used (25.41%)
       0 bad blocks
       1 large file

  208425 regular files
   28234 directories
      57 character device files
      25 block device files
       1 fifo
      41 links
   38340 symbolic links (33583 fast symbolic links)
       1 socket
--------
  275124 files
    
por Blue Ice 03.07.2014 / 05:22

1 resposta

2

poderia . Em teoria, seu sistema de arquivos e as unidades devem apenas contornar isso. Ao trabalhar com discos danificados, tenho a tendência de favorecer uma variância dd centrada na recuperação, como gnu ddrescue (não confundir com a outra, ddrescue antiga), uma vez que eles tentarão novamente em setores defeituosos após dados é copiado. Em seguida, eu executaria um utilitário de verificação de sistema de arquivos adequado, como chdsk ou fsck, para garantir que o arquivo system seja íntegro.

No entanto, olhando para a saída, você deve estar bem. Os gnomos mágicos do seu sistema fizeram um ótimo trabalho; p

    
por 03.07.2014 / 06:58