The title pretty much speaks for itself… I have a linux install that I’ve spent a considerable time configuring, which is unfortunately installed on a drive that’s starting to show signs of dying.
My question is: how, if there is a way, can I migrate said linux install over to a different drive, while preserving all the configurations and such.
EDIT: Thank you to everyone who commented! I made the transfer, using dd and it went mostly smoothly, even if it did take a while.
You must log in or register to comment.
I used dd recently to upgrade the drive in a Steam Deck. Easy and worked perfectly.
Get a same sized drive (or larger) and just dd it? I used to do that all the time, even to Windows installs, if I knew a drive was starting to become unreliable. I’d advise mounting the original/donor drive as read-only to mitigate any potential data losses while transferring. But dd makes a perfect bit for bit copy of any partitions, drives, etc that you feed it. Just don’t get the inputs/outputs backwards! And always remember: dd stands for “disk destroyer” because if you get it wrong, bye-bye data.
Yeah, but how do I “Just dd it”. I know all about disk destroyer, so I’m a bit terrified of dd and have never really used it like that before…
You should do backups for cases like that. And mind that harddisks might fail and laptops and phones can get stolen, you might want to backup your data regardless if it’s important to you.
The trick with ‘dd’ is to pay attention to the destination. “of=” is the one thing to worry about. If you make a mistake there, it’ll overwrite somehing. Everything else isn’t as critical. And you can use some graphical interfaces like Clonezilla. It’s the same thing there: pay attention to what you’re overwriting… But the GUI might make it easier to use an understand what you’re doing.
I do have backups, I just don’t wanna bother reconfiguring the system and reinstalling everything
Sure. Just wanted to make sure you have something backed up, just in case something goes wrong. You shouldn’t need that anyways. But that’s why all the people here recommend 'dd’ing the harddrive. This way you don’t need to re-configure or install anything. It’ll copy everything and just boot up as before.
Additional advice: Detach unnecessary drives before starting the process. That way you can’t overwrite other things and it’ll be just one disk to worry about. Buy a new drive that’s the same size or larger. Expand the partitions at some point afterwards if it’s larger, to access the new space. And after 'dd’ing a whole drive: Don’t run the computer with both drives connected at the same time. The partitions will have the same identifiers, as it’s an exact copy, and that might lead to confusing situations or the computer reading/writing to the wrong disk. Just detach the old drive after you’re done and before booting again. You don’t need that old hdd anymore. And use a Live CD / USB-Stick / Clonezilla to do it. Don’t ‘dd’ the system while it’s running itself.
I’ve done it several times. Worked very well each time. And it’s not that much of an effort. Get an USB-Stick ready and install the new harddisk, 15minutes of work to get the copying started and then you just have to wait for it to finish, shut down, detach the USB-Stick and the old harddisk and you’re pretty much done. It’ll come up just as it was, just with a new harddisk inside.
There’s an old article on the Arch wiki I used to use HERE. For simplicity I’d just always use section 2.2. Hasn’t ever steered me wrong, but I’m also under no illusions that no digital data is sacred. And if it IS sacred, then it’s already backed up under the 3-2-1 approach. Just make sure you know which device is which so you don’t mix up “if” and “of”. There’s probably significantly more user friendly ways of doing it, but I guess I’m old now so I’m stuck in my ways.
I’m glad you got it sorted with dd.
One thing people don’t often realize about dd is that it copies all the data from one drive to the other, including uuids that were written when the old drives filesystem were created.
For that reason it excels at cloning one’s boot disk, because when the old drive gets removed from the pc, the clone drives os says at some point during the boot process “okay, let’s mount the filesystem with uuid ABC123 at /“ and it works.
Dd is also not the best tool for cloning disk that you intend to leave hooked up because if you do it’ll put the poor host os in a “I’m seein’ double here, four spidermen!” Type situation.
I was also one of those people who didn’t realize that it copied UUIDs. I only figured that out, because I imagined that I’d have to update the fstab to point to the UUIDs of the partitions on the new drive.
Clonezilla Is what I normally use for cloning drives, including my boot drive. You flash it to a USB drive then.
Maybe look up a Youtube guide first but I’ve never had issues with it.
Yeah i used this when i got an nvme and migrated from spinning disk on my machine. I dont remember the exact process, but it was fairly straightforward as i recall
Clonezilla is amazing, you ‘just’ need a disposable thumb drive (it gets wiped) and an external hard drive (to save the temporary clone file).
Assuming the new drive is an equal size or larger: Boot from a USB drive and use dd to clone the old drive to the new one. Then, remove the old drive and boot from the new one. You’ll also need to resize the partitions on the new drive if it’s larger.
Yeah, but… how. I’m a bit terrified of dd and have only really used it to make images of drives before…
I usually use
dd status=progress conv=sync,noerror bs=64k if=/path/to/source/drive of=/path/to/destination/driveTake a reading of the drive health first with something like smartctl and if it has a lot of failing attributes, consider lowering the block size to something rather smaller like bs=512.
Edit: To elaborate, using the sync and noerror arguments will instruct dd to ignore errors and continue in the event of read failures, while allocating zeroes to the remainder of the block space. Which is also why smaller block sizes are better for potentially failing drives. The copy will take longer, but a single error won’t take large swaths of data with it.
Hm, using a smaller block size does make sense, but I imagine that cloning an entire drive with 512 byte blocks is gonna take 10 million years. Especially this one, since the main reason I’m suspecting that it has started failing is because it’s slowed down to the point where it drags down the entire system when even the smallest of loads hit it…
That’s a bad sign. First off stop using it so that you don’t make it worse. Next take a backup. I think dd automatically skips over bad blocks but I don’t remember. Also, I would not go straight to another drive but instead go to a file.
I don’t mean to freak you out but there is a chance you are going to lose data.
I already have all data I care about backed up, so even if I lose some, it’s not a big deal
If you suspect a failing drive, you may want to consider using ddrescue as opposed to
dd. The tool is specifically designed to help with failing disks.
Take one of your backups and restore it to the new drive.
You do have backups right?
Side note I would recommend creating automation to setup your device they way you want. Either bash or Ansible pull.
I don’t do full backups, just of the things I really care about
Linux is pretty forgiving. You don’t even need to use dd, if you know what you are doing you can create a totally new partitioning format and just copy the files. Since getting the fstab just right in that case is more error prone, just using dd is simpler. If using dd, don’t worry, you can resize partition afterwards.
If it were me, I’d do a fresh minimal install of the same OS, boot to the livecd and then delete pretty much everything except for /etc and /boot. I’d then cp -ar all my files from the failing drive and then manually merge /etc back. I say manually merge because most things would get replaced by my old files, but I’d manually modfify my fstab to keep the new partition information and add my extra mounts after it. Maybe that’s just me though. You can also just dd and then resize partitions if necessary.
I did this recently. dd is fine, but you have to make sure you catch all of the places the UUID of the device is referenced. Maybe fstab, but certainly in the boot loader. This bit me, because the device IDs changed, and UEFI couldn’t find the new partitions.
Make sure you have a bootable USB rescue disk, and you’ll be fine. Even if you mess up like I did, it’s just a matter of booting, mounting, and finding the config file you missed, and replacing the blkids.
You can partition your drive identically and rsync your directorys over. Rsync will keep all softlinks and hardlinks. You made need to reinstall grub tho.
