#3339 Issue closed: Directories Missing in REAR Backup, openSUSE Tumbleweed¶
Labels: support / question, fixed / solved / done
cbmiller2610 opened issue at 2024-11-02 19:55:¶
ReaR version ("/usr/sbin/rear -V"): Relax-andRecover 2.7 / 2022-07-13
If your ReaR version is not the current version, explain why you can't upgrade: https://software.opensuse.org/package/rear official version is at 2.7, no other community packages provide a newer version so I would have to build my own.
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
NAME="openSUSE Tumbleweed"
# VERSION="20241011"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20241011"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
# CPE 2.3 format, boo#1217921
CPE_NAME="cpe:2.3:o:opensuse:tumbleweed:20241011:*:*:*:*:*:*:*"
#CPE 2.2 format
#CPE_NAME="cpe:/o:opensuse:tumbleweed:20241011"
BUG_REPORT_URL="https://bugzilla.opensuse.org"
SUPPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
/etc/rear/local.conf"):
local.conf.txt
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR): PC
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): Linux x64
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): UEFI, GRUB
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): NVMe with secondary SSD
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/sda /dev/sda sata disk 465.8G
`-/dev/sda1 /dev/sda1 /dev/sda part btrfs OFFLOAD 465.8G /OFFLOAD
/dev/sdb /dev/sdb usb disk 10.9T
`-/dev/sdb1 /dev/sdb1 /dev/sdb part btrfs Chris_Backup 10.9T /run/media/cbmiller/Chris_Backup
/dev/nvme0n1 /dev/nvme0n1 nvme disk 931.5G
|-/dev/nvme0n1p1 /dev/nvme0n1p1 /dev/nvme0n1 nvme part vfat 512M /boot/efi
|-/dev/nvme0n1p2 /dev/nvme0n1p2 /dev/nvme0n1 nvme part btrfs 899.8G /var, /usr/local, /srv, /root, /opt, /home, /boot/grub2/x86_64-efi, /boot/grub2/i386-pc, /.snapshots, /
`-/dev/nvme0n1p3 /dev/nvme0n1p3 /dev/nvme0n1 nvme part swap 31.3G [SWAP]
Description of the issue (ideally so that others can reproduce it):
My NVMe drive recently began to mount read only (btrfs) and show errors
with btfrs check. After replacing the drive and using the rear rescue
ISO to attempt to recover, I ran into
https://github.com/rear/rear/issues/3338.
After working through that, I realized that some directories are
missing, despite not being called out as excluded by REAR in the
local.conf, or otherwise. For example, my /opt directory was for sure
not backed up at all, and neither was /usr/local/texlive.
Workaround, if any: none
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug
log files):
Creation of the most recent backup:
rear-localhost.27988.log
cbmiller2610 commented at 2024-11-03 15:38:¶
Update again... apologies for cluttering up the issues, I didn't search for the right things until I began to understand more about the problem. My issue is likely this: https://github.com/rear/rear/issues/2928, clearly I should have specified the subvolumes to be explicitly included in the backup. This can be seen in the backup log, where it did not descend into either /var, /usr/local, or likely any of the other default suse btrfs subvolumes:
I am closing https://github.com/rear/rear/issues/3338 as it looks redundant to https://github.com/rear/rear/issues/2927.
I'll leave this issue open, just to get confirmation:
- Are the fixes in https://github.com/rear/rear/issues/2928 and https://github.com/rear/rear/issues/2927 expected to be incorporated in REAR 2.8?
- In the meanwhile, is using this template https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/examples/SLE12-SP2-btrfs-example.conf#L48 designed to prevent both of those issues by explicitly including snapper/chattr, and by explicitly including the subvolumes? Or, is there still expected to be an issue (especially for the snapper/chattr thing) in REAR 2.7 even when using this template?
Thanks for providing such a flexible and powerful backup solution, and sorry again for posting on topics that may have been already settled!
jsmeix commented at 2024-11-05 10:31:¶
https://github.com/rear/rear/issues/2927
is fixed in current GitHub master code
by the two fixes
https://github.com/rear/rear/commit/64e9228e9178e717534526ba8ccd9a51af0cb4a8
and
https://github.com/rear/rear/commit/bfb4edf8ee30ebecb75b4019f86bc8f0a3e81460
https://github.com/rear/rear/issues/2928
should be fixed in current GitHub master code by
https://github.com/rear/rear/pull/3175
together with several other related fixes
but currently - off the top of my head -
I don't know whether or not
/.snapshots must be excluded from the backup restore
cf.
https://github.com/rear/rear/pull/3175#issuecomment-2151951631
i.e. whether or not one must manually specify
in /etc/rear/local.conf something like
BACKUP_PROG_EXCLUDE+=( /.snapshots )
to avoid what I described in the BUT part in
https://github.com/rear/rear/pull/3175#issuecomment-2111776529
and also in
https://github.com/rear/rear/pull/3175#issuecomment-2112519793
@cbmiller2610
I would much appreciate it if you could
test our current ReaR upstream GitHub master code
as described in the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
and provide feedback how far things "just work"
with openSUSE Tumbleweed on your particular system
in your particular environment.
See also the section
"Version upgrades with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
To avoid too high expectations note that
in general openSUSE Tumbleweed cannot be
a supported Linux distribution for ReaR upstream,
see the section
"Supported and Unsupported Operating Systems"
in our release notes, currently online at
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt#L3862
which reads (excerpt)
In theory ReaR 2.7 should work on openSUSE Tumbleweed
but in practice arbitrary failures could happen at any time
because the Tumbleweed distribution is a pure
rolling release version of openSUSE containing
the latest stable versions of all software
(cf. https://en.opensuse.org/Portal:Tumbleweed)
so arbitrary changes of any software are possible at any time
that could arbitrarily break how ReaR works.
cf. the section
"No disaster recovery without testing and continuous validation"
in
https://en.opensuse.org/SDB:Disaster_Recovery
which reads (excerpt)
You must continuously validate that the recovery still works
on the replacement hardware in particular
after each change of the basic system.
So a rolling release operating system contradicts
a prerequirement of disaster recovery which is
to have a stable basic system.
[Export of Github issue for rear/rear.]