From: none@not.here   
      
   lisa wrote:   
   > On Tue, 30 Dec 2025 18:31:00 +1100, Axel  wrote:   
   >   
   >> I wanted to clone my 500 Gb LM nvme disk to a 500 Gb mechanical drive,   
   >> but Rescuezilla reports that the target disk is too small. ??   
   >>   
   > users who had the same problem. Have a read.   
   >   
   > https://forums.linuxmint.com/viewtopic.php?t=387748   
      
   so it seems the suitable/recommended methods to overcome the disk size   
   issue are as follows..   
      
   (a) Use Gparted from a live disk to reduce the size of the source disk.   
   Illustration: https://auslink.info/linux/gpart.png   
      
   *However, would I be risking data loss doing this?   
      
   (b) Make a new install of Mint on the target disk. Use Backup Tool on   
   the source disk to produce a copy of the current Applications and a copy   
   of the /Home directory including hidden files. Restore the source disk   
   Applications and /Home on the new install using Backup Tool   
      
   (c) Use Gparted from LinuxMint Live Media to Copy & Paste a partition ..   
   from one HDD to another HDD / SSD- one at an Time, preferably, that is.   
   This will Not create a boot-able medium, though .. only copy the   
   specified data // partitions. You will have to Install a Boot-Loader to   
   the New Drive. Thus a Clone Program, is different, as it will also   
   create a boot-able medium.   
      
   *However, I do not know how to install a Boot-Loader   
      
   (d) Boot a live session. Copy the EFI and system partitions to target   
   using GParted. Then use GParted to create a third partition in the   
   remaining space, give it a label (e.g., Data-Backups), and also label   
   the data partition on source (e.g., Data-Files). Finally, use rsync to   
   copy the files from source to target. File copy is slower than cloning   
   (by a factor of two, on average), but it'll get the job done. More   
   importantly, for present purposes, file copy moots the issue of the   
   target partition being smaller (provided, of course, it's large enough   
   to hold the files). Then still in the live session, mount both   
   partitions (using Disks or File Manager), then command in this form:    
   sudo rsync -ahn --info=progress2 /media/mint/Data-Files/   
   /media/mint/Data-Backups   
   This is a dry run, mainly to confirm size of the transfer. If there's   
   enough room on target, run command again without the -n flag.   
      
   Notice slash (/) after Data-Files. Need sudo because user mint in the   
   live session has no permissions on the source files. The -a flag   
   preserves ownership and permissions of the files, but you'll want to   
   claim ownership of the partition eventually, using either chown or File   
   Manager (as root/admin) in your regular system. By the way, this is   
   assuming the source partition is simple, in particular no hard links   
   (i.e., no Timeshift snapshots)   
      
   If desired, you could use a similar command in future to re-sync the   
   backup to reflect changes in source, except you generally would add   
   --delete after -ahn, so files no longer appearing on source are removed   
   from the backup. It's also possible to re-sync the system partition, but   
   that's more complicated.   
      
   *This method seems too complicated to me   
      
   (a) or (b) is my preference   
      
   --   
   Linux Mint 22.2   
   {I shot Felix and buried him}   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)