#3463 Issue open
: COVE backup method to support Cove Data Protection (Backup Manager)¶
Labels: enhancement
svlv opened issue at 2025-04-28 13:20:¶
Platform¶
Linux x64
Is your feature request related to a problem? Please describe.¶
The Cove team would like to propose an integration with the Backup
Manager. It will allow to use new COVE
backup method.
Describe the solution you'd like¶
The Backup Manager integration with Relax-and-Recover will be implemented and tested by the Cove team.
jsmeix commented at 2025-04-29 13:08:¶
@svlv
thank you for your contribution to ReaR!
I had only a first quick look at your
https://github.com/rear/rear/pull/3464
and made some quick comments FYI.
But I could not yet do an actual analysis.
To do that I need to get some basic understanding
how the Backup Manager is meant to work.
Currently I am wondering why during "rear recover"
the Backup Manager must be downloaded in any case.
I read that the Backup Manager needs to be
installed on the partitioned target disks
and launched from there to restore the backup.
But I do not yet understand why the Backup Manager
could not get included in the ReaR recovery system
during "rear mkrescue" or "rear mkbackup" and then
during "rear recover" the included Backup Manager
could get installed onto the target disk.
I ask because for all other backup methods in ReaR
the backup restore tool and all what it needs to run
(libraries, config files, whatever else) get included
in the ReaR recovery system during "rear mkrescue"
or "rear mkbackup" so the backup restore tool is available
"ready to use" from within the ReaR recovery system
without the need to download the backup restore tool
from some external location.
With certain ReaR OUTPUT methods like OUTPUT=USB
but (to some extent) also with OUTPUT=ISO
the backup can be included on the same medium
where the ReaR recovery system system is
so the user can create one single medium
(in particular a bootable external disk via OUTPUT=USB)
that is self-contained for a disaster recovery.
As far as it currently looks like, it seems this
is (currently) not possible with BACKUP=COVE.
To avoid possible misunderstanding:
It is no problem when some functionality or feature
is not supported by certain backup methods in ReaR.
I only like to get some basic understanding
how the BACKUP=COVE method is meant to work.
svlv commented at 2025-04-30 09:54:¶
Hello @jsmeix. Thank you for your time and comments. I am in progress of applying them.
Let me explain how the Backup Manager integration with Relax-and-Recover is intended to work.
-
Backup Manager installation flow
We added the ReaR tarball created by
make dist
into the Backup Manager installer (it's RUN package created via makeself). During the Backup Manager installation process the ReaR tarball is extracted to/opt/MXB/rear
directory./opt/MXB
is not a static folder in meaning that Cove users may have different installation location but this location in predefined by the particular installer. Additionally, the Backup Manager installer providessite.conf
config file. It contains at the moment:BACKUP=COVE OUTPUT=ISO ISO_PREFIX="cove-rear" # static URL to CDN to download BM COVE_INSTALLER_URL="https://cdn.cloudbackup.management/maxdownloads/mxb-linux-x86_64.run" # it depends on the installer COVE_INSTALL_DIR="/opt/MXB"
And some workarounds for Ubuntu but I am planning to propose fixes for that, so
site.conf
should contain only this params.The idea behind
site.conf
is to provide some predefined default values that are controlled by the Backup Manager. But users still can uselocal.conf
to set up things. -
Backup flow
Users must have two data sources: Files and folders and System state for Linux. System state for Linux is the ISO rescue image created by ReaR. The Backup Manager under the hood launches
rear mkrescue
(rear
here is/opt/MXB/rear/usr/sbin/rear
) and then backs up the created ISO image. It is supposed thatBACKUP=COVE
andOUTPUT=ISO
because the Backup Manager expects that the ISO will be created and not any other type ofOUTPUT
. -
Recovery flow
Users need to restore the backed up ISO image and then boot the device from this ISO rescue image.
As you mentioned, ReaR downloads the installation package from the internet and the Backup Manager is installed on the target disks. By this we are solving the following problems:
- The Backup Manager included to the ISO image may be outdated and not compatible with new storage nodes.
- The Backup Manager requires certificates and they will be outdated even if they are copied to the ISO image. Moreover, the authorisation during the installation process is chanding at the moment to improve the security.
- Updating the Backup Manager during BMR
- Keep the ISO image as small as possible
Currently we are working on creating the generic ISO image that will be used to get the rescue ISO image created by ReaR which is device-specific one. This generic ISO won't contain the Backup Manager as well but will download and install it.
- Process flow with genetic ISO
After the installation, the Backup Manager restores the ISO image created by ReaR. Next,
initrd
for the rescue system is repacked to move the Backup Manager files into the rescue system. Next, the system is booted from the rescueinitrd
and kernel viakexec
call. In this case the Backup Manager will be provided by the generic ISO and won't be downloaded from the internet. But we would like to support two ways: recovery directly from the rescue ISO created by ReaR (in that case users need to restore the rescue ISO, also it can be a workaround if the generic ISO is not bootable on the target device) and recovery from the generic ISO (it's more automated, users can use one single ISO to recover different devices). It is also a point why we do not include the Backup Manager in the rescue system.
Also, as far as I know, we are not really the first who want to download the agent from the internet, e.g. 410_use_replica_cdm_cluster_cert.sh
jsmeix commented at 2025-04-30 11:19:¶
@svlv
thank you for your explanations!
Today I won't find time to read them and
tomorrow is public holiday in Germany
and I am on vacation on Friday
so (hopefully) next week...
[Export of Github issue for rear/rear.]