Clonagem SSHD - algo especial a ter em conta, em comparação com o HDD?

0

A questão é se o fato de o dispositivo ser um disco híbrido tem alguma (e qual) importância ao usar dd ou outras ferramentas desse tipo, ou se todas as operações são executadas da mesma forma que para um HDD. / p>

O contexto

O dispositivo em questão é um Seagate ST1000LM014. Eu usei este comando para fazer um backup antes de enviar o laptop para reparos (placa de som): dd if=/dev/sdb conv=sync,noerror bs=64K | gzip -c | split -b 2000m - ./sdb_backup.gz.

Previsivelmente, os caras do serviço HP formataram o disco, só porque. Eu não tenho razão (ainda) para suspeitar que eles a trocaram. Eu restaurei os dados: cat sdb_backup.gz.* | gunzip -c | dd of=/dev/sdb conv=sync,noerror bs=64K

Agora tudo o que é visível de outro Windows é a partição de recuperação e gdisk -l /dev/sdb me dá:

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 1953525164 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): {{I removed it}}
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525130
Partitions will be aligned on 2048-sector boundaries
Total free space is 14851 sectors (7.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1333247   650.0 MiB   2700  Basic data partition
   2         1333248         1865727   260.0 MiB   EF00  EFI system partition
   3         1865728         2127871   128.0 MiB   0C01  Microsoft reserved ...
   4         2127872      1907614565   908.6 GiB   0700  Basic data partition
   5      1907615744      1909415935   879.0 MiB   2700  
   6      1909415936      1953513471   21.0 GiB    0700  Basic data partition

O gparted mostra "desconhecido" para o tipo das primeiras 4 partições. sdb4, pelo menos, deveria ser NTFS, mas não vai montar como tal, ou NTFS-3g - mount -r -t ntfs-3g /dev/sdb4 /media/myusername/sdb4 dá:

NTFS signature is missing.
Failed to mount '/dev/sdb4': Invalid argument
The device '/dev/sdb4' doesn't seem to have a valid NTFS.

Mas isso é fundo suficiente, eu acho. Eu tentei muitas coisas para este erro, não conseguiu corrigir. Eu não estou pedindo uma solução aqui.

    
por kaay 08.04.2016 / 13:48

1 resposta

3

Parece que você sabe o que está fazendo! Se sdb funcionou antes (no Linux), então deve funcionar novamente depois de uma restauração como você descreve. Se isso acontecesse comigo, estaria suspeitando de algum tipo de erro do usuário. Mas de qualquer forma, eu não consigo ver o que poderia ter dado errado. Por exemplo. se o gunzip alimentasse os arquivos na ordem errada, geraria mensagens de aviso assustadoras e você (provavelmente) teria notado.

Acho que li sobre unidades em que o SSD é exposto separadamente e o armazenamento em cache é feito por software. No entanto, eu suspeito que foi um hack precoce, uma medida paliativa. Esta unidade é anunciada como uma atualização simples, mesmo para Playstation ou Mac. Não vejo nenhuma configuração de software especial mencionada. Eu definitivamente esperaria que ele se comportasse da mesma forma que uma unidade normal e não híbrida.

Entendo que você não tem mais interesse ou capacidade em investigar o backup. Mas noto que é possível examinar tal backup exigindo um disco rígido extra, ou até mesmo um terabyte de espaço livre em disco. A tubulação para dd conv=sparse of=single.img criaria um arquivo de imagem, sem precisar alocar para blocos que nunca foram gravados na unidade original. É possível acessar o arquivo de imagem como um disco usando o losetup, por exemplo. %código%. (Considerando seu comando split, deve-se mencionar que não é possível criar tais arquivos de imagem no vfat / FAT32).

Em princípio, parece que você não conseguiu testar sua restauração com antecedência. Na prática, a maneira de testar um backup de imagem de um sistema operacional arbitrário seria restaurá-lo para um hardware idêntico (e algo parecido com variáveis de inicialização EFI para garantir que ele seja realmente inicializável). Que não é muito realista. Isso mostra como os backups de imagem não são geralmente muito úteis, fora do tipo de caso que você descreve.

(Eu acho que sei como fazer as coisas EFI para uma instalação Linux. Para Windows ... Eu quero fazer backup da instalação exata usando o Linux losetup -P --show -f single.img . Ou praticar com algo como o CloneZilla que é projetado para fazer para você. CloneZilla é incrível).

Dito isto, você poderia ter verificado a capacidade de acessar arquivos dentro da imagem. Essa técnica permitiria uma medida de confiança no backup de imagem e uma confiança quase total na capacidade de restaurar arquivos do usuário.

    
por 08.04.2016 / 16:20