If I wanted to be more careful I could probably just do a full registry export and keep C:\Users\[username]\AppData. But rather than dig around trying to recall and export MORE stuff (when I want to be playing on the new machine...) I'll just keep a copy of the whole thing for reference.

And it'll get deleted down the track when I'm happily bedded into the new machine.

Other tips: if you moved your license for Windows to the new machine, run the VM without networking...

If you are wondering how to get stuff off it with no networking - because you are using (inbuilt to Windows Pro) hyperv instead of vmware - you can mount the VHD disks directly on your new machine while the VM is off.

Pretty common problem for someone to do their boot drive, reboot and have it mount their backup.

If you are using iSCSI or anything with multipathing this can happen even without a reboot.

I know that block level copies seem like a good easy solution. But several decades in the storage admin to architect roles during the height of the SAN era showed that it is more problematic than you expected.

To be honest, full block level backup of a boot volume is something you do when the data isn't that critical anyways.

But if you use case requires this and the data is critical, I highly encourage you to dig into how even device files are emitted.

If you are like most people who don't have the pager scars that forced you to dig into udev etc... you probably won't realize what appears to be a concrete implementation detail is really just a facade pattern.

The rootfs can be mkfs and rsynced nicely.

That said, the article is awesome and the idea very clever.

But more to do streaming replication that dd catchup.

2) Arguing that it might be better to avoid such methods because of possible problems with data integrity isn’t a lack of an approach to data integrity.

The number of writers on a typical OS means that you can't depend on a pathological case.

I suppose you could reduce it to Rice's theorm and how threeTM is undecidable but remember it generalizes to even total functions.

Just goes back to the equivalence of two static programs requires running them, and there is too much entropy in file operations to practically cover much of the behavior.

When forced to, it can save you, but a block level copy on a live filesystem is opportunistic.

Crash consistency is obviously the best you can hope for here, so that and holes in classic NFS writes may be a more accessible lens on the non-happy path than my preferred computability one.

The guid being copied and no longer unique problem I mentioned below is where I have see people lose data the most.

The undecidable part is really a caution that it doesn't matter how smart the programmer is, there is simply no general algorithms that can remove the cost of losing the symantic meaning of those writers.

So it is not a good default strategy, only one to use when context forces it.

TL:DR it is Horses for courses