1

So, I'm replacing my laptop's 1TB hard drive with a 1TB sata ssd, and I'm wondering how to transfer the files from one to another. I'm dual booting kubuntu 17.10 and windows 10, and I'd like to keep it that way. I'm ok with a reinstall on windows, as I don't use it that much anyways, and I'd be ok with a kubuntu reinstall as well, as I've been having some problems I can't fix, no matter however long I spend researching them or asking questions.

Other than just backing my stuff on an external hard drive, is there anything else I should know about? Thanks.

1
  • 3
    The problem with naive cloning is that not all "1TB" drives are the same size. This could result in a damaged filesystem if the new drive is smaller. – Ignacio Vazquez-Abrams May 9 '18 at 4:49
1

You intend to copy over your valuable files, right. But what if you forget on one or two.

This answer addresses the issue of cloning the whole partition in case you forget on something.


Suppose your laptop's hard drive is named:

/dev/sda

Further suppose your Linux partition is for instance:

/dev/sda2

And finally suppose that your external HDD is mounted as:

/mnt/externalhdd

Then you might want to do a perfect copy of it, for example this way:

  1. Boot from a live Linux USB.

  2. Become root:

    sudo -i
    
  3. Install pv, or if you don't need to see progress, you might use cat:

    pv < /dev/sda2 > /mnt/externalhdd/sda2.pv
    
  4. It came to be very handy to me to have a copy of the drive's partition in case I forgot something to copy over.

1

Disk Imaging method

Attach the SSD using a quality USB-to-SATA adapter or through the secondary ports on your laptop if available.

You could boot into any LiveCD/USB environment and use dd command to clone the disks and it should work just fine.

If the source drive is /dev/sda, and destination is /dev/sdb, the command would be dd if=/dev/sda of=/dev/sdb bs=1M

Please verify which drive is which before starting since this is the point where event a hint of carelessness could lead to data loss. (Source: me)

Afterwards all you would want to do is extend the last partition to the full length of the disk or create a new partition in that empty space, but this should not be a worry since the size of the source and target disks are the same.

Cleaner method

You can take a tar.gz dump of your Kubuntu distribution from a Live CD and unpack it later on a ext4/xfs partition to transplant your installation.

You will have to update the following in the new partition:

  • Partition ID in /etc/fstab

  • Reinstall grub using the new /boot directory

1

TL;DR:

Use Clonezilla to clone your current disk in the new one, and Bob's your uncle!


but, if you want to have fun, you can do fdisk -l /dev/sda | head -1 && fdisk -l /dev/sdb | head -1 ( or, more concisely fdisk -l | awk '/Disk.*sd(a|b)/' ) where /dev/sda is your current disk and /dev/sdb is your new disk, to print something like this:

Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Disk /dev/sdb: 232.9 GiB, 250059350016 bytes, 488397168 sectors

take note of the number of bytes of each disk: it's important for what follows.

If your disks have exactly the same number of bytes

(and, maybe, but not ideally, if your current disk is smaller than the new one)


If in your dd command (read bellow) you put a wrong device file in if [inputfile], it's not a big deal: you can do it that again, but, beware: dd can be dangerous... if you put a wrong device file in of [outputfile], say, for example, /dev/sdc, another disk of yours in your system, you instantly destroy the data in your /dev/sdc, overwriting them with the data in your if [inputfile] ; so, check your of [outpufile] several times.


You can use dd command from your kubuntu system to make and EXACT copy [clone] (byte by byte) {dd does't understand about filesystems... it's a dummy copy, byte by byte and, ideally, both disks need to have the exact same number of bytes} ; this can be slow, specially if you don't use the blocksize that gives you the best performance; the only way to know the best performance blocksize, is to try with various blocksizes and test; but in your case, that doesn't seem a good idea (your are manipulating your sensible data)... You can do something like this:

dd if=/dev/sda of=/dev/sdb

where /dev/sda is your current disk and /dev/sdb is your new disk (this use the default blocksize of 512 bytes, that could be very slow)

In this case, while dd is cloning your current disk in your new disk, you get nothing on your terminal (I mean: nothing on stdout or stderr); this is far from good, specially, in a case like this, where you are cloning a large disk, so, in most recent versions of dd, you can use status=progress to get a feedback in your terminal, like this:

 dd if=/dev/sda of=/dev/sdb status=progress

Read your dd manual and search for status; if you don't have that option, and for whatever reason you are doing your cloning with that version of dd, your can use pv with dd, like this:

 dd if=/dev/sda | pv | dd of=/dev/sdb

pv stands for pipeview, and you get almost the same effect that with status=progress on newer versions of dd

or, even better, faster and simpler:

pv --progress /dev/sda > /dev/sdb

(pv will automatically choose the "best/faster" block size for you)


If not...

(or in any case, really)

Even tough you can use dd too, it's a little more complex: you need to do one thing if A > B and another if B > A, and, besides, take account on your partition table type (ms-dos,gpt,...), so... better than that, use partclone, or even Clonezilla

partclone is another program that you can use from your terminal (maybe, not installed by default) but, it's much more adequate for your task... partclone understand perfectly about filesystem (it's much more high level than dd, and, among other things, doesn't waste time coping the empty bytes in your file system)

Clonezilla it's a little linux distro especially designed for your task and alike; take a look here:

https://clonezilla.org/

(In fact, Clonezilla will try to use partclone, but, if your prefer, it can use dd too)

2
  • Your dd commands read and write 512 byte blocks, which causes complexity for SSDs that use 4KB blocks Ideally, just use cat (it'll be so much faster). But if you insist on using dd please use the bs option to use decent a block size, eg bs=32M – roaima May 9 '18 at 8:44
  • yeah; I've made that clear in my answer here: this can be slow, specially if you don't use the blocksize that gives you the best performance; the only way to know the best performance blocksize, is to try with various blocksizes and test and here: (this use the default blocksize of 512 bytes, that could be very slow): I've give her/him the bare bones and then, she/he can try with several different blocksizes, dropping the cache after each try with something like echo 3 > /proc/sys/vm/drop_caches, or even use bs=32M directly – matsib.dev May 9 '18 at 9:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.