Using the CLI to backup or copy a Linux system

ihasama · 21 January 2026 09:18

I can’t say anything to this because I’ve never used a MacOS. It’s just that I prefer more DIY approach and IF I’m gonna buy an M1 Mac I’ll keep the MacOS too just to try and learn it.. My only reason to buy one would be the ARM chip which doesn’t need cooler and the battery lasts for a long time. Propably I’ll go with i5 Thinkpad though. Just saw one with i5-10th gen + 16G RAM for 180eur.

The video you point is cool, seen it earlier.

M1 and M2 have been “brute forced” to work with Linux kernel (Asahi), M3 and M4 aren’t.

nevj · 21 January 2026 10:59

@ihasama ,
When you get this wonderful new laptop, you may be able to use rsync to transfer your gentoo and whatever from the old laptop.

callpaul.eu · 21 January 2026 13:05

The only difficulty is that apple make the machine obsolete after 5 years so no more updates to the system. Occasionally you can keep going and just change Safari for Google but after a while that stops. I then went to opera.

It’s no big deal Mac os it’s so Linux like but max min etc are red green buttons top left not top right. But you look at control panel and it’s a copy of mint… almost.

One issue is getting to command line or trying to write commands enough different to make you struggle.

I added 5 years to my Mac on mint. It just died of motherboard failure at that point but it had a hard life.

4dandl4 · 22 January 2026 09:37

I use the command line everyday, nothing scary!! I use the command to use startx to open my LFS Waterfox, I use it to mount and umount my usb data drives, I use it for the cp, mv and rsync commands!! The command line is Linux a GUI is just a picture!!!

nevj · 22 January 2026 10:18

The command line or shell is for giving commands to the kernel.
The GUI is for doing the same thing without having to know the commands… it has limited capacity.
Everything you do in Linux is a command to the kernel, regardless of whether you do it with pictures or words.

What is coming is the AI interface, where you talk to the AI bot and it sends commands to the computer. Gives me the creeps, … no words, no pictures, just a conversation.

nevj · 23 January 2026 10:52

After several failures I am becoming very conservative with rsync

I decided to make 2 backups

one on a 1Tb plugable SATA disk HDD
one on a 32Gb usb3.0 flash drive
Here are the results

USB drive
root@trinity:/mnt/backupusb# time rsync --dry-run --quiet -axHAXS --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} / /mnt/backupusb

real	0m4.579s
user	0m2.598s
sys	0m2.247s


root@trinity:/mnt/backupusb# time rsync -axHAXS --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} / /mnt/backupusb

real	1m45.637s
user	0m13.829s
sys	0m45.104s

That seemed successful, but if I run a sync afterwards it goes forever and cant be killed.

So I rebooted and did the backup to SATA drive

SATA drive

root@trinity:/home/nevj# time rsync --dry-run --quiet -axHAXS --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} / /mnt/backupsata

real	0m4.620s
user	0m2.806s
sys	0m2.084s


root@trinity:/home/nevj# time rsync  -axHAXS --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} / /mnt/backupsata

real	1m19.262s
user	0m13.495s
sys	0m46.455s

Same thing… it seems OK, but a sync never finishes.
The SATA drive is about 26 seconds faster the the USB drive.

I looked it up it says ( Google AI)

“rsync finishes followed by a sync command that takes forever, it indicates a bottleneck in flushing buffered data to the storage medium, often caused by high I/O wait, slow destination disks (HDD vs SSD), large file counts, or high-latency network storage. To fix this, optimize rsync by adding -W (whole file) to avoid slow delta calculations, -q (quiet), and ensure your sync command is only running after massive, slow write operations.”

To check, I looged at the size of the 2 backups

root@trinity:/home/nevj# du -s /mnt/backupusb
6445316	/mnt/backupusb
root@trinity:/home/nevj# du -s /mnt/backupsata
6445616	/mnt/backupsata

They are close… they will not be identical , because they were done from a running Peppermint Linux… so some files will have changed.

I then ran a diff

root@trinity:/home/nevj# diff -r /mnt/backupusb /mnt/backupsata
diff: /mnt/backupusb/bin/snap-store: No such file or directory
diff: /mnt/backupsata/bin/snap-store: No such file or directory
diff: /mnt/backupusb/bin/X11: recursive directory loop
diff: /mnt/backupusb/etc/alternatives/desktop-grub: No such file or directory
diff: /mnt/backupsata/etc/alternatives/desktop-grub: No such file or directory

diff: /mnt/backupusb/usr/bin/snap-store: No such file or directory
diff: /mnt/backupsata/usr/bin/snap-store: No such file or directory
diff: /mnt/backupusb/usr/bin/X11: recursive directory loop

That is just a sample
It eventually finished. Lots of differences in places like logfiles.
I think it is OK
Will test by doing a recovery.

abu · 23 January 2026 10:53

<mode=‘teacher’>
Well, to be correct, there are the applications or tools in between.
</mode>

SCNR.

nevj · 23 January 2026 10:58

Correct.
There are also services telling the kernel to do things.

nevj · 24 January 2026 11:01

I had a third try.
From within MX I mounted the Peppermint partition and rsynce dit to SATA disk. So different OS doing the rsync, and not rsyncing the live system.
The result was…

root@trinity:/home/nevj# time rsync --dry-run --quiet -axHAXS --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} /media/nevj/77dafefe-5fd6-476c-b527-172b00cb29ac/ /mnt/dest


real	0m11.888s
user	0m2.613s
sys	0m4.807s
root@trinity:/home/nevj# time rsync -axHAXS --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} /media/nevj/77dafefe-5fd6-476c-b527-172b00cb29ac/ /mnt/dest


real	3m10.605s
user	0m17.374s
sys	1m4.851s
root@trinity:/home/nevj# 

root@trinity:/home/nevj# sync
root@trinity:/home/nevj# 

root@trinity:/home/nevj# du -s /mnt/dest
6481816	/mnt/dest

So it took longer than the live rsync ( 3m10s vs 1m19s) , and the resultant backup was larger (6481816 vs 6445616) and the sync afterwards returned immediately.
I dont know whether the difference is due to MX versus Peppermint doing the rsync, or rsync of live system versus rsync of mounted partition from another Linux.

This 3rd try looks much healthier to me.
It will be interesting to see which, if any, of these 3 backups I can successfully restore from.

I will try restores to a mounted partition from MX first, then if that works will try restores to a live system.

When @kovacslt and I started this, we never though there would be so many considerations.

kovacslt · 24 January 2026 19:23

Yes, we were unaware of those. I will rejoin the thread soon, and will do my own tests.
A recent discovery regarding rsync is that the order of excludes and includes in command do matter a lot!

nevj · 24 January 2026 21:12

Thanks, that may help, especially with rsync of a live system.
I read, the order matters if you use a general exclude rule like --exclude=/*

nevj · 25 January 2026 10:06

I tried restoring from the non-live backup as follows … working in MX

root@trinity:/home/nevj# mount /dev/sdj3 /mnt/source
root@trinity:/home/nevj# mount /dev/sdi7 /mnt/dest

root@trinity:/home/nevj# rsync --dry-run -axHAXS --delete --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} /mnt/source/ /mnt/dest
root@trinity:/home/nevj# 
root@trinity:/home/nevj# rsync  -axHAXS --delete --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} /mnt/source/ /mnt/dest
root@trinity:/home/nevj#

There was one extra file in my home directory on the destination

before recovery
$ ls /mnt/dest/home/nevj
Desktop    Downloads  log1  log3  log5   Pictures  Templates
Documents  fosstry2   log2  log4  Music  Public    Videos
the extra file is log5

after recovery
$ ls /mnt/dest/home/nevj
Desktop    Downloads  log1  log3  Music     Public     Videos
Documents  fosstry2   log2  log4  Pictures  Templates
the file log5 is gone.

If I now boot the recovered Peppermint… it boots
So non-live backup + non-live recovery works well.

You can recover on top of the existing Linux … the --delete takes care of that.
I did not exclude /etc/mtab for a non-live recovery… I think we want a total windback, and that includes the old mtab file.

So now, can I do a recovery from the same non-live backup, into a running live Peppermint?
I tried this

root@trinity:/home/nevj# rsync  -axHAXS --delete --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*,/etc/mtab} /mnt/backupsata/ /

with a dry run first , of course.
I am still in that live Peppermint… it did not kill it. … and it restored a file in my home directory that I had deleted.

Note. This time I had /etc/mtab in the exclude list… I think you want to keep the same live mtab in a running system.
and, I remembered, at last, to mount the backup read-only.
There was no --include list. Rsync’s default is to include everything on the source, except those things in the exclude list… that should be sufficient.

I think now, live recovery is fine, as long as the backup filesystem was made correctly… ie it worked with my non-live backup file…and it should work with a properly made live backup file … what I now have to resolve is why are my live backup attempts misbehaving.

And there are questions… eg if a backup and a filesystem being recovered to both contain a particular file, but the file dates or permissions differ, what happens… will a recovery revert the file to its version with an older date from the backup? … I hope so. … but it may say dates are different so that is a different file , and proceed to delete it?

nevj · 25 January 2026 11:04

Then I became brave and attempted to restore into live Peppermint from my live-backup on a usb drive

root@trinity:/home/nevj# mount /dev/sdf2 -o ro /mnt/backupusb
root@trinity:/home/nevj# 
root@trinity:/home/nevj# rsync --dry-run  -axHAXS --delete --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*,/etc/mtab} /mnt/backupusb/ /
root@trinity:/home/nevj# 
root@trinity:/home/nevj# rsync -axHAXS --delete --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*,/etc/mtab} /mnt/backupusb/ /
root@trinity:/home/nevj#

Well, it finished quickly… there was probably very little to recover
It seems to have reverted my home directory to an earlier state with both log4 and log 5 missing… and the file dates are all jan23 or earlier.
OK, so it may have worked… I am still here using Peppermint!

That business with sync after rsync hanging forever, while doing a live backup, may not have been serious. ’
I need to see it it was a Peppermint issue… I will try a live backup of some other distro. Peppermint may have been a bad choice.

There is just a glimmer of hope from this, that live backups and restores may be possible with a relatively simple rsync using only --delete and --exclude.

ihasama · 25 January 2026 11:32

Nice! This is so great to see your efforts lead to succes! I’ve learned so much from this thread, thank you Neville and Laszlo!

nevj · 25 January 2026 11:44

Me too. I apologise for the many rounds of confusing failures.
I have no other way to learn.
The outcome I want is to find the simplest possible procedure that will work reliably.
Thank you for following the thread and for comments.

abu · 25 January 2026 11:53

Most of us, if not all, do it that way.

nevj · 25 January 2026 11:58

“It is the true nature of mankind to learn from mistakes, not from example”
Fred Hoyle

abu · 25 January 2026 12:07

I have not failed. I’ve just found 10,000 ways that don’t work.

– Thomas Alva Edison

nevj · 26 January 2026 11:06

I tried backing up my MX with a live rsync
I have 3 partitions

/ is 30Gb
/home is 43Gb
/common is 109Gb

Because I use the -x flag on rsync it will stay on the / filesystem …a total of about 30GB

nevj@trinity:~
$ cat mxlivebu
root@trinity:/home/nevj# mkdir /mnt/backup
root@trinity:/home/nevj# mount /dev/sdd6 /mnt/backup
root@trinity:/home/nevj# 
root@trinity:/home/nevj# time rsync --dry-run --quiet -axHAXS --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} / /mnt/backup

real	0m24.131s
user	0m6.915s
sys	0m11.983s
root@trinity:/home/nevj# 
root@trinity:/home/nevj# time rsync -axHAXS --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} / /mnt/backup

real	12m7.139s
user	0m52.915s
sys	3m8.172s

root@trinity:/home/nevj# sync
root@trinity:/home/nevj# 
nevj@trinity:~
$

It all works beautifully, and the sync at the end returns immediately
Therefore

the ‘sync’ problem was due to Peppermint/Devuan
my rsync options for a live backup are OK.
the live backup itself did not cause the sync problem

and
I am quite impressed … 12 minutes for the whole 30Gb is really good (2.5GB per minute) … I used a plugable SATA disk for the backup…it is a 1Tb HDD. The root filesystem of MX was on SSD.

Dont ask me to test a restore on that… it is too important.

ihasama · 27 January 2026 12:02

Now that Neville got the CLI command working right I made a try. First I decided to try encrypting the partition on my laptop’s SSD for my /home folder sync (just for fun and because I need to learn the encrypting for my next machine): This part is made according to Gentoo wiki (https://wiki.gentoo.org/wiki/Dm-crypt)

┌─[pete@gentoo]─[~]
└──╼ su -
Password:
Last login: Mon Jan 26 13:01:21 EET 2026 on pts/0
gentoo ~ # emerge sys-fs/cryptsetup

These are the packages that would be merged, in order:

Calculating dependencies      ... done!
Dependency resolution took 3.87 s (backtrack: 0/20).

[binary   R    ] sys-fs/cryptsetup-2.8.3-r1-1:0/12::gentoo  USE="argon2 nls openssl udev -fips -gcrypt -kernel -nettle -passwdqc -pwquality -ssh -static -static-libs -test -urandom -verify-sig" 0 KiB

Total: 1 package (1 reinstall, 1 binary), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] No4
Sorry, response 'No4' not understood. [Yes/No] No

Quitting.

gentoo ~ # cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      1985939 iterations per second for 256-bit key
PBKDF2-sha256    2385838 iterations per second for 256-bit key
PBKDF2-sha512    1718977 iterations per second for 256-bit key
PBKDF2-ripemd160  981812 iterations per second for 256-bit key
PBKDF2-whirlpool  669588 iterations per second for 256-bit key
argon2i       4 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b      1128.9 MiB/s      3311.3 MiB/s
    serpent-cbc        128b        96.2 MiB/s       724.6 MiB/s
    twofish-cbc        128b       219.7 MiB/s       393.7 MiB/s
        aes-cbc        256b       854.0 MiB/s      2642.7 MiB/s
    serpent-cbc        256b        95.5 MiB/s       673.6 MiB/s
    twofish-cbc        256b       217.9 MiB/s       370.9 MiB/s
        aes-xts        256b      3129.4 MiB/s      3154.9 MiB/s
    serpent-xts        256b       560.7 MiB/s       539.2 MiB/s
    twofish-xts        256b       338.2 MiB/s       340.0 MiB/s
        aes-xts        512b      2590.2 MiB/s      2585.6 MiB/s
    serpent-xts        512b       585.4 MiB/s       589.5 MiB/s
    twofish-xts        512b       326.6 MiB/s       318.9 MiB/s
gentoo ~ # lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 465.8G  0 disk
├─nvme0n1p1 259:1    0     2G  0 part /efi
├─nvme0n1p2 259:2    0 406.2G  0 part /
├─nvme0n1p3 259:3    0     1K  0 part
├─nvme0n1p4 259:4    0  25.4G  0 part
└─nvme0n1p5 259:5    0  24.4G  0 part
gentoo ~ # cryptsetup -c aes-xts-plain64 -s 512 -y luksFormat /dev/nvme0n1p4
WARNING: Device /dev/nvme0n1p4 already contains a 'ext4' superblock signature.

WARNING!
========
This will overwrite data on /dev/nvme0n1p4 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/nvme0n1p4:
Verify passphrase:
gentoo ~ # cryptsetup luksOpen /dev/nvme0n1p4 pete
Enter passphrase for /dev/nvme0n1p4:
gentoo ~ # lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1     259:0    0 465.8G  0 disk
├─nvme0n1p1 259:1    0     2G  0 part  /efi
├─nvme0n1p2 259:2    0 406.2G  0 part  /
├─nvme0n1p3 259:3    0     1K  0 part
├─nvme0n1p4 259:4    0  25.4G  0 part
│ └─pete    253:0    0  25.4G  0 crypt
└─nvme0n1p5 259:5    0  24.4G  0 part
gentoo ~ # mkfs.ext4 /dev/mapper/pete
mke2fs 1.47.3 (8-Jul-2025)
Creating filesystem with 6650624 4k blocks and 1662976 inodes
Filesystem UUID: 7330c741-4536-48c6-be53-96972947ceb8
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
	4096000

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

gentoo ~ # mount /dev/mapper/pete /mnt
gentoo ~ # ls /mnt
lost+found
gentoo ~ # lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1     259:0    0 465.8G  0 disk
├─nvme0n1p1 259:1    0     2G  0 part  /efi
├─nvme0n1p2 259:2    0 406.2G  0 part  /
├─nvme0n1p3 259:3    0     1K  0 part
├─nvme0n1p4 259:4    0  25.4G  0 part
│ └─pete    253:0    0  25.4G  0 crypt /mnt
└─nvme0n1p5 259:5    0  24.4G  0 part
gentoo ~ # cryptsetup luksDump /dev/nvme0n1p4
LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	530ac0af-4d39-4a06-81eb-b053c5a12c40
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  4
	Memory:     1048576
	Threads:    4
	Salt:       07 d8 a2 fd 9d 04 20 0d 27 ac 2f 04 28 ae d5 c9
	            18 a4 34 c3 1e 81 4a 96 e5 8d aa 3f 90 a2 b2 47
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 144671
	Salt:       8c 04 0f ac d2 42 60 09 94 38 e5 98 1c 2a 93 c5
	            11 f2 56 ac cb a3 b9 6e 03 a3 03 83 09 9b e1 d5
	Digest:     18 5b 76 47 77 bf 44 b8 9e 76 a9 a7 7e 26 59 93
	            d3 b6 ee 92 60 92 94 22 56 3e 8b 27 a1 eb e1 a8

I now have a crypted partition for backing up my /home. Now make a /backup folder:

gentoo ~ # mkdir /mnt/backup

First I tried the same command as Neville on the post 179:

gentoo ~ # time rsync --dry-run --quiet -axHAXS --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} / /mnt/backup

real	0m15.639s
user	0m2.619s
sys	0m6.605s
gentoo ~ # time rsync -axHAXS --exclude={/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} / /mnt/backup
^Crsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(519) [generator=3.4.1]
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(716) [sender=3.4.1]

real	1m14.379s
user	0m4.854s
sys	0m27.706s
gentoo ~ # rsync: [receiver] write error: Broken pipe (32)
ls /mnt/backup/
backup              bin   deja-dup  dots  etc     home  lib64       media  opt   root  sbin  temp  usr
backup19102025.zip  boot  dev       efi   gentoo  lib   lost+found  mnt    proc  run   sys   tmp   var
gentoo ~ # rm -r /mnt/backup/*

and the last command I interrupted because I would need more than 35Gb partition for my /

and here’s the command I used to make a backup of my /home:

gentoo ~ # time rsync -axHAXS --exclude={/home/pete/Downloads*,swapfile} /home/pete /mnt/backup
real	1m17.910s
user	0m21.701s
sys	1m1.397s
gentoo ~ # sync
gentoo ~ #

to unmount the crypted partition:



gentoo ~ # umount /mnt
gentoo ~ # cryptsetup luksClose pete
gentoo ~ # lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 465.8G  0 disk
├─nvme0n1p1 259:1    0     2G  0 part /efi
├─nvme0n1p2 259:2    0 406.2G  0 part /
├─nvme0n1p3 259:3    0     1K  0 part
├─nvme0n1p4 259:4    0  25.4G  0 part
└─nvme0n1p5 259:5    0  24.4G  0 part
gentoo ~ # mount /dev/nvme0n1p4 /mnt
mount: /mnt: unknown filesystem type 'crypto_LUKS'.
       dmesg(1) may have more information after failed mount system call.
gentoo ~ #

I now have backed up my home folder! Thanks Neville and Laszlo!