#3143 Issue `closed`: Implementing own backup method in rear¶

Labels: support / question, no-issue-activity

DheerajSS2000 opened issue at 2024-01-30 10:37:¶

ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.7 / Git
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="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86 compatible
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
GRUB
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):

NAME                        KNAME     PKNAME    TRAN   TYPE FSTYPE      LABEL   SIZE MOUNTPOINT
/dev/sda                    /dev/sda            sata   disk                    1000G 
|-/dev/sda1                 /dev/sda1 /dev/sda         part ext4                  1G /boot
`-/dev/sda2                 /dev/sda2 /dev/sda         part LVM2_member         999G 
  |-/dev/mapper/centos-root /dev/dm-0 /dev/sda2        lvm  xfs               897.3G /
  |-/dev/mapper/centos-swap /dev/dm-1 /dev/sda2        lvm  swap                  4G [SWAP]
  `-/dev/mapper/centos-home /dev/dm-2 /dev/sda2        lvm  xfs                97.7G /home
/dev/sr0                    /dev/sr0            ata    rom                     1024M

Description of the issue (ideally so that others can reproduce it):

I want to implement my own backup method in rear, so what and all changes it need to make to make it integrate with rear

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

schlomo commented at 2024-01-31 14:42:¶

Welcome to ReaR!

Just to satisfy my curiosity: Can you share your motivation for creating your own backup tooling? ReaR already supports a lot of open source backup tools, e.g. Duplicity, RBME, Borg, Baroes and of course it can simply create an archive on a file share or on the USB media or even on a DVD. What feature is missing from those?

What you want to achieve is actually very simple, please take a look at #3138 for an example of how I'm adding a new backup method (this one only restores data because PPDM is a commercial backup tool that does the backup on its own).

In general, you'll be adding some files under the following directories under usr/share/rear/:

prep - prepare stuff for the backup or creating the rescue image
backup - to actually create a backup if you want to run that from within ReaR
verify - preparatins for the restore (runs in rescue system), e.g. start services or figure out what to restore
restore - actually restore the backup

The way ReaR is built allows you to simply drop files into the appropriate folders, e.g. you could create your own my-rear package that would depend on rear and add some more files with your stuff.

jarppiko commented at 2024-02-11 12:34:¶

Hello,

I just experienced an SSD crash wiping the whole system drive unreadable and to prepare for similar event in the future, I am determined to implement an disaster recovery solution. ReaR topped the search results and I am having the very same question than the OP.

The issue with traditional backup systems is that a disk has awful lot of files that do not need to be backed up at all:

All application files and libraries: I would rather just save the list of packages (Ubuntu) installed and "recover" those by reinstalling those after the 1st stage system recovery.
The order of recovery should be such that the applications are installed first and only then settings (/etc) and /home would be recovered from a file backup. And even here I would like to be selective what backup (e.g. just container recipes, not containers itself)
I am a btrfs user and I probably would like to customize a bit how recovery is done i.e. what directory is a btrfs subvolume. But this is not that important since it can do these manually later.

github-actions commented at 2024-04-12 02:05:¶

Stale issue message

jsmeix commented at 2024-04-12 05:32:¶

@jarppiko
regarding "I would rather just save the list of packages (Ubuntu) installed and 'recover' those by reinstalling those":

We have currently the backup methods
BACKUP=ZYPPER (for SUSE) and BACKUP=YUM (for Red Hat), see
https://github.com/rear/rear/blob/master/doc/user-guide/14-ZYPPER-and-YUM.adoc

We do not have such a backup method for Ubuntu or Debian.

In particular regarding Ubuntu:
I am not a Ubuntu user
(and I won't find time to test things on Ubuntu).
We at ReaR upstream do not have an active maintainer for Ubuntu
(and it seems Canonical is not sufficiently interested in ReaR)
so ReaR support for Ubuntu can be only as good as voluntary
contributors who use Ubuntu contribute - which is much appreciated!

So you would have to implement needed functionality on your own
by making appropriate GitHub pull requests here, see
https://en.opensuse.org/SDB:Disaster_Recovery#How_to_contribute_to_Relax-and-Recover
and
https://github.com/rear/rear/wiki/Coding-Style
or alternatively
you pay one of the ReaR upstream maintainers
to implement it for you, see
http://relax-and-recover.org/support/
and
http://relax-and-recover.org/support/sponsors

github-actions commented at 2024-06-12 02:18:¶