DEMO: System Transfer using rsync

Write tutorials here
There are more tutorials here
Forum rules
Please don't add support questions to tutorials,start your own thread in the appropriate sub-forum instead. Before you post please read this
Post Reply
Level 15
Level 15
Posts: 5665
Joined: Wed Jun 21, 2017 12:25 pm
Location: San Francisco

DEMO: System Transfer using rsync

Post by pbear »

The question of how to transfer a Mint system to another hard drive and/or computer comes up fairly often, so for reference I’m going to describe how I did that with rsync when transferring my Mate 19.1 system to a new hard drive (twice the size of the old one). Could have reinstalled (I have very detailed setup notes), but was curioius how well this would work.

Others may find this strategy appealing if they don’t want to take the time to learn Clonezilla and/or CZ isn’t a good fit for their situation. For example, transferring to a smaller drive (HDD to SDD) is difficult with Clonezilla or any block copy solution. Also, rsync is more suitable if you want to modify your partition scheme for the new system. One advantage of doing this at file level is that rsync doesn't care tuppence about the partition table. You're copying from one place to another. To rsync, it's irrelevant whether the target is a partition or a subdirectory.

Notice this is more a demonstration than a complete tutorial. You’ll probably have to modify the steps for your situation, but something along these lines should work. For example, if attaching the target drive isn’t feasible because you’re transferring to another computer and its hard drive isn't easily removed, you could do two file transfers, first to a USB hard drive, then a second from that to the target system.

By the way, another way to do an rsync system transfer is Timeshift. See Demo. That method is easier than what I describe here, but also more limited. A hybrid solution would be to use Timeshift for the system and rsync for partitions other than root (home, data, etc.).


There are four phases: Preparation, File Transfer, Edit fstab, and Install Grub. For reference, I did the work with the old drive still installed, so that was sda. Live session (below) was booted from sdb. Target drive, attached by SATA-to-USB cable, was sdc.

Preparation. Before the transfer, I updated the system so it was fully current. Also, I cleaned up a bit. Like moving your house, more efficient to cull before moving than after. You might want to trim or even delete Timeshift snapshots, as there's not much point to transferring those.

File Transfer. Boot a live session, preferably one matching the installed system. I have four partitions: System, Timeshift, Home and Data. System is the root partition. I didn't bother to transfer Timeshift, but did include it on the partition table for the target drive. So, first step is to open GParted, set up partitions on the target drive and label them. Labels are very useful here, as they make the rsync commands simpler. For ease of reference, I changed the labels on the source drive to things like System-Old. Close Gparted.

My system uses BIOS. With a UEFI system, use GParted to copy the EFI partition in its entirety from source to target. This duplicates the boot loaders and preserves the EFI partition's UUID, which is used in fstab for mounting it at boot. If for some reason you can't do this, be sure to include an EFI partition on the new system.

o Open File Manager. Mount both the source and target partitions. Mount points will be something like /media/mint/System-Old. Then I ran a separate rsync command for each partition being transferred. You'll have to adjust, of course, for your partition labels.
sudo rsync -axHAX --info=progress2 /media/mint/System-Old/ /media/mint/System
sudo rsync -axHAX --info=progress2 /media/mint/Home-Old/ /media/mint/Home
sudo rsync -axHAX --info=progress2 /media/mint/Data-Old/ /media/mint/Data
Per the man page, -a = archive (implies -rlptgoD, i.e., recursive (include sub-directories); copy symlinks; preserve permissions, timestamps, groups, owner, devices and specials); -x = one file system (don’t cross filesystem boundaries); -H = preserve hardlinks (symlinks covered by -a); -A = preserve Access Control Lists; -X = preserve extended attributes. Not sure actually need all those, but recommended by various sources. Using sudo because copying as user “mint”; no need for a password, though, as it’s a live session. Experienced rsync users might notice the absence of exclusions like /sys and /proc for the root partition; again, that’s because it’s a live session.

o FYI, info=progress2 provides feedback to confirm command is running. Note: % complete refers to each file, so pretty much useless. If want to monitor overall progress, notice aggregate size of files being copied beforehand and compare with amount completed at any point in time.

o To confirm copy, run each command again (use up-arrow to retrieve); should go very quickly as mostly just comparing file lists and attributes.

Revise fstab. Need to revise /etc/fstab with new UUIDs. Run sudo blkid to generate list. Open fstab with sudo nano /media/mint/System/etc/fstab. Or, for a GUI text editor, you could use xed admin:///media/mint/System/etc/fstab. Copy in new UUID for each mount point. Close and save. Note: fstab is a configuration file used by the system to mount partitions at boot. For more information, see man page, Ubuntu Help and How-To Geek. It needs to be modified here because the file as transferred refers to the old hardware.

ETA: Alternatively, you could use tune2fs to conform the UUIDs of the new partitions to the old ones. Only reason I didn't do it this way is that I was unaware of the option at the time. tune2fs requires a file system check first. So, working one partition at a time, run sudo fsck -fy /dev/sdx#, then sudo tune2fs -U old-UUID /dev/sdx#. (You get the old UUIDs by copying from fstab.) Will warn, "setting UUID could take some time," but it's been quick each time I've done it. If there's a swap partition, that should be conformed also, but the command is sudo mkswap -U old-UUID /dev/sdx#.

Note: The tune2fs command only works with Linux partitions. That's why I say above, if yours is a UEFI system, use GParted to copy the old EFI partition to the new system. The partition is formatted fat32, so tune2fs can't touch it. If for some reason you were unable to copy the partition, conform fstab instead.

Install Grub. When I did this the first time, I thought I had to use chroot to install Grub to the new system. Turns out, there's an easier way. From the live session, run this (assuming the target is sdc and the system partition is sdc1):

Code: Select all

sudo mount /dev/sdc1 /mnt 
sudo grub-install /dev/sdc --boot-directory=/mnt/boot
That's for a BIOS system. For UEFI, you don't need to install Grub if you followed my advice to copy the EFI partition with GParted. That has the boot loaders, and the (duplicated) system has all the other files needed to boot. If you weren't able to do that, see my tutorial on Grub install for the appropriate form of command. The only tricky case is transferring from BIOS to UEFI. Of course, there's no EFI partition to copy. Now you are going to have to use chroot, and a few other tricks besides. See my system backup demo for details (third-to-last paragraph).

Cleanup. Shut down the live session. Remove the old hard drive and install the new one. Boot (fingers crossed). You may find (I did) that Mint is listed as Ubuntu in the Grub menu. Running sudo update-grub will take care of that. Also, you probably want to take a manual Timeshift snapshot, so you have a baseline as of the transfer date.
Post Reply

Return to “Tutorials”