dd cloning a Win10 HDD to SSD

[Joshua Judson Rosen]

On 3/23/21 9:07 AM, Bruce Labitt wrote:
> On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins <dan at rastech.com <mailto:dan at rastech.com>> wrote:
> 
>     In my experience dd works. Make sure the destination disk is larger than
>     the source. I've had problems sometimes when they were the exact same
>     size. Any other issue was due to issues on the source disk, in which
>     case ddrescue, has worked.
 >
> In my case the disks report to be the same size in lsblk.
> fdisk -l reports the hdd is 1000204886016 bytes, and the sdd is 1000204886016 bytes or exactly the same size.
> Guess I will try dd.  Fingers crossed...
If the destination disk does end up not being big enough,
you can probably shrink the data on the source disk a little
(and then fix up the GPT on the destination disk, if you're using GPT--
  because GPT wants to keep a `backup table' at the _physical tail end_
  of the disk and some implementations of GPT will refuse to read
  the partition table if the disk doesn't pass that sniff-test).

Just be sure that you don't have the source filesystem mounted writeably when
you're trying to copy it like that...: it's pretty important
that nothing be actively using a filesystem and causing the data/metadata
stored within it to change as you try to dd a copy of its underlying storage.

And, since I don't think anyone mentioned this: be sure to us a big enough blocksize
with dd, because the default 512-byte bs will be incredibly slow
(and I guess *could* in theory cause a lot of extra wear on the SSD
  due to write-amplification, though I guess the Linux block layer
  should protect against that?).

For the rest of my response, I'm going to mostly ignore the "Windows 10"
part of the question and provide guidance to people looking through the list archive
for guidance doing the same sort of data-migration but for Linux disks
(though I suspect that the underlying rationales port to other operating systems)...:

There are theoretically reasons to make a fresh filesystem / LVM PV / RAID / whatever
structure, with its configuration tuned to the native block-size of the underlying
flash controller..., but in practice it never seems to matter enough to make it worthwhile
to even bother figuring out what any of those numbers are.

There are however real + very practical reasons to initialize storage on different physical disks
with different *IDs* if you want to be able to use them together at the same time, e.g.:
different ext filesystem UUIDs, or different PV IDs if you want to be able
to use them both with LVM. You can also change those IDs after the fact.

If I understand your use case, you really just have a partition table with
one two filesystems + maybe swap space, and you're going to discard the data on
the old disk (and maybe even discard the old disk) once the transfer is done.
Taking both disks out of use and just dd-ing from one to the other should be
fine for that--though, when doing such a migration for Linux systems, you might want
to consider setting the new disk up with LVM (and then dd'ing from the _partitions_
on the source disk into the _Logical Volumes_ on the destination disk),
so that things like this are easier next time.

(one of the many nice things about LVM, even if you're only going to have one disk `right now',
  is that it makes disk-migrations like this *really easy*: you just plug the new
  disk in, ensure that it has been initialized as a PV, run "pvmove", and then pull
  the old disk out when it's done--and you can keep using the filesystem while
  the migration is in progress--and LVM makes it pretty straightforward to even
  do things like convert a single disk into a RAID setup at some future point,
  like when you're about to throw the old disk out and decide that it'd be more useful
  as a hot spare than as landfill).

-- 
Connect with me on the GNU social network: <https://status.hackerposse.com/rozzin>
Not on the network? Ask me for an invitation to a social hub!