#3217 Issue closed: Check for empty NETFS 'tar' backup¶
Labels: enhancement, cleanup, fixed / solved / done
jsmeix opened issue at 2024-05-03 16:04:¶
Currently there is no check if a NETFS 'tar' backup is empty.
What gets included in a NETFS 'tar' backup
gets specified in $TMP_DIR/backup-include.txt by
backup/NETFS/default/400_create_include_exclude_files.sh
via var/lib/rear/recovery/mountpoint_device that was made by
layout/save/default/340_generate_mountpoint_device.sh
based on the active 'fs' entries disklayout.conf
In certain cases it can happen that backup-include.txt
does not contain '/' or is even empty, e.g. see
starting at
https://github.com/rear/rear/issues/3189#issuecomment-2082615405
and the subsequent comments therein down to
https://github.com/rear/rear/issues/3189#issuecomment-2082981807
So I am thinking about a generic check for an empty NETFS backup
(regardless of multipath or whatever).
My point is that I assume at least '/' must be included
in any backup because it is the basic functionality
that "rear mkbackup" makes a backup of the files
of the basic system so at least '/' must be
backed up (with '--one-file-system').
So in case of a NETFS backup at least '/'
should normally be in backup-include.txt
and - as far as I can imagine - at least an
empty backup-include.txt is always an error.
Cf.
https://github.com/rear/rear/issues/3189#issuecomment-2092992455
By the way:
It seems '/' is last in backup-include.txt
see
https://github.com/rear/rear/issues/3189#issuecomment-2082615405
(excerpt):
2024-04-29 14:45:49.347139698 Backup include list (backup-include.txt contents):
2024-04-29 14:45:49.349245934 /boot/grub2/i386-pc
2024-04-29 14:45:49.351251309 /boot/grub2/x86_64-efi
2024-04-29 14:45:49.353379145 /home
2024-04-29 14:45:49.355323537 /opt
2024-04-29 14:45:49.357239244 /root
2024-04-29 14:45:49.359060043 /srv
2024-04-29 14:45:49.360984958 /tmp
2024-04-29 14:45:49.362798965 /usr/local
2024-04-29 14:45:49.364743496 /var
2024-04-29 14:45:49.366581308 /
But I think it would be better in general to have '/'
first in backup-include.txt to get the files and directories
of the the basic system first stored in backup.tar.gz
so that in particular the directories of the the basic system
get restored first during "rear recover" so that those
directories are already there when later other files
get restored into the basic system directories.
Perhaps the ordering may not actually matter but at least
it looks "unexpected" to store and restore '/' last, cf.
https://github.com/rear/rear/pull/3177#issuecomment-1985926458
jsmeix commented at 2024-05-15 15:42:¶
With
https://github.com/rear/rear/pull/3221
merged
this issue should be fixed.
[Export of Github issue for rear/rear.]