Using the CLI to backup or copy a Linux system

I fell into that trap once. :smiley:
Reinstalled the core system to a new SSD, and restored a systemback snapshot.
This in theory gave me an exact copy of my previous system, in practice it could not boot…
Took me a while to sort it out.
That was long ago.

2 Likes

Is this really true? I thought the UUID is bound to the partition, not to the filesystem. Just reformatting shouldn’t change the UUID, even if done with mkfs.

But maybe I’m wrong…

It’s the PARTUUID.
See blkid output before:

/dev/sdd1: UUID="548ed40e-636f-473a-8226-473f8a802a11" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="722186a3-01"

..and after formatting:

/dev/sdd1: UUID="ae0ef6bd-26f6-474d-bfc2-b9f176500f41" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="722186a3-01"
3 Likes

With gparted or mkfs?

With gparted.
Gonna try using mkfs…

Edit: it changed it too.

root@nagygep-cin-13:/home/laco# blkid |grep sdd1
/dev/sdd1: UUID="ae0ef6bd-26f6-474d-bfc2-b9f176500f41" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="722186a3-01"
root@nagygep-cin-13:/home/laco# mkfs.ext4 /dev/sdd1
mke2fs 1.47.2 (1-Jan-2025)
/dev/sdd1 contains a ext4 file system
	created on Thu Feb  5 11:33:10 2026
Proceed anyway? (y,N) y
Creating filesystem with 41822102 4k blocks and 10461184 inodes
Filesystem UUID: 09cfbe8d-7e0b-4005-88c8-1f6e1b4d2c05
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (262144 blocks): 
done
Writing superblocks and filesystem accounting information: done     

root@nagygep-cin-13:/home/laco# 
root@nagygep-cin-13:/home/laco# blkid |grep sdd1
/dev/sdd1: UUID="09cfbe8d-7e0b-4005-88c8-1f6e1b4d2c05" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="722186a3-01"
root@nagygep-cin-13:/home/laco#
4 Likes

The PARTUID is unchanged
The UUID has changed.
Grub and fstab use the UUID … so @kovacslt is right.
Thanks for checking.

4 Likes

Good to know. After thinking a bit, it seems logical, as formatting really changes the identity of the partition. I was wrong with my initial assumption.

3 Likes

Yeah. I have to revise my statement. in reply no 218

“Rather than empty the filesystem with rm -r * , it is better to use gparted and reformat the partition. That way you get a new filesystem. That may help in cases where the filesystem itself has been corrupted.”

Rather I should say

  • if you think the filesystem is OK and only the files are corrupted. empty the filesystem with rm -r *. Then you can recover to the same filesystem UUID and grub will not be affected
  • if you think the kernel has gone beserk and damaged the filesystem, make a new filesystem with gparted or mkfs. You will then have to fix UUID,s in fstab and grub.cfg, before it will boot.

Is that correct now?

3 Likes

I think so, yes.

3 Likes