Clone an entire filesystem

[superdeez]

When I built my current system for my root drive, I used an SSD that (while free) was on the small side and finally I ran out of space.

Not sure if dd would work if the two drives are of different sizes. When I've used cp before I've found it doesn't copy over *everything* (though it's been good enough when I've moved my home dir around between different drives). What's the best way to attempt to copy over my entire / and /boot filesystems?

root is ext4, boot is ext2.

[sdauth]

rsync -avHAX /mnt/oldssd_root/ /mnt/newssd_root/
rsync -avHAX /mnt/oldssd_boot/ /mnt/newssd_boot/
should do to the job. I used that a few weeks ago when moving from ext4 to btrfs.

then restore UUID of your old boot & root partition to the new one. (With tune2fs -U *UUID* ..)

Otherwise, since the old one is smaller, you could simply dd the old one to the new one and then expand the root partition.

[NeddySeagoon]

superdeez,

dd copies everything, including the empty space. That's a bad thing for an SSD because even if its erased empty space on the source, it will incur a write on the destination.
rsync is good, it only copies the content of the filesystems.

You must do the copy as root, while the source filesystem is not mounted. If its in use, files open for writing will be corrupt in the copy.

You can update the UUIDs but they are supposed to be Universally Unique ... the kernel will hate you for two identical UUIDs in the same system at the same time, so I advise against it.
Chroot into the copy, once its done and update all the UUID consumers. That's future proof.

BIOS booting users will need to reinstall grub to the MBR as that is outside any filesystems.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[superdeez]

I will come back and update this thread with the (apparently) successful conclusion.

I had never ever thought of using rsync to mirror a filesystem like that. I'd always used some variation of cp -R.

It worked like a charm. I was replacing a 128GiB ssd that was unused and free to me. Since my early Linux days I've used one hdd for root and another, larger (4TiB, in this case) ssd for my home dir. Though I may get flak for this, I used a low hours 500GiB mechanical hdd I had in a laptop that bit the dust last year. Very slightly slower, but I already own it and it only has around 2500 hours on it.

No UUIDs or anything here, my machines all still use lilo as a bootloader.

But rsync -avHAX worked perfectly, then I just chrooted into the new HDD's root, ran lilo and it all works.

I only had to run one srync command as I mounted both /boots before running it and it just copied that all as well.

Thank you to all who replied.

[dmpogo]

[Hu]

I think that was a confusing phrasing. If the filesystem is mounted read-write, then its superblock may be inconsistent (bad when using dd; irrelevant when using rsync). Additionally, if it is mounted read-write and any applications have files open for write, then those files may also be inconsistent. To guard against both cases, the source filesystem should be mounted -o ro (read-only), so that the kernel enforces that no application can write to any file in that filesystem. In my experience, though I am not aware of a hard guarantee in this regard, the superblock tends to be consistent for a read-only filesystem, which benefits dd. As Neddy says though, dd is not a good choice if your filesystem can be copied by rsync. You might use dd if the filesystem is damaged and you are trying to create a clone for recovery purposes.

[C5ace]

I use this batch file to backup a running laptop with MBR and grub2 via WIFI to my desktop"

[Goverp]

FWIW I take backups and copy disks and so forth in Single User mode:

[dmpogo]

Sorry for somewhat hijacking the thread, but I just resized/moved partitions and /home filesystem around to make extra space for root / . (*) Now I am in position to delete and recreate larger root partition and expand the filesystem.
What stops is a question whether I can do it on life partition (should be, second step is definitely doable), but more that I will get a new PARTUUID and that is how root is build in into my EFI stub kernel parameters. So I can rebuild kernel with new parameter, but is there a way to change manually PARTUUID the way filesystem UUID can be changed with tune2fs ? Or are some advance versions of fdisk ( I tend to use this primitive one) allow setting PARTUUID when creating the partition ?

The danger is of course that if anything goes wrong I'll be unbootable

(*) having experienced remarkable hardware problems on the way, but that is another story

[Hu]

As I read the interactive help of fdisk, you can enter expert mode, then use u to change the partition UUID.

[dmpogo]

[szatox]

You can.
Partition table is already loaded to memory, your system wont even see the change until you rescan (though fdisk should trigger it automatically after you write changes; if it fails, partprobe is your friend).
_________________
Make Computing Fun Again

[dmpogo]