#3199 Issue open: Proceed regardless that 'mkrescue' could be destructive with a 'iso' BACKUP_URL?

Labels: support / question

iringor opened issue at 2024-04-05 20:42:

  • ReaR version ("/usr/sbin/rear -V"):
    Relax-and-Recover 2.6 / 2020-06-17
    This also happens to Relax-and-Recover 2.4 / Git for RHEL 7.9

  • If your ReaR version is not the current version, explain why you can't upgrade:

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
    NAME="Red Hat Enterprise Linux"
    VERSION="8.6 (Ootpa)"

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
    For details, please check it from https://github.com/iringor/rear.git
    [root@dvsdsas1 ~]# cat /etc/rear/site.conf | grep . | grep -v ^#
    export TMPDIR="/rear"
    OUTPUT=ISO
    ISO_DIR="/rear"
    OUTPUT_URL=null
    BACKUP=NETFS
    BACKUP_URL=iso:///backup
    REL=cat /etc/redhat-release |awk -F"release" '{print $2}' |awk -F. '{print $1}'
    if [ $REL -le 6 ]; then
    LISTOFBACKUP="$(df -T -x tmpfs -x devtmpfs -x devpts -x sysfs -x proc | grep -oE '/\S+' | grep -v /dev/ | awk '! /^/$|^/boot$/ {print}'| tr '\n' ' ')"
    else
    LISTOFBACKUP="$(df -T -x tmpfs -x devtmpfs -x devpts -x sysfs -x proc | awk 'NR>1{print $7}' | awk '! /^/$|^/boot$/ {print}'| tr '\n' ' ')"
    fi
    LISTOFBACKUP="${LISTOFBACKUP} /var/log/cups /var/log/httpd "
    if [ -f /usr/local/sbin/mondoexclude.txt ]; then
    LISTOFBACKUP="${LISTOFBACKUP}cat /usr/local/sbin/mondoexclude.txt"
    fi
    BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" ${LISTOFBACKUP})
    ISO_MAX_SIZE=4400
    MIGRATION_MODE=false

  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
    VMware

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    x86

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    BIOS GRUB

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    local disk

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
    [root@dvsdsas1 ~]# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
    NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
    /dev/sda /dev/sda disk 20G
    |-/dev/sda1 /dev/sda1 /dev/sda part xfs 1G /boot
    -/dev/sda2 /dev/sda2 /dev/sda part LVM2_member 19G |-/dev/mapper/VolGroup01-root /dev/dm-0 /dev/sda2 lvm xfs 17G /-/dev/mapper/VolGroup01-swap /dev/dm-1 /dev/sda2 lvm swap 2G [SWAP]
    /dev/sdb /dev/sdb disk 200G
    -/dev/sdb1 /dev/sdb1 /dev/sdb part LVM2_member 200G |-/dev/mapper/VolGroup02-LogVol01 /dev/dm-2 /dev/sdb1 lvm xfs 100G /usr/sap/sapmnt |-/dev/mapper/VolGroup02-LogVol02 /dev/dm-3 /dev/sdb1 lvm xfs 40G /install |-/dev/mapper/VolGroup02-LogVol03 /dev/dm-4 /dev/sdb1 lvm xfs 10G /u01 |-/dev/mapper/VolGroup02-lv_swap2 /dev/dm-5 /dev/sdb1 lvm swap 16G [SWAP]-/dev/mapper/VolGroup02-LogVol04 /dev/dm-6 /dev/sdb1 lvm xfs 10G /rear
    /dev/sr0 /dev/sr0 sata rom 1024M

  • Description of the issue (ideally so that others can reproduce it):
    I am getting this email notification everyday even if the mkbackup script is only running once a month.

From: (Cron Daemon) root@server.company.com
Sent: Thursday, April 4, 2024 1:30 AM
To: root@server.company.com
Subject: Cron root@server test -f /var/lib/rear/layout/disklayout.conf && /usr/sbin/rear checklayout || /usr/sbin/rear mkrescue

Proceed regardless that 'mkrescue' could be destructive with a 'iso' BACKUP_URL ?
(default 'No' timeout 300 seconds)
ERROR: The mkrescue workflow does not work for the BACKUP_URL scheme 'iso'
Some latest log messages since the last called script 040_check_backup_and_output_scheme.sh:
2024-04-04 01:30:24.256120130 Including prep/default/040_check_backup_and_output_scheme.sh
2024-04-04 01:30:24.314857703 UserInput: called in /usr/share/rear/prep/default/040_check_backup_and_output_scheme.sh line 30
2024-04-04 01:30:24.350941007 UserInput: No choices specified
2024-04-04 01:30:24.368811100 Proceed regardless that 'mkrescue' could be destructive with a 'iso' BACKUP_URL ?
2024-04-04 01:30:24.386439123 (default 'No' timeout 300 seconds)
2024-04-04 01:30:24.422376325 UserInput: 'read' timed out with non-zero exit code
2024-04-04 01:30:24.477753667 Aborting 'mkrescue' with a 'iso' BACKUP_URL by default Aborting due to an error, check /var/log/rear/rear-dvsdsas1.log for details

  • Workaround, if any:

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

You can drag-drop log files into this editor to create an attachment
or paste verbatim text like command output or file content
by including it between a leading and a closing line of
three backticks like this:

verbatim content

iringor commented at 2024-04-09 23:17:

I think the issue is resolved. I was not aware that when installing rear, it automatically creates a cron for rear mkrescue that runs everyday at 1:30 AM and it looks like this is a default setting. I will comment out this cron for now and if there is no more recurring issue related to this in a week I will close this case. Thanks.

[root@server ~]# grep -R rear /etc/cron*
/etc/cron.d/rear:#30 1 * * * root /usr/sbin/rear checklayout || /usr/sbin/rear mkrescue

jsmeix commented at 2024-04-11 10:56:

@iringor
it seems your issue is similar like this one
https://github.com/rear/rear/issues/2787
where also a cron job broke things.

The /etc/cron.d/rear/ related things
were removed for ReaR 2.5 see
https://github.com/rear/rear/issues/2139
and
https://github.com/rear/rear/issues/1892

See the comments therein why that cron thing is broken
and why I and others are against such cron things.

It seems your issue here is just another case
that shows why that cron thing is broken.

I guess your cron job is a leftover from ReaR 2.4

iringor commented at 2024-04-11 20:25:

Hi Johannes,

Yes, it looks similar. But my issue is now fixed. I could not access https://relax-and-recover.org/ before when I started researching about ReaR. The site was blocked by our IT admin for some reason. I didn't find this in the man pages, but it is mentioned in https://relax-and-recover.org/usage/ that a cron job can be created (or automatically created?) to sync with the rescue image. It is actually a good tool, this "rear checklayout," to alert me if there is a need to create a new image. Thank you.
-Don Ringor

[Export of Github issue for rear/rear.]