That’s not a bad idea, but I’ll have to figure out how to enable it on the NAS side because I didn’t do a lot with the distro (TOS from TerraMaster) it uses.
1 Like
Also, you can tell sshd not to listen to a particular interface… eg the internet interface. So noone can ssh from outside.
3 Likes
Why did I not use the --filter=protect option?
Well , I could not get it to work… so I used --exclude instead.
The difference is
--filter=protectonly prevents writing of specified files on the destination--exclude=prevents reading specified files from the source , and writing specified files on the destination.
I had another try
First make a new backup. sdd4 is an HDD, not a flash drive.
root@trinity:/home/nevj# mount /dev/sdd4 /mnt/backup
oot@trinity:~# time rsync --dry-run -axHAXS --filter=protect_{/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} / /mnt/backup
real 0m13.424s
user 0m3.173s
sys 0m4.277s
root@trinity:~#
root@trinity:~# time rsync -axHAXS --filter=protect_{/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*} / /mnt/backup
real 1m42.734s
user 0m17.402s
sys 1m1.004s
root@trinity:~#
root@trinity:~# ls /mnt/backup
bin common etc initrd.img lib64 media opt root sbin sys usr vmlinuz
boot dev home lib lost+found mnt proc run srv tmp var
That looks OK.
Note it is `–filter=protect_{/dev/*,…}. That is what was wrong last try… the underscore is essential.
Now add a few files, then try a live recovery
root@trinity:~# umount /mnt/backup
root@trinity:~# mount /dev/sdd4 -o ro /mnt/backup
oot@trinity:~# time rsync --dry-run --delete -axHAXS --filter=protect_{/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*,/etc/mtab} /mnt/backup/ /
real 0m9.109s
user 0m4.014s
sys 0m5.643s
root@trinity:~#
root@trinity:~# time rsync --delete -axHAXS --filter=protect_{/dev/*,/proc/*,/sys/*,/run/*,/mnt/*,/media/*,/tmp/*,/etc/mtab} /mnt/backup/ /
real 0m9.065s
user 0m3.821s
sys 0m5.360s
root@trinity:~#
Note: /etc/mtab protected
Looks fine, now what happened to the added files?
Before:
nevj@trinity:~$ ls
compare Documents filter fosstry2 log1 log3 Pictures Templates
Desktop Downloads filter2 junk log2 Music Public Videos
After:
nevj@trinity:~$ ls
compare Documents fosstry2 log2 Music Public Videos
Desktop Downloads log1 log3 Pictures Templates
The 3 files I added after doing the backup have disappeared.
So , yes, it has wound it back to the backup properly.
I conclude that --filter=protect is a valid alternative option to --exclude, for both backups and recoveries… and they both work live.
5 Likes
Major kudos to @nevj and @kovacslt ! That was a ton of work to even type much less think it all through. Thank you. 
Perhaps this is a stupid question but why do people worry about backing up their entire install / all partitions? For my money, I’m only worried about my personal files (documents, pictures, etc) and dotfiles/config directories so I don’t have to set everything up by hand again.
If a drive dies isn’t it quicker to put in a new drive and install from an ISO to get up and running quickly vs using a live environment to clone a USB drive to your new internal drive? Am I missing something?
3 Likes
Two reasons
- if you are doing upgrades… particularly rolling release … it helps to have a recent snapshot to recover to in case the upgrade fails
- if a hard disk fails, it helps to have an image the whole thing… I know you can easily reinstall Linux, but configuring can take some time.
Absolutely right. I rsync my data directory every night before shutdown. I takes only a minute or so.
You can get anything else back by reinstalling, but your personal stuff is your responsibility.
3 Likes
Test backing up a filesystem with tar
Tar can be used ‘live’ to backup data directories.
It can be quite tricky to control the way tar uses pathnames and wildcards
when you are specifying the files to be backed up.
For example , lets say I attempt to backup files in my home directory
mount /dev/sdf2 /mnt/backupusb
tar -czvpf /mnt/backupusb/home.tar.gz /home/nevj/*
tar: Removing leading `/' from member names
/home/nevj/compare
tar: Removing leading `/' from hard link targets
/home/nevj/Desktop/
/home/nevj/Documents/
/home/nevj/Downloads/
/home/nevj/filter3
/home/nevj/fosstry2
/home/nevj/log1
/home/nevj/log2
/home/nevj/log3
/home/nevj/Music/
/home/nevj/Pictures/
/home/nevj/Public/
/home/nevj/Templates/
/home/nevj/Videos/
root@trinity:~# ls -a /mnt/backupusb
. .. home.tar.gz
It only backed up files and directories, NOT dot files ( files whose name begins with dot)
Also it prepended a path to each filename.
You can inspect the tarfile contents with
root@trinity:~# tar -tf /mnt/backupusb/home.tar.gz
home/nevj/compare
home/nevj/Desktop/
home/nevj/Documents/
home/nevj/Downloads/
home/nevj/filter3
home/nevj/fosstry2
home/nevj/log1
home/nevj/log2
home/nevj/log3
home/nevj/Music/
home/nevj/Pictures/
home/nevj/Public/
home/nevj/Templates/
home/nevj/Videos/
So you can see the prepended filenames
Now, I am going to remove a file
m compare
ls
Desktop Downloads fosstry2 log2 Music Public Templates
Documents filter3 log1 log3 Pictures tar1 Videos
and try to recover it with tar
tar -xvf /mnt/backupusb/home.tar.gz home/nevj/compare
home/nevj/compare
ls
Desktop Downloads fosstry2 log1 log3 Pictures tar1 Videos
Documents filter3 home log2 Music Public Templates
ls home
nevj
ls home/nevj
compare
So it recovered the file compare , but it put it in /home/nevj/home/nevj/compare`
So, if you are not careful, tar will give you directory creep
The creep problem is causeed by specifying a pathname when you specify the files to be backed up.
Tar will do what you say exactly and prepend that path to every file it backs up.
The other, missing dotfiles problem, is caused by using ‘*’. You should use ‘.’.
Tar does not have the ‘trailing slash’ facility of rsync.
So the right way to do it is as follows
cd ~nevj
tar -czvpf /mnt/backupusb/home.tar.gz .
tar -tf /mnt/backupusb/home.tar.gz
rm -r Public
ls
Desktop Downloads fosstry2 log2 Pictures Templates
Documents filter3 log1 log3 tar1 Videos
tar -xvf /mnt/backupusb/home.tar.gz ./Public
./Public/
ls
Desktop Downloads fosstry2 log2 Pictures tar1 Videos
Documents filter3 log1 log3 Public Templates
You have to be in the directory you wish to backup… I used cd before doing tar. In the first post of this topic @kovacslt
used the --directory option.
Note the . at the end of the tar backup command. There is no path prepended, and the . means
‘everything in the current directory’.
This time I removed the directory Public , and then restored it.
There is no directory creep this time… The directory Public was restored to its correct
position in my home directory.
And one final point… I did this to a usb flash drive in Peppermint… and there was no sync issue like
I found with rsync . Maybe I need to try a larger tarfile..
So, summary for tar users
- be careful with pathnames
- be in the directory you are archiving, and use
.not*to specify all files - dont put the tar archive file in the directory you are backing up. You can put it on an internal disk, but be careful where.
5 Likes
Thanks. The hard work is actually done by @nevj.
I just wrote some words about tar originally.
But now! Tadammm!
I took a VM with LMDE7 installed and upgraded.
Added a second virtual disk, formatted to ext4, and mounted in /mnt/backup.
Nothing special so far.
After several trials and errors, which I don’t want to detail now, I found a line which seems to work:
rsync -aAXh --progress --verbose --exclude=/{sys,proc,media,mnt,run,tmp,var/run,var/tmp,var/lib/ureadahead,etc/mtab} --include=/home/*/.*/*** --include=/home/*/.** --exclude=/home/*/* / /mnt/backup
This creates a copy of the live system in /mnt/backup. Note, that I intentionally excluded /mnt as a whole just to be safe 
Intentionally excluded all the non-dot files from home directories, this is what --exclude=/home/*/* tells, BUT included the dot files (--include=/home/*/.**) and dot directories and ALL of those contents (--include=/home/*/.*/*** )
So this didn’t back up data, but settings only.
The result output was:
var/spool/cron/
var/spool/cron/crontabs/
var/spool/cups/
var/spool/cups/tmp/
var/spool/libreoffice/
var/spool/libreoffice/uno_packages/
var/spool/libreoffice/uno_packages/cache/
var/spool/rsyslog/
sent 8,19G bytes received 6,42M bytes 39,48M bytes/sec
total size is 8,16G speedup is 1,00
root@klteszt:/mnt/backup#
Just looked around in the output, some random samples (it is too long, I won’t paste here):
40,29K 100% 194,77kB/s 0:00:00 (xfr#8873, ir-chk=1143/14940)
usr/lib/firmware/intel/sof-tplg/sof-rpl-rt1316-l12-rt714-l0.tplg
28,91K 100% 139,06kB/s 0:00:00 (xfr#8874, ir-chk=1142/14940)
usr/lib/firmware/intel/sof-tplg/sof-rpl-rt711-4ch.tplg
45,90K 100% 220,80kB/s 0:00:00 (xfr#8875, ir-chk=1141/14940)
usr/lib/firmware/intel/sof-tplg/sof-rpl-rt711-l0-rt1316-l12-rt714-l3.tplg
41,42K 100% 198,28kB/s 0:00:00 (xfr#8876, ir-chk=1140/14940)
usr/lib/firmware/intel/sof-tplg/sof-rpl-rt711-l0-rt1316-l12.tplg
34,92K 100% 165,56kB/s 0:00:00 (xfr#8877, ir-chk=1139/14940)
Checked the backed up home closely:
root@klteszt:/mnt/backup/home/kl# ls -lah
összesen 140K
drwx------ 8 kl kl 4,0K febr 3 13.58 .
drwxr-xr-x 3 root root 4,0K okt 16 09.23 ..
-rw------- 1 kl kl 515 febr 3 13.56 .bash_history
-rw-r--r-- 1 kl kl 220 okt 16 09.23 .bash_logout
-rw-r--r-- 1 kl kl 3,5K okt 16 09.23 .bashrc
drwx------ 13 kl kl 4,0K jan 12 09.21 .cache
drwxr-xr-x 14 kl kl 4,0K jan 12 09.21 .config
-rw-r--r-- 1 kl kl 27 okt 16 09.26 .dmrc
-rw-r--r-- 1 kl kl 245 okt 16 09.41 .gtkrc-2.0
-rw-r--r-- 1 kl kl 516 okt 16 09.23 .gtkrc-xfce
drwxrwxr-x 2 kl kl 4,0K okt 16 09.29 .icons
drwxrwxrwx 3 kl kl 4,0K jan 12 13.53 .linuxmint
drwxr-xr-x 4 kl kl 4,0K okt 16 09.26 .local
-rw-r--r-- 1 kl kl 807 okt 16 09.23 .profile
-rw-r--r-- 1 kl kl 0 okt 16 09.26 .sudo_as_admin_successful
drwxrwxr-x 2 kl kl 4,0K okt 16 09.29 .themes
-rw-r----- 1 kl kl 6 febr 3 13.58 .vboxclient-clipboard-tty7-control.pid
-rw-r----- 1 kl kl 5 febr 3 13.58 .vboxclient-clipboard-tty7-service.pid
-rw-r----- 1 kl kl 6 febr 3 13.58 .vboxclient-draganddrop-tty7-control.pid
-rw-r----- 1 kl kl 5 febr 3 13.58 .vboxclient-draganddrop-tty7-service.pid
-rw-r----- 1 kl kl 5 febr 3 13.58 .vboxclient-hostversion-tty7-control.pid
-rw-r----- 1 kl kl 6 febr 3 13.58 .vboxclient-seamless-tty7-control.pid
-rw-r----- 1 kl kl 5 febr 3 13.58 .vboxclient-seamless-tty7-service.pid
-rw-r----- 1 kl kl 6 febr 3 13.58 .vboxclient-vmsvga-session-tty7-control.pid
-rw-r----- 1 kl kl 5 febr 3 13.58 .vboxclient-vmsvga-session-tty7-service.pid
-rw------- 1 kl kl 52 febr 3 13.58 .Xauthority
-rw------- 1 kl kl 19K febr 3 14.16 .xsession-errors
-rw------- 1 kl kl 20K febr 3 13.53 .xsession-errors.old
Indeed, only dot files and directories are present.
Looked at .local:
root@klteszt:/mnt/backup/home/kl# cd .local/
root@klteszt:/mnt/backup/home/kl/.local# ls -lah
összesen 16K
drwxr-xr-x 4 kl kl 4,0K okt 16 09.26 .
drwx------ 8 kl kl 4,0K febr 3 13.58 ..
drwxr-xr-x 12 kl kl 4,0K febr 3 13.52 share
drwx------ 4 kl kl 4,0K jan 12 13.17 state
root@klteszt:/mnt/backup/home/kl/.local#
The non-dot contents are there too.
I think this would work for restore.
I do some deathly harm to this system:
root@klteszt:/mnt/backup/home/kl/.local# cd /etc
root@klteszt:/etc# rm fstab
root@klteszt:/etc# cd /boot
root@klteszt:/boot# ls
config-6.12.43+deb13-amd64 config-6.12.63+deb13-amd64 initrd.img-6.12.43+deb13-amd64 initrd.img-6.12.63+deb13-amd64 System.map-6.12.48+deb13-amd64 vmlinuz-6.12.43+deb13-amd64 vmlinuz-6.12.63+deb13-amd64
config-6.12.48+deb13-amd64 grub initrd.img-6.12.48+deb13-amd64 System.map-6.12.43+deb13-amd64 System.map-6.12.63+deb13-amd64 vmlinuz-6.12.48+deb13-amd64
root@klteszt:/boot# rm -rf grub
root@klteszt:/boot#
Additionally, infect the /etc with a “malicious” settings dir:
root@klteszt:~$ cd /etc
root@klteszt:/etc# mkdir blabla
root@klteszt:/etc#
Now do the restore:
rsync -aAXh --progress --verbose --delete --filter=protect_{/proc/***,/sys/***,/mnt/***,/dev/***,/run/***,/var/run/***,/var/tmp/***,/var/lib/ureadahead/***,/var/lib/udisks2/***,/etc/mtab,/home/*/*} /mnt/backup/* /
(Thanks @nevj for the syntax of filter=protect_!).
What it did:
root@klteszt:/boot# rsync -aAXh --progress --verbose --delete --filter=protect_{/proc/***,/sys/***,/mnt/***,/dev/***,/run/***,/var/run/***,/var/tmp/***,/var/lib/ureadahead/***,/var/lib/udisks2/***,/etc/mtab,/home/*/*} /mnt/backup/* /
sending incremental file list
deleting etc/blabla/
boot/
boot/grub/
boot/grub/grub.cfg
10,28K 100% 0,00kB/s 0:00:00 (xfr#1, ir-chk=1018/1049)
boot/grub/grubenv
1,02K 100% 1000,00kB/s 0:00:00 (xfr#2, ir-chk=1017/1049)
boot/grub/unicode.pf2
2,41M 100% 191,67MB/s 0:00:00 (xfr#3, ir-chk=1016/1049)
I split here, because many files restore into that dir, the exact list is not important now…
That’s important, fstab is restored for example:
boot/grub/themes/linuxmint/icons/windows.png
385 100% 1,25kB/s 0:00:00 (xfr#398, ir-chk=1034/1468)
boot/grub/themes/linuxmint/icons/xubuntu.png
526 100% 1,71kB/s 0:00:00 (xfr#399, ir-chk=1033/1468)
etc/
etc/fstab
211 100% 0,66kB/s 0:00:00 (xfr#400, ir-chk=1310/1767)
etc/cups/
etc/cups/subscriptions.conf
679 100% 1,74kB/s 0:00:00 (xfr#401, ir-chk=1272/2606)
etc/cups/subscriptions.conf.O
679 100% 1,74kB/s 0:00:00 (xfr#402, ir-chk=1271/2606)
deleting home/kl/.local/share/gvfs-metadata/home-11ff28fd.log
home/kl/
home/kl/.xsession-errors
18,90K 100% 25,49kB/s 0:00:00 (xfr#403, ir-chk=2667/5565)
home/kl/.cache/mesa_shader_cache_db/part0/mesa_cache.idx
4,67K 100% 6,29kB/s 0:00:00 (xfr#404, ir-chk=2566/5565)
home/kl/.local/share/gvfs-metadata/
home/kl/.local/share/gvfs-metadata/home
64 100% 0,09kB/s 0:00:00 (xfr#405, ir-chk=2367/5565)
home/kl/.local/share/gvfs-metadata/home-4caafe27.log
32,77K 100% 44,08kB/s 0:00:00 (xfr#406, ir-chk=2366/5565)
deleting var/lib/apt/lists/partial/deb.debian.org_debian_dists_trixie-updates_InRelease
deleting var/lib/apt/lists/partial/deb.debian.org_debian_dists_trixie-backports_InRelease
var/lib/apt/lists/partial/
deleting var/log/journal/6da5b94533b7477ebdd8e901e676fc04/user-1000@860dc880a37346769d7edf6ffe0ae343-00000000000021a4-0006482c5feff2f6.journal
deleting var/log/journal/6da5b94533b7477ebdd8e901e676fc04/system@860dc880a37346769d7edf6ffe0ae343-0000000000001f5f-0006482c5f635b40.journal
var/log/Xorg.0.log
23,73K 100% 0,00kB/s 0:00:00 (xfr#407, to-chk=83/470081)
var/log/cups/access_log
326 100% 318,36kB/s 0:00:00 (xfr#408, to-chk=34/470081)
var/log/journal/6da5b94533b7477ebdd8e901e676fc04/
var/log/journal/6da5b94533b7477ebdd8e901e676fc04/system.journal
16,78M 100% 219,18MB/s 0:00:00 (xfr#409, to-chk=29/470081)
var/log/journal/6da5b94533b7477ebdd8e901e676fc04/user-1000.journal
8,39M 100% 65,04MB/s 0:00:00 (xfr#410, to-chk=26/470081)
var/log/lightdm/x-0.log
904 100% 7,12kB/s 0:00:00 (xfr#411, to-chk=19/470081)
var/log/sysstat/sa03
15,98K 100% 125,85kB/s 0:00:00 (xfr#412, to-chk=16/470081)
sent 53,54M bytes received 30,75K bytes 1,95M bytes/sec
total size is 8,16G speedup is 152,27
root@klteszt:/boot#
Rebooting, fingers crossed…
It went smooth anyway. 
5 Likes
I have 2 headless servers, one of them I cant reach physically (VPS somewhere in Aruba’s cloud…).
The working state of them are mission-critical
Despite, sometimes I need to try something experiment with something, modify some config, etc, after all, my trial may end up in a dead or zombie, defunct server.
It’s possible to reinstall and reconfigure everything, but it may take a day, or hours at least…
Recovering a snapshot created just before the experiment takes only 5 minutes in worst case.
I’m not worried.
I have Seafile, the server runs on a small computer (ODroid HC4), the clients run on all computers we use here at home. Personal data, documents, etc. are automatically synced to the server from desktops adn laptops, Android phones sync via Foldersync.
The server itself is backed up every day automatically to another “backup” server.
4 Likes
It may be a cacheing issue, USB drives can be very slow.
5..8MB/s maybe even slower for many small files, even with an USB3 flash drive.
I filled up a ton of Kingston Data traveller USB3 drives, typically they were able to write at approx. 10MB/s when writing out images via dd.
Reading speed was way much faster.
2 Likes
I see the point if you use a distro which doesn’t have a downloadable iso. Like Arch, Void, Gentoo.
Thanks Laszlo for the test of the dot files backup!
3 Likes
Yours is very sophisticated.
Some questions
- why
.**rather than.* - what does
/***mean
and some worries
-
the exclude bit
{sys,proc,media,mnt,run,tmp,var/run,var/tmp,var/lib/ureadahead,etc/mtab}
could vary somewhat between different linux distros -
you are using the combination of include and exclude to deal with dot files in the home directory. Their structure could vary with different linux distros too.
It should be OK for any Debian derived distro. -
you have that
***again in the filter-protect option. Why is that better than single*
It is very hard to check the result. You seem to have it right.
Well done
The question I have to face now is … I went for the simplest possible command that looked like it worked… you went for the most technically correct command.
What do we recommend? I think it has to be your approach… we do need to deal with /home… My /home has only dot files … so I can rsync all of it.
Update
I found the pattern matching rules
"
Rsync chooses between doing a simple string match and wildcard matching by checking if the pattern contains one of these three wildcard characters: ‘*’, ‘?’, and ‘[’ :
- a
'?'matches any single character except a slash (/). - a
'*'matches zero or more non-slash characters. - a
'**'matches zero or more characters, including slashes. - a
'['introduces a character class, such as[a-z]or[[:alpha:]], that must match one character. - a trailing
***in the pattern is a shorthand that allows you to match a directory and all its contents using a single rule. For example, specifying"dir_name/***"will match both the"dir_name"directory (as if"dir_name/"had been specified) and everything in the directory (as if"dir_name/**"had been specified)."
It can be found here
3 Likes
You found a source for that information, I used this
article.
You are right. On most systems /run and /var/run are the same just on different mount points. The same goes for tmp and /var/tmp. The sys, proc is no question, I should have added /dev too…
These are runtime directories, which should not be backed up. Luckily in the restore command I had protected /dev so that the restore did not touch it.
That was a mistake of me anyway, the exclude should have looked like --exclude=/{dev,sys,proc,media,mnt,run,tmp,var/run,var/tmp,var/lib/ureadahead,var/lib/udisks2/,etc/mtab}
My home has all bells and whistles even on the empty VM. Such as Desktop, Documents, Pictures directories, and so on…
I wanted to backup only the dot-dirs, such as .config, .local, these are important for the users settings. Also the dot-files in the root of the home, such .profile.
Probably .xsession-errors is not worth to backup, it just matches the pattern.
If something to omit in case of disk space worries, .cache could be a subject of discussion, whether it contains important things to backup?
Anyway, the safe approach is to back it up
As this all is about system backup, so I intentionally excluded non-dot-dirs and files, as those are user data.
Upon restore, --delete is necessery to remove added mess. But of course deleting user data is not a good idea, hence the /home/*/* in filter protect clause.
I recommend to think, to check and verify, ensure the resulting backup is restorable.
I can’t beleive we could provide a full-fledged always working solution in a single simple command, but we can give a skeleton on which the audience can build upon: enhance it to their own needs, complete it, and then use.
Use it with care, as there are caveats, like I already mentioned, MySQL/MariaDB is not to be backed up via rsync during it is running, it needs special care - that’s just an example, probably there are other cases too.
2 Likes
That seems to be the reality.
There are too many cases for a general solution… I think even systemback would fail sometimes.
You have at least solved the /home issues.
Do you think it is worth pursuing a live backup and restore with tar? I am wondering whether anyone would want to use it.
2 Likes
I don’t know. Rsync requires the target to be a Linux-native filesystem to store attributes, ownerships, file persmissions. Tar can encode these into the archive, so it may have a usecase.
For example, backup to an external exFAT formatted drive: rsync will fail, tar can succeed - this is my pre-assumption only, did not test.
2 Likes
OK, I shall continue.
You can see how slow and mistake-ridden I am. …be prepared for another month of tar episodes.
1 Like
Your aren’t alone on that 
Now I thought about it again, and now I see an issue.
Rsync has the --delete option, which is useful when restoring, as it removes mess added to the system since the last backup. Tar does not have such an option, I see this a problem.
So backing up would work, but the restore target should be an empty filesystem to achieve the exact copy of the previously backed up system.
So it’s not that simple…
Alternatively, unpack the tar to a temp dir, and rsync --delete back to the original place…
Rsync seems to be still necessary.
3 Likes
"To remove a file from an existing tar archive, use:
tar --delete -f archive.tar file_to_delete.txt "
Tar does have --delete, but it does something different
I wonder if incremental backup could be twisted to make an incremental restore?
3 Likes
I checked. Among all the tar options, there is nothing that will no what rsync does with --delete.
So the only option for a clean recovery from a tar archive is to empty the target filesystem.
Rather than empty the filesystem with rm -r * , it is better o 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.
Note:
The above is bad advice, but not incorrect
Se post No 228
I will not proceed with tar investigations. The situation is …
- tar is OK for archiving data partitions … live or non-live. Recovery should be to an empty filesystem.
- rsync is a better option for archiving an entire Linux filesystem. With rsync you can archive and recover either live or non-live. The filesystem recovered to does not have to be empty if you use the --delete option.
I did have in mind a rewrite of the original post . I think now that is not really necessary … there is nothing there that is wrong… it just needed testing.
3 Likes
The same caveat as when restoring with rsync to a new filesystem: the partitions UUID’s changed almost for sure. Double check /etc/fstab in the restored system, as well probably grub needs to be reinstalled.
3 Likes
Yes. A reformat with Gparted changes partition UUID’s
I forgot that.
3 Likes