#3347 PR merged: Skip to add /.snapshots by default to the backup include list¶
Labels: enhancement, fixed / solved / done
jsmeix opened issue at 2024-11-27 08:24:¶
-
Type: Enhancement
-
Impact: High
High impact (i.e. "highly needed") only on SLES with btrfs. -
Reference to related issue (URL):
https://github.com/rear/rear/issues/3346 -
How was this pull request tested?
see below -
Description of the changes in this pull request:
In backup/NETFS/default/400_create_include_exclude_files.sh
skip to add /.snapshots by default to the backup include list
because btrfs snapshots cannot be recreated
jsmeix commented at 2024-11-27 08:31:¶
On SLES16-SP6 with its default btrfs structure
and with this etc/rear/local.conf
OUTPUT=ISO
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://192.168.178.66/nfs
REQUIRED_PROGS+=( snapper chattr lsattr )
COPY_AS_IS+=( /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default )
POST_RECOVERY_SCRIPT=( 'if snapper --no-dbus -r $TARGET_FS_ROOT get-config | grep -q "^QGROUP.*[0-9]/[0-9]" ; then snapper --no-dbus -r $TARGET_FS_ROOT set-config QGROUP= ; snapper --no-dbus -r $TARGET_FS_ROOT setup-quota && echo snapper setup-quota done || echo snapper setup-quota failed ; else echo snapper setup-quota not used ; fi' )
SSH_ROOT_PASSWORD="rear"
USE_DHCLIENT="yes"
FIRMWARE_FILES=( 'no' )
MODULES=( 'loaded_modules' )
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="5"
I get
# usr/sbin/rear -D mkbackuponly
...
Running 'layout/save' stage ======================
Creating disk layout
SLES12-SP1 (and later) btrfs subvolumes setup needed for /dev/vda2 (default subvolume path contains '@/.snapshots/')
Added /dev/vda2 to BTRFS_SUBVOLUME_SLES_SETUP in /var/tmp/rear.5Cyn1w6VGN2YFok/rootfs/etc/rear/rescue.conf
...
Running 'backup' stage ======================
By default skip /.snapshots in the backup include list (btrfs snapshots cannot be recreated)
Making backup (using backup method NETFS)
...
What I get in the backup regarding 'snapshots'
is only the plain .snapshots/ directory.
With the BACKUP_PROG_EXCLUDE+=( /.snapshots ) workaround
(cf.
https://github.com/rear/rear/issues/3346)
there is no .snapshots/ directory in the backup
which does not harm because it gets created anyway
anew from scratch during "rear recover".
jsmeix commented at 2024-11-27 08:39:¶
"rear recover" test worked well for me.
Some details:
Original system:
# lsblk -ipo NAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINTS
NAME TRAN TYPE FSTYPE SIZE MOUNTPOINTS
/dev/sr0 sata rom iso9660 15.3G
/dev/vda virtio disk 15G
|-/dev/vda1 virtio part 8M
|-/dev/vda2 virtio part btrfs 13G /var
| /usr/local
| /tmp
| /srv
| /root
| /home
| /opt
| /boot/grub2/x86_64-efi
| /boot/grub2/i386-pc
| /.snapshots
| /
`-/dev/vda3 virtio part swap 2G [SWAP]
localhost:~/rear.github.master # find /.snapshots -xdev
/.snapshots
/.snapshots/1
/.snapshots/1/snapshot
/.snapshots/1/info.xml
/.snapshots/2
/.snapshots/2/snapshot
/.snapshots/2/info.xml
/.snapshots/2/grub-snapshot.cfg
/.snapshots/9
/.snapshots/9/snapshot
/.snapshots/9/info.xml
/.snapshots/9/grub-snapshot.cfg
...
/.snapshots/16
/.snapshots/16/snapshot
/.snapshots/16/info.xml
/.snapshots/16/grub-snapshot.cfg
/.snapshots/16/filelist-15.txt
/.snapshots/grub-snapshot.cfg
In the ReaR recovery system after "rear recover":
RESCUE localhost:~ # lsblk -ipo NAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINTS
NAME TRAN TYPE FSTYPE SIZE MOUNTPOINTS
/dev/sr0 sata rom iso9660 84.1M
/dev/vda virtio disk 15G
|-/dev/vda1 virtio part 8M
|-/dev/vda2 virtio part btrfs 13G /mnt/local/var
| /mnt/local/usr/local
| /mnt/local/tmp
| /mnt/local/srv
| /mnt/local/root
| /mnt/local/home
| /mnt/local/opt
| /mnt/local/boot/grub2/x86_64-efi
| /mnt/local/boot/grub2/i386-pc
| /mnt/local/.snapshots
| /mnt/local
`-/dev/vda3 virtio part swap 2G
RESCUE localhost:~ # find /mnt/local/.snapshots -xdev
/mnt/local/.snapshots
/mnt/local/.snapshots/1
/mnt/local/.snapshots/1/snapshot
/mnt/local/.snapshots/1/info.xml
jsmeix commented at 2024-11-27 08:41:¶
@rear/contributors
please have a look here if it is OK for you.
Provided there are no objections
I would like to merge it tomorrow afternoon.
jsmeix commented at 2024-11-27 14:09:¶
A side note primarily for my own information
because I detected it right now here:
In the rebooted recreadted system directly after "rear recover":
# find /.snapshots -xdev
/.snapshots
/.snapshots/1
/.snapshots/1/snapshot
/.snapshots/1/info.xml
I called
# yast2 users
but did not change anything therein and just closed it with OK
to get artificially some snapshots created
(YaST creates a snapshot before and after a YaST module run)
so after yast2 users I have now
# find /.snapshots -xdev
/.snapshots
/.snapshots/1
/.snapshots/1/snapshot
/.snapshots/1/info.xml
/.snapshots/2
/.snapshots/2/snapshot
/.snapshots/2/info.xml
/.snapshots/2/grub-snapshot.cfg
/.snapshots/3
/.snapshots/3/snapshot
/.snapshots/3/info.xml
/.snapshots/3/grub-snapshot.cfg
/.snapshots/3/filelist-2.txt
/.snapshots/grub-snapshot.cfg
and - voila! - after reboot I got "magically"
that additional GRUB boot menu entry
Start bootloader from a read-only snapshot
So - hooray! - I now finally understand what "magic"
makes that additional GRUB boot menu entry :-)
jsmeix commented at 2024-11-28 11:04:¶
An addedum to my above side note
https://github.com/rear/rear/pull/3347#issuecomment-2503976318
which is about the SUSE specific additional boot menu entry
Start bootloader from a read-only snapshot
see also
https://github.com/rear/rear/pull/3025#issuecomment-1639798077
which is about another SUSE specific additional boot menu entry
UEFI Firmware Settings
[Export of Github issue for rear/rear.]