Ao usar o 'rsync' para duplicar uma partição, os tamanhos saem diferentes. Eu deveria me preocupar?

2

Eu tenho usado o rsync no CD do Parted Magic para duplicar minha partição do Ubuntu 14.04LTS em um drive USB como backup. Depois de concluído, o tamanho da unidade USB de destino é maior (> 2,1 GB) do que a unidade SSHD de origem. Eu deveria estar preocupado e por quê?

root@PartedMagic:~# df  
Filesystem     1K-blocks     Used Available Use% Mounted on  
/dev/sdb1      122940824 97847408  18825340  84% /media/sdb1  
/dev/sda3      239541408 95747516 131602840  43% /media/sda3  

Aqui está o script que estou usando atualmente no AP do ROXTerm:

mount /dev/sdb1
mount /dev/sda3
cd /media/sda3
rsync -avpHAX --del --numeric-ids . /media/sdb1/

Aqui está a informação fdisk -l :

root@PartedMagic:/media/sda3# fdisk -l  
Disk /dev/ram0: 16 MiB, 16777216 bytes, 32768 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 /dev/ram1: 16 MiB, 16777216 bytes, 32768 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 /dev/ram2: 16 MiB, 16777216 bytes, 32768 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 /dev/ram3: 16 MiB, 16777216 bytes, 32768 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 /dev/ram4: 16 MiB, 16777216 bytes, 32768 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 /dev/ram5: 16 MiB, 16777216 bytes, 32768 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 /dev/ram6: 16 MiB, 16777216 bytes, 32768 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 /dev/ram7: 16 MiB, 16777216 bytes, 32768 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 /dev/ram8: 16 MiB, 16777216 bytes, 32768 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 /dev/ram9: 16 MiB, 16777216 bytes, 32768 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 /dev/ram10: 16 MiB, 16777216 bytes, 32768 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 /dev/ram11: 16 MiB, 16777216 bytes, 32768 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 /dev/ram12: 16 MiB, 16777216 bytes, 32768 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 /dev/ram13: 16 MiB, 16777216 bytes, 32768 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 /dev/ram14: 16 MiB, 16777216 bytes, 32768 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 /dev/ram15: 16 MiB, 16777216 bytes, 32768 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 /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 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  
Disklabel type: dos  
Disk identifier: 0x5bc53d8b  
Device     Boot      Start        End   Sectors   Size Id Type  
/dev/sda1  *            63  955604991 955604929 455.7G  7 HPFS/NTFS/exFAT  
/dev/sda2        955604992  976766975  21161984  10.1G  7 HPFS/NTFS/exFAT  
/dev/sda3        976766976 1463753951 486986976 232.2G 83 Linux  
/dev/sda4       1463754750 1953523711 489768962 233.6G  5 Extended  
/dev/sda5       1463754752 1572020223 108265472  51.6G 83 Linux  
/dev/sda6       1572022272 1936746495 364724224 173.9G 83 Linux   
/dev/sda7       1936748544 1953523711  16775168     8G 82 Linux swap  
Partition 1 does not start on physical sector boundary.  
Partition 4 does not start on physical sector boundary.  
Disk /dev/sdb: 119.2 GiB, 128035323904 bytes, 250068992 sectors  
Units: sectors of 1 * 512 = 512 bytes  
Sector size (logical/physical): 512 bytes / 512 bytes  
I/O size (minimum/optimal): 512 bytes / 512 bytes  
Disklabel type: dos  
Disk identifier: 0xd25c4889  
Device     Boot Start       End   Sectors   Size Id Type  
/dev/sdb1  *       63 250067789 250067727 119.2G 83 Linux
    
por Mark L Keppinger 23.01.2016 / 22:46

2 respostas

0

Isso não é nada para se preocupar. A razão pela qual isso acontece é devido a algumas coisas. A primeira é a informação do sistema na tabela de partições. Quando você copia uma partição, você só copia os arquivos do usuário para um novo, e todos os arquivos temporários no antigo são deixados em paz. Outro fator é a questão de longa data das unidades de memória da base 10. Isso também é reconhecível em pen drives e HDDs (já notou como eles têm menos memória do que o que é dito no pacote? Isto é devido aos cálculos de memória na base 10). E outro problema poderia ser apenas um erro do usuário. Se você não tiver direitos em um diretório ou se alguma outra coisa impedir você de copiá-lo, os arquivos não serão espelhados na nova partição. Espero que isso ajude.

    
por TechnicalTophat 24.01.2016 / 00:09
0

Obrigado por todas as respostas. Eles me ajudaram a diminuir onde e por que eu estava tendo problemas. Um fato que descobri recentemente que impactou esse problema foi que a partição de origem era uma partição estendida, enquanto a partição de destino era uma partição primária. Depois que mudei a partição de destino para uma partição estendida, os números são quase idênticos. Portanto, o 1000 vs 1024 está relacionado a partições primárias vs estendidas. Eu suspeito que as poucas diferenças de xK que agora têm a ver com setores defeituosos (a verdade de diff - evangelho - ainda não mostra diferença).

Aqui está uma df com a unidade USB conectada e outra sem a unidade USB (/ dev / sdb5) conectada, quando inicializada a partir da unidade SSD ( /dev/sda6 ). Apenas uma diferença de 8K. Observe o nome da partição do diretório / nos dois df s. IMO, um bug visual que deve ser reportado ao pessoal do Ubuntu:

:~# df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev             1008240        8   1008232   1% /dev
tmpfs             203808     1200    202608   1% /run
/dev/sdb5       32896880 12291920  18910868  40% /
none                   4        0         4   0% /sys/fs/cgroup
none                5120        0      5120   0% /run/lock
none             1019020    16400   1002620   2% /run/shm
none              102400       40    102360   1% /run/user
/dev/sdb1       16382888  3650412  11877240  24% /media/markk/Ubuntu 15.10
/dev/sdb2        1125376    26325   1099051   3% /media/markk/Boot
/dev/sda1         323580    58804    264776  19% /media/markk/SYSTEM
/dev/sda2       91773948 62945400  28828548  69% /media/markk/D345EB1A3E8C47E1
/dev/sda7       72539432  3274148  65557380   5% /media/markk/519c4876-b4b6-43e5-8876-1656394e69a9

:~# df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev             1008240        8   1008232   1% /dev
tmpfs             203808     1180    202628   1% /run
/dev/sda6       32896880 12291912  18910876  40% /
none                   4        0         4   0% /sys/fs/cgroup
none                5120        0      5120   0% /run/lock
none             1019020    16368   1002652   2% /run/shm
none              102400       40    102360   1% /run/user
/dev/sda1         323580    58804    264776  19% /media/markk/SYSTEM
/dev/sda2       91773948 62945400  28828548  69% /media/markk/D345EB1A3E8C47E1
/dev/sda7       72539432  3274148  65557380   5% /media/markk/519c4876-b4b6-43e5-8876-1656394e69a9

Uma nota adicional para aqueles que desejam executar backups em uma unidade USB inicializável ... Meu comando rsync inicial com o -avpHAX funcionou bem na primeira tentativa de preencher a unidade USB. Tentativas subseqüentes de enviar "alterações incrementais" não são concluídas quando começam a fazer referência ao CD "Parted Magic". Não sei por quê, mas suspeito que esteja seguindo um link rígido para algum diretório /... . O exemplo que eu estava seguindo tinha uma opção -avp e adicionei a parte HAX na tentativa de resolver o problema da contagem K "Usado".

O único problema que resta para resolver está relacionado ao processo 'grub' que está reclamando sobre não encontrar um determinado ID de dispositivo. As coisas funcionam bem quando reconheço que ignora o problema.

    
por Mark L Keppinger 15.02.2016 / 06:05