#2886 Issue closed: Losing backups after performing local restore¶
Labels: support / question, fixed / solved / done
ZENAdmin-Ops opened issue at 2022-11-02 10:49:¶
Relax-and-Recover (ReaR) Issue Template¶
Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):
-
ReaR version ("/usr/sbin/rear -V"): 2.6
-
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): Ubuntu 22.04
-
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OUTPUT=USB
BACKUP=NETFS
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash')
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
USB_UEFI_PART_SIZE="1000"
USB_RETAIN_BACKUP_NR=10
-
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR): Hyper-V
-
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
-
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
-
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): USB disk
-
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/loop0 /dev/loop0 loop squashf 4K /snap/bare/5
/dev/loop1 /dev/loop1 loop squashf 63.2M /snap/core20/
/dev/loop2 /dev/loop2 loop squashf 63.2M /snap/core20/
/dev/loop3 /dev/loop3 loop squashf 238.5M /snap/firefox
/dev/loop4 /dev/loop4 loop squashf 238.4M /snap/firefox
/dev/loop5 /dev/loop5 loop squashf 346.3M /snap/gnome-3
/dev/loop6 /dev/loop6 loop squashf 346.3M /snap/gnome-3
/dev/loop7 /dev/loop7 loop squashf 81.3M /snap/gtk-com
/dev/loop8 /dev/loop8 loop squashf 91.7M /snap/gtk-com
/dev/loop9 /dev/loop9 loop squashf 37.1M /snap/hunspel
/dev/loop10 /dev/loop10 loop squashf 45.9M /snap/snap-st
/dev/loop11 /dev/loop11 loop squashf 45.9M /snap/snap-st
/dev/loop12 /dev/loop12 loop squashf 48M /snap/snapd/1
/dev/loop13 /dev/loop13 loop squashf 48M /snap/snapd/1
/dev/loop14 /dev/loop14 loop squashf 284K /snap/snapd-d
/dev/loop15 /dev/loop15 loop squashf 284K /snap/snapd-d
/dev/sda /dev/sda disk 127G
|-/dev/sda1 /dev/sda1 /dev/sda part vfat 512M /boot/efi
`-/dev/sda2 /dev/sda2 /dev/sda part ext4 40G /
/dev/sdb /dev/sdb disk 3.6T
|-/dev/sdb1 /dev/sdb1 /dev/sdb part vfat REAR-EFI 1000M
`-/dev/sdb2 /dev/sdb2 /dev/sdb part ext3 REAR-000 3.6T /media/zen/RE
/dev/sr0 /dev/sr0 rom 1024M
- Description of the issue (ideally so that others can reproduce
it):
I performed a test restore of the rear backups in another VM.
The test restore completed fine.
However, after re-attaching the disk to the original system
I noticed that the label had changed from REAR-000 to REAR-0001,
not really a big deal, I changed it back.
But I had two backups and they have disappeared!
The directory containing the backups is now empty!
I took screenshots of the restore process, which I have in a word document, which I can upload if reviewing the restore process might provide some insight into what has happened.
-
Workaround, if any:
-
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
To paste verbatim text like command output or file content,
include it between a leading and a closing line of three backticks like
```
verbatim content
```
pcahyna commented at 2022-11-02 11:14:¶
I believe that the recovery process leaves a log under /var/log/rear in
the recovered system, which would be better than a document with
screenshots. Can you have a look if the log is there, please? Also there
should be a symlink to it in /root.
ZENAdmin-Ops commented at 2022-11-02 11:26:¶
ZENAdmin-Ops commented at 2022-11-02 12:08:¶
Well I've managed to locate the backups. So that's a relief.
But there is still an issue.
Prior to dismounting the disk and doing the restore, the mount point for
the external disk was:
/media/zen/REAR-000
Now when I issue:
lsblk
The mount point has again reverted to:
/media/zen/REAR-0001
Why would this be happening?
jsmeix commented at 2022-11-02 12:08:¶
I had used USB_RETAIN_BACKUP_NR only once
some longer time ago for a test.
Without checking any details here in
https://github.com/rear/rear/files/9919852/rear-Ubuntu-DR6-recover.log
I see
2022-11-02 21:32:51.029916700 Including finalize/Linux-i386/670_run_efibootmgr.sh
2022-11-02 21:32:51.139179300 Creating EFI Boot Manager entry ...
so UEFI is used and that seems to contradict what is described
about USB_RETAIN_BACKUP_NR in default.conf
# Number of older rescue environments or backups to retain on USB.
# What is more than USB_RETAIN_BACKUP_NR gets automatically removed.
# This is only supported when EXTLINUX is used as bootloader for USB
# see USB_BOOTLOADER and output/USB/Linux-i386/300_create_extlinux.sh
# and this setting is ignored when USB_SUFFIX is set (see above).
USB_RETAIN_BACKUP_NR=2
https://github.com/rear/rear/blob/rear-2.6/usr/share/rear/conf/default.conf#L878
I have no idea why "rear recover" changed what is on the USB disk
(the USB disk content has to be sacrosanct during "rear recover")
in particular why the label changed from REAR-000 to REAR-0001.
A "rear -D recover" debug log file may have helped here.
jsmeix commented at 2022-11-02 12:14:¶
@ZENAdmin-Ops
in general regarding "better safe than sorry"
see section
"Relax-and-Recover versus backup and restore" in
https://en.opensuse.org/SDB:Disaster_Recovery
that reads in particular (excerpt)
It is your task to ensure your backups
are kept safe at a sufficiently secure place.
In particular the place where ReaR writes
a new backup (e.g. a NFS share or a USB disk)
is not a really safe place to also keep old backups
(arbitrary things might go wrong when writing there).
Again:
Of course during "rear recover" nothing of what there is
on the USB disk should ever be changed by ReaR.
pcahyna commented at 2022-11-02 17:03:¶
If you say that the label has changed, is it literally that in the
output of dumpe2fs /dev/sdb2 you see REAR-0001 instead of REAR-000
? Concerning the disappearing backup, do you mean that the files
backup.tar.gz have disappeared, or something more?
pcahyna commented at 2022-11-02 17:08:¶
I.e. is the USB now completely empty, or are only some files missing?
ZENAdmin-Ops commented at 2022-11-02 20:15:¶
It turned out that the contents of the USB is intact.
Somehow the details in /etc/fstab were messed up and the auto-mount of the disk had changed to /media/zen/REAR-0001 rather than /media/zen/REAR-000
So, even when I had changed the mount manually, next time the mount had changed and I had not realised that at the time.
Regards,
Vaughan
pcahyna commented at 2022-11-03 09:37:¶
Thanks for the update. Can we close this issue then?
By the way, I believe that mountpoints under /media are usually not referenced in fstab, the system mounts removable devices there automatically. Shouldn't that be the case?
ZENAdmin-Ops commented at 2022-11-03 09:42:¶
Thanks for the update. Can we close this issue then?
Yes, thanks
By the way, I believe that mountpoints under /media
are usually not referenced in fstab, the system mounts
removable devices there automatically. Shouldn't that be the case?
I’m still learning Linux, so I can’t comment about “usually”, but in my case they’re. And the fact that entry was changed really messed me about.
pcahyna commented at 2022-11-03 09:44:¶
I mean, the right thing might have been to not reference the disk in /etc/fstab at all and referencing it there could be the mistake. What was the problematic line in fstab?
ZENAdmin-Ops commented at 2022-11-03 09:51:¶
Well, I’ve modified the entry now, but the mount point had a “1” appended and I didn’t initially realise that the fstab entry had changed.
I did notice that the mount point had changed. Manually changed it, then assumed that it was “fixed”.
Then after a subsequent restart of course the mount point changed because of the fstab entry, but I wasn’t aware of that initially and it didn’t occur to me that the mount point in fstab had changed. Which then lead me to making conclusions which were false.
Anyway, that’s a mistake that I won’t repeat. If a mount point does change in future, I will check fstab.
Regards,
Vaughan
pcahyna commented at 2022-11-03 10:11:¶
Is that entry in fstab needed at all?
ZENAdmin-Ops commented at 2022-11-03 10:26:¶
That’s an interesting question.
You might have a point there.
Regards,
Vaughan
pcahyna commented at 2022-11-03 10:48:¶
yeah, I do not know the details of removable device automounting either,
but my understanding has been that they get mounted without any fstab
entry. (I have seen them mounted under an user-specific path in /run
instead of system-wide /media though, which is probably not what you
want.)
[Export of Github issue for rear/rear.]