#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"):

BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash')
  • 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


/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:

Now when I issue:

The mount point has again reverted to:

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
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).


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:

in general regarding "better safe than sorry"
see section
"Relax-and-Recover versus backup and restore" in
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).

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.


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.


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.


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.]