• State Verified Answer
  • +3 person also asked this people also asked this
  • Replies 23 replies
  • Answers 1 answer
  • Subscribers 37 subscribers
  • Views 31171 views
  • Users 0 members are here
Options
Related

Support for RHEL 8, CentOS 8 or Rocky Linux 8? Including Rocky Linux 9

webaccounts
over 4 years ago

Released in May of 2019, when is support for these 2 OS's happening?

CentOS 7 & RHEL 7 become unsupported in 4.5 years and that's the latest you support. Makes things very difficult when we build new machines that are expected to go 5 years out.

For those that have tried. The RHEL 7 agent installs on 8 but can't be loaded into the new 4.18+ kernels.

  • 0 over 2 years ago in reply to webaccounts

    I think I follow. I'm assuming you're referring to a Hyper-V cluster yeah? If so the part I don't follow is the agent on the host so agent-less doesn't work. Are you backing up the host itself? If so, then yes you can't back up the host and then use the host for agent-less. Which is why the host should just be a host and nothing more (normally). If it's agent-less for Hyper-V though, you MUST have the agent on the host in order for it work (I only say that as you mentioned removing the agent from the host, and that's the part where I got lost). 

    Only trying to walk through your situation and help out if I can. I do agree with you though, versioning gets to be problematic with any 'new' releases (or newer), just like with Server 2022. Luckily if we're talking VMs there are ways around this. If you have ESXi then no agents are needed, if you have Hyper-V an agent has to go on each HV host in order to backup the VMs w/o an agent. Regardless of your DP vendor, the agent inside the Hyper-V hosts is needed as there isn't an open API as there is with ESXi. This is exactly how we backup some of the older OSs that Quest no longer supports (and shouldn't) but clients still have for one reason or another. 

  • 0 over 2 years ago in reply to phuff

    With VM's aside, If there is no agent on the hyper-v host can you still back up the host?

  • 0 over 2 years ago in reply to webaccounts

    Assuming the Hyper-V host itself is a physical server, no there is not. The only way to backup physical hardware with RR (or with basically any solution I can think of) is with an agent. 

    If your Hyper-V host is embedded inside ESXi or something like that (just saying), then yes you can. 

    The industry as a whole however would tilt toward NOT backing up the host itself, although that assumes its just a host and doesn't provide any additional features/roles other than Hyper-V. The intent is for it to be a drone, and Data Protection as a whole, assumes as though it is. 

  • 0 over 2 years ago

    Is this being worked on at all? I haven't heard from Quest at all on this outside of the post from 2 years ago. I ask because it was working at 8.2 but not 8.4 or higher. I'm not sure what the hold up is, but everyone is left in the dark right now.

    CentOS 7 is EOL June 2024 and you don't support 8 at all anymore which is now 3 years into it.

    Our IT auditors are going to start complaining on why we still have CentOS 7 versions and haven't started with 8.

  • +1 over 2 years ago in reply to webaccounts

    Rapid Recovery version 6.6 supports CentOS 8.2 kernel version 4.18.0-193. 

    The next version of Rapid Recovery, version 6.7 will support Centos version 8.4 and 9.

  • 0 over 2 years ago in reply to Saul.Greco

    Fantastic. Is there a plan of release for that version? Thanks.

  • 0 over 2 years ago in reply to webaccounts

    We are currently testing. No ETA for the moment.

  • 0 over 1 year ago

    Just to keep this updated for people. Rapid Recovery now supports RHEL 8 & Rocky Linux 8. I have confirmed it's working on at least 3 of ours right now.

    However as mentioned below that this was going to support RHEL/Rocky 9, the latest Rapid Recovery system requirements do not confirm this. I haven't checked to see if this works.

  • 0 over 1 year ago in reply to webaccounts

    I have been trying to get RR 6.7 to work on Alma 9 but get and error with nbd module.  It seems that RR nbd uses a function that is not in the kernel (anymore?)

    make[2]: Entering directory '/usr/src/kernels/5.14.0-70.17.1.el9_0.x86_64'
    CC [M] /var/lib/dkms/nbd/6.7.0.387/build/nbd.o
    /var/lib/dkms/nbd/6.7.0.387/build/nbd.c: In function ‘nbd_bdev_reset’:
    /var/lib/dkms/nbd/6.7.0.387/build/nbd.c:1237:13: error: implicit declaration of function ‘disk_openers’ [-Werror=implicit-function-declaration]
    1237 | if (disk_openers(nbd->disk) > 1)

  • 0 over 1 year ago in reply to cainfotech

    When running the rapidrecovery-config tool to install the kernel modules it will compile and install the rapidrecovery-vss and nbd module. The rapidrecovery-vss module is used for attaching the volumes and backing up the server and the nbd module is used to mount recovery points directly on the Linux server using local_mount. 
    Alma 9 is not yet fully support, but I do have a test machine with the same kernel. The VSS module compiled successfully and the nbd failed with the same error. The backups are completed successfully and have been stable since I upgraded the kernel to 5.14.0-70. Have you confirmed if the VSS module was installed and tried to add the server on the core?