8000 COVE backup method to support Cove Data Protection (Backup Manager) · Issue #3463 · rear/rear · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

COVE backup method to support Cove Data Protection (Backup Manager) #3463

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
svlv opened this issue Apr 28, 2025 · 3 comments
Open

COVE backup method to support Cove Data Protection (Backup Manager) #3463

svlv opened this issue Apr 28, 2025 · 3 comments
Labels
enhancement Adaptions and new features

Comments

@svlv
Copy link
svlv commented Apr 28, 2025 •
edited by jsmeix
Loading

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.
@svlv svlv added the enhancement Adaptions and new features label Apr 28, 2025
@svlv svlv mentioned this issue Apr 28, 2025
Open
@jsmeix
Copy link
Member
jsmeix commented Apr 29, 2025 •
edited
Loading

@svlv
thank you for your contribution to ReaR!

I had only a first quick look at your
#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
Copy link
Author
svlv commented Apr 30, 2025

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.

  1. 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 provides site.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 use local.conf to set up things.

  2. 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 that BACKUP=COVE and OUTPUT=ISO because the Backup Manager expects that the ISO will be created and not any other type of OUTPUT.

  3. 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 rescue initrd and kernel via kexec 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
Copy link
Member
jsmeix commented Apr 30, 2025 •
edited
Loading

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement Adaptions and new features
Projects
None yet
3592
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jsmeix @svlv
0