#3284 Issue closed: Disklayout.conf missing partition (with oracleasm)

Labels: support / question, needs sponsorship, special hardware or VM

NewNow479 opened issue at 2024-07-19 03:57:

  • ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.4 / Git

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): RedHatEnterpriseServer 7

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

This is site.conf from VM 1. The same file exist for VM 2 with AUTOEXCLUDE_DISKS=y

OUTPUT=ISO
OUTPUT_URL=nfs://nfs-server/backup_in/REAR-TEST/

BACKUP=NETFS
BACKUP_PROG=tar
BACKUP_URL=nfs://nfs-server/backup_in/REAR-TEST/
BACKUP_TYPE=incremental

FULLBACKUPDAY="Mon"
AUTOEXCLUDE_DISKS=n

  • Hardware vendor/product = VM on VMWare KVM

  • Firmware = BIOS and bootloader = GRUB

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

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):

[root@node1 ~]# lsblk -ip
NAME                          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
/dev/sda                        8:0    0  160G  0 disk
|-/dev/sda1                     8:1    0    1G  0 part /boot
`-/dev/sda2                     8:2    0  159G  0 part
  |-/dev/mapper/rhel-root     253:0    0 56,2G  0 lvm  /
  |-/dev/mapper/rhel-swap     253:1    0    5G  0 lvm  [SWAP]
  |-/dev/mapper/rhel-tmp      253:2    0  4,7G  0 lvm  /tmp
  `-/dev/mapper/rhel-u01      253:3    0 93,1G  0 lvm  /u01
/dev/sdb                        8:16   0   16G  0 disk
`-/dev/sdb1                     8:17   0   16G  0 part
/dev/sdc                        8:32   0   50G  0 disk
`-/dev/sdc1                     8:33   0   50G  0 part
/dev/sdd                        8:48   0   35G  0 disk
`-/dev/sdd1                     8:49   0   35G  0 part
  `-/dev/mapper/vg_app-lv_app 253:4    0   35G  0 lvm  /app
/dev/sr0                       11:0    1 1024M  0 rom
[root@node1 ~]# lsblk -ipf
NAME                          FSTYPE      LABEL UUID                                   MOUNTPOINT
/dev/sda
|-/dev/sda1                   xfs               0dfb72a7-4b5c-40a3-a112-bda4bb86377b   /boot
`-/dev/sda2                   LVM2_member       dkzOm0-K27j-PVot-QXBF-wBvb-qMgx-zXO5UF
  |-/dev/mapper/rhel-root     xfs               a10256eb-2cdd-430e-a80d-3bafbd8c2c44   /
  |-/dev/mapper/rhel-swap     swap              0387eafb-b07e-4b6c-8866-7880c8d1f868   [SWAP]
  |-/dev/mapper/rhel-tmp      xfs               81524856-ac81-4e57-9cc2-6402f2a5767f   /tmp
  `-/dev/mapper/rhel-u01      xfs               d10a1f41-7018-47fc-9f90-ce5e844d317a   /u01
/dev/sdb
`-/dev/sdb1                   oracleasm   OCR1
/dev/sdc
`-/dev/sdc1                   oracleasm   DATA1
/dev/sdd
`-/dev/sdd1                   LVM2_member       C1qVAh-w7oo-KbD4-4I10-8sem-RDGr-FJ4gOJ
  `-/dev/mapper/vg_app-lv_app xfs               c27ebec4-c8e0-4e4a-bc92-b8429a2a1785   /app
  • Description of the issue (ideally so that others can reproduce it):

I have two virtual machines (VMs) created, each connected to an NFS server that can store backup files as tar and ISO files. Each VM has four disks:

  1. /sda: Boot disk.
  2. /sdb: Shared disk for Oracle database.
  3. /sdc: Another shared disk for Oracle database.
  4. /sdd: Shared disk for log files.

The VMs are set up in an active/active cluster configuration. The main goal of this setup is to create a cluster of two or more VMs and to back up the shared disks.

For VM 1, I specified the option AUTOEXCLUDE_DISKS=n in my site.conf file to ensure all my partitions are recreated during recovery.

For VM 2, I set AUTOEXCLUDE_DISKS=y to avoid saving the shared disks, as VM 1 is responsible for this task.

However, I am encountering an issue on VM 1 where /sdb is not partitioned or specified in the disklayout.conf file when I boot from the rescue image with my backup on VM 1, while /sdc is.

Example here of disklayout.conf :

# Disk /dev/sda
# Format: disk <devname> <size(bytes)> <partition label type>
disk /dev/sda 171798691840 msdos
# Partitions on /dev/sda
# Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
part /dev/sda 1073741824 1048576 primary boot /dev/sda1
part /dev/sda 170720755712 1074790400 primary lvm /dev/sda2
# Disk /dev/sdb
# Format: disk <devname> <size(bytes)> <partition label type>
disk /dev/sdb 17179869184 msdos
# Partitions on /dev/sdb
# Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
# Disk /dev/sdc
# Format: disk <devname> <size(bytes)> <partition label type>
disk /dev/sdc 53687091200 msdos
# Partitions on /dev/sdc
# Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
part /dev/sdc 53686042624 1048576 primary none /dev/sdc1
# Disk /dev/sdd
# Format: disk <devname> <size(bytes)> <partition label type>
disk /dev/sdd 37580963840 msdos
# Partitions on /dev/sdd
# Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
part /dev/sdd 37579915264 1048576 primary lvm /dev/sdd1

As you can see in this example, there is a missing line for /dev/sdb specifying the partition size, partition start, and type, such as: part /dev/sdb <partition_size> <partition_start> primary none /dev/sdb1.
No partition is specified for /dev/sdb1

I'm also adding diskdeps.conf :

[root@node1 ~]#  cat /var/lib/rear/layout/diskdeps.conf
/dev/sda1 /dev/sda
/dev/sda2 /dev/sda
/dev/sdc1 /dev/sdc
/dev/sdd1 /dev/sdd
/dev/vg_app pv:/dev/sdd1
pv:/dev/sdd1 /dev/sdd1
/dev/rhel pv:/dev/sda2
pv:/dev/sda2 /dev/sda2
/dev/mapper/rhel-root /dev/rhel
/dev/mapper/rhel-swap /dev/rhel
/dev/mapper/rhel-tmp /dev/rhel
/dev/mapper/rhel-u01 /dev/rhel
/dev/mapper/vg_app-lv_app /dev/vg_app
fs:/ /dev/mapper/rhel-root
fs:/tmp /dev/mapper/rhel-tmp
fs:/tmp fs:/
fs:/u01 /dev/mapper/rhel-u01
fs:/u01 fs:/
fs:/app /dev/mapper/vg_app-lv_app
fs:/app fs:/
fs:/boot /dev/sda1
fs:/boot fs:/

And disk_mapping :

[root@node1~]# cat /var/lib/rear/layout/disk_mappings
/dev/sda /dev/sda
/dev/sdb /dev/sdb
/dev/sdc /dev/sdc
/dev/sdd /dev/sdd

And disktodo.conf :

[root@node1~]# cat /var/lib/rear/layout/disktodo.conf
todo /dev/sda disk
todo /dev/sda1 part
todo /dev/sda2 part
todo /dev/sdb disk
todo /dev/sdc disk
todo /dev/sdc1 part
todo /dev/sdd disk
todo /dev/sdd1 part
todo pv:/dev/sdd1 lvmdev
todo pv:/dev/sda2 lvmdev
todo /dev/vg_app lvmgrp
todo /dev/rhel lvmgrp
todo /dev/mapper/rhel-root lvmvol
todo /dev/mapper/rhel-swap lvmvol
todo /dev/mapper/rhel-tmp lvmvol
todo /dev/mapper/rhel-u01 lvmvol
todo /dev/mapper/vg_app-lv_app lvmvol
todo fs:/ fs
todo fs:/tmp fs
todo fs:/u01 fs
todo fs:/app fs
todo fs:/boot fs
todo swap:/dev/mapper/rhel-swap swap

As you can see, the todo /dev/sdb1 part is missing, but my partition is functional (see lsblk output below).

Can someone try to help me on this one ? @jsmeix

Steps to Reproduce

  1. Create two VMs connected to an NFS server.
  2. Configure the VMs with four disks as described.
  3. Set up rear backup with AUTOEXCLUDE_DISKS=n in site.conf (cf sife.conf below).
  4. Perform a rear backup. (The issue should already be evident at this step, check disklayout.conf)
  5. Boot from the rear rescue image and initiate recovery.
  6. Observe that /sdb is not partitioned or included in disklayout.conf.

Expected Behavior
Both /sdb and /sdc should be partitioned and included in the disklayout.conf file during the recovery process, ensuring all shared disks are correctly restored.

Actual Behavior
Only /sdc is partitioned, and /sdb is missing from the disklayout.conf file during the recovery process.

NewNow479 commented at 2024-07-19 05:34:

Hello,

My issue was resolv while upgrading rear from 2.4 to 2.7.

I had some issue finding the good ".rpm" for RHEL 7.

Could you give me some repositories/link with ".rpm" file of rear 2.7 for RHEL 8 and RHEL 9 ?

Thanks guys.

gdha commented at 2024-07-19 06:02:

@NewNow479 Thank you for using ReaR and do the effort for the extensive testing. ReaR v2.7 was released 2 years ago and you can find it at http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/CentOS_8/x86_64/
The latest snapshots you can find at https://github.com/rear/rear/releases/tag/snapshot

The good news is that the ReaR team is working on ReaR v3.0 to be released within a couple of months. Stay tuned I would say.

NewNow479 commented at 2024-07-22 00:32:

@gdha Thanks for your reply.

Using Rear v2.7, I have an issue with my disk. Using the same configuration as above, my disk /dev/sdb is now present in 'disklayout.conf', but when my system is fully recovered, the file systems 'oracleasm OCR1' and 'oracleasm DATA1' are not correctly setup.

Do you know if I need other options for oracleasm to work correctly in my site.conf file? As I explained, the only difference between my two VMs in the site.conf file is that I specify AUTOEXCLUDE_DISKS=n in my VM 1 and AUTOEXCLUDE_DISKS=y in VM 2 because my disks /sdb, /sdc, and /sdd are shared between VM 1 and VM 2.

I can recreate an issue and close this one if needed.

NewNow479 commented at 2024-07-23 00:57:

Hello,

I would like to keep this issue open. In addition to my previous question about the necessary configuration for oracleasm, when my Oracle cluster is running, my disk /dev/sdb oracleasm OCR1 is not added to my disklayout.conf even though I switched to ReaR v2.7. However, my disk /dev/sdc oracleasm DATA1 is properly added to the disklayout.conf.

I can provide additional logs if needed. I have read the default.conf documentation in its entirety and apart from the exclude dev/oracleasm directory, I haven't seen any other information regarding the operation with oracleasm. Does dev/oracleasm is needed in order for my cluster to run correclty when recover or it's will be recreated by oracle automaticly when reboot ?

Could you provide guidance on the necessary configuration? Does ReaR support this type of system? And if needed, which log should I check to see why my partition is not being added to my disklayout.conf?

Thanks for the help.

gdha commented at 2024-09-09 07:49:

@NewNow479 I assume issue #3316 is about the same? I complete lost track of this issue. However, OracleASM (https://docs.oracle.com/cd/B28359_01/server.111/b31107/toc.htm for those who wonder where we are talking about) is not (yet) supported within ReaR - see also an old issue comment - https://github.com/rear/rear/issues/373#issuecomment-38553577

NewNow479 commented at 2024-12-09 00:04:

Hi @gdha,

Thank you for your reply. As you mentioned that this feature is not yet implemented and is currently out of scope, do you think it might be included in the Rear 3.0 roadmap?

Looking forward to your thoughts.

Best regards

gdha commented at 2024-12-14 08:53:

Hi @gdha,

Thank you for your reply. As you mentioned that this feature is not yet implemented and is currently out of scope, do you think it might be included in the Rear 3.0 roadmap?

Looking forward to your thoughts.

None of the ReaR developers have OracleASM in use.
Therefore, we need sponsoring or help from users who are willing to help us with the implementation.

gdha commented at 2026-09-04 10:14:

Since Dec 2024 the situation with the ReaR contributors did not change - no OracleASM available to use nor test.
We close this issue for now, if a sponsor is found then we can see what we can do.

[Export of Github issue for rear/rear.]