1

The question is whether the fact the device is a hybrid disk has any (and what) importance when using dd or other such tools, or if all operations run the same as for a HDD.

The context

The device in question is a Seagate ST1000LM014. I used this command to make a backup before sending the laptop in for repairs (soundcard): dd if=/dev/sdb conv=sync,noerror bs=64K | gzip -c | split -b 2000m - ./sdb_backup.gz.

Predictably the HP service guys formatted the drive, just because. I have no reason (yet) to suspect they swapped it. I restored the data: cat sdb_backup.gz.* | gunzip -c | dd of=/dev/sdb conv=sync,noerror bs=64K

Now all that is visible from another Windows is the recovery partition, and gdisk -l /dev/sdb gives me:

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

gparted shows "unknown" for the type of the first 4 partitions. sdb4, at least, was supposed to be ntfs, but won't mount as such, or ntfs-3g - mount -r -t ntfs-3g /dev/sdb4 /media/myusername/sdb4 gives:

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

But that's enough background, I think. I've tried many things for this error, failed to fix. I am not asking for a solution here.

kaay
  • 125
  • 1
  • 6
  • did you backup /dev/sda or /dev/sdb? because your first command says you backed up sdb to `sdb_backup.gz*`, but your second says you're restoring from `sda_backup.gz.*` files. – cas Apr 09 '16 at 00:58
  • Yeah, sorry, my mistake. It was all sdb, retyped here incorrectly – kaay Apr 11 '16 at 06:04

1 Answers1

2

It looks like you know what you're doing! If sdb worked before (on Linux), then it should definitely work again after a restore like you describe. If it happened to me I would be suspecting some kind of user error. But either way, I just can't see what could have gone wrong. E.g. if gunzip was fed the files in the wrong order, it would generate scary warning messages, and you would (probably) have noticed.

I think I've read about drives where the SSD is exposed separately, and the caching is handled by software. However I suspect it was an early hack, a stopgap meaure. This drive is advertised as a simple upgrade even for Playstation or Mac. I don't see any special software setup mentioned. I would definitely expect it to behave the same as a normal, non-hybrid drive.

I understand you may no longer have interest or capability in investigating the backup. But I note it can be possible to examine such a backup requiring a spare hard drive, or even necessarily a full terabyte of free disk space. Piping to dd conv=sparse of=single.img would create an image file, without needing to allocate for blocks which were never written to on the original drive. It is possible to access the image file as a disk using losetup, e.g. losetup -P --show -f single.img. (Considering your split command though, it should be mentioned one can't create such image files on vfat / FAT32).

In principle, it sounds like you failed to test your restore in advance. In practice, the way to test an image backup of an arbitrary OS would be to restore it to identical hardware (and something something EFI boot variables to ensure it's actually bootable). Which not very realistic. So that just shows how image backups are not generally very useful, outside the sort of case you describe.

(I think I know how to do the EFI stuff for a Linux install. For Windows... I'd want to back up the exact setup using Linux efibootmgr. Or practice with something like CloneZilla that's designed to do it for you. CloneZilla is pretty amazing).

That said, you could have verified the ability to access files within the image. That technique would allow a measure of confidence in the image backup, and near-full confidence in the ability to restore user files.

sourcejedi
  • 48,311
  • 17
  • 143
  • 296
  • Thank you. In this world where time is at a premium and "probably good enough" is what we bet our lives on, the procedure of image verification (and maybe verification of the verification process?) did not feel like a sane thing to do in this case. Thanks for the losetup command, though, gonna try it as soon as I find another large drive. Anyway - I gather that between same model drives, the procedure could be expected to work correctly no less than with a HDD. – kaay Apr 08 '16 at 15:00
  • 1
    +1, especially for the recommendation of Clonezilla. CZ would have been the best tool to do the backup with, far better than doing an image backup with `dd`. as for SSHDs, they work just like any other HD. I have four of them (ST4000DX001) in my ZFS backup pool (as two mirrored pairs, similar to RAID-10) and researched them carefully before purchase to make sure there wouldn't be any unpleasant surprises. – cas Apr 09 '16 at 00:55