#2607 Issue closed: what are the options to restore rear backup with file:/// option

Labels: discuss / RFC, support / question, no-issue-activity

sunilckhatri opened issue at 2021-04-28 05:19:

Hi,

Performed a rear backup with option BACKUP_URL=file:///software/rear

Need to know a way how to restore the data with such a option
when only ISO can boot the system but the backup location
i.e. /software/rear is not available during the recovery phase.

Sunil

jsmeix commented at 2021-04-28 11:37:

What about
https://github.com/rear/rear/blob/master/.github/ISSUE_TEMPLATE.md

jsmeix commented at 2021-04-28 11:40:

Do perhaps the comments in
https://github.com/rear/rear/issues/2553
help?

jsmeix commented at 2021-04-28 11:45:

Perhaps also
https://github.com/rear/rear/issues/2400#issuecomment-630255235
might help?

sunilckhatri commented at 2021-04-28 15:20:

Hi,

Got the few outputs

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"):
7.9

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

b30svrxt-ebsdb22:~ # cat /etc/rear/local.conf
# Default is to create Relax-and-Recover rescue media as ISO image
# set OUTPUT to change that
# set BACKUP to activate an automated (backup and) restore of your data
# Possible configuration values can be found in /usr/share/rear/conf/default.conf
#
# This file (local.conf) is intended for manual configuration. For configuration
# through packages and other automated means we recommend creating a new
# file named site.conf next to this file and to leave the local.conf as it is.
# Our packages will never ship with a site.conf.
OUTPUT=ISO
OUTPUT_URL=file:///rear
BACKUP=NETFS
#BACKUP_URL=iso:///directory
BACKUP_URL=file:///rear
# Specify any directory or file to be excluded
BACKUP_PROG_EXCLUDE=( '/var/tmp/*' '/var/crash/*' )
# Specify all volume groups to be excluded
#EXCLUDE_VG=(  'vg01'  )
# Specify all filesystems present under the volume groups mentioned above
EXCLUDE_MOUNTPOINTS=( '/u02/admin/t1ebs' '/u02/admin/d1ebs' '/u02/admin/d2ebs' '/u01/crs_1' '/u02/admin/t2ebs' '/u02/admin/t3ebs' '/u02/admin/t4ebs' '/u01/crs' '/u01/app/oracle' '/u01/app/oracle/product/11.2.0/db_2' '/u01/app/oracle/product/11.2.0/db_3' '/u03/data/appld1' '/u03/data/applt1' '/u03/data/applt2' '/u03/data/appld2' '/u03/data/applt3' '/software' '/home/ap' '/u04/oraback' )
AUTOEXCLUDE_MULTIPATH=n

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
HP bl460 g8 blade server

System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
X86_64

Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
Grub2.
BIOS

Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
The storage is SAN presented, from a 3Par array. There is also some NFS.

Filesystem                        1K-blocks      Used Available Use% Mounted on
devtmpfs                           32810768         0  32810768   0% /dev
tmpfs                              32833212    675484  32157728   3% /dev/shm
tmpfs                              32833212   1978296  30854916   7% /run
tmpfs                              32833212         0  32833212   0% /sys/fs/cgroup
/dev/mapper/vg00-lv_root           10229760    458212   9771548   5% /
/dev/mapper/vg00-lv_usr            10213120   3567456   6645664  35% /usr
/dev/mapper/mpatha1                 1013648    429864    583784  43% /boot
/dev/mapper/vg00-lv_var             5101440   3854968   1246472  76% /var
/dev/mapper/vg00-lv_home            2037760    309380   1728380  16% /home
/dev/mapper/vg00-lv_tmp             3037184   2459216    577968  81% /tmp
/dev/mapper/vg00-lv_opt             2021376    774316   1247060  39% /opt
/dev/mapper/vg01-lv_t1ebs           5232512     40964   5191548   1% /u02/admin/t1ebs
/dev/mapper/vg01-lv_d1ebs           5232512     38820   5193692   1% /u02/admin/d1ebs
/dev/mapper/vg01-lv_d2ebs           5232512     47064   5185448   1% /u02/admin/d2ebs
/dev/mapper/vg01-lv_crs_1          31447040  16173656  15273384  52% /u01/crs_1
/dev/mapper/vg01-lv_t2ebs           5232512     49792   5182720   1% /u02/admin/t2ebs
/dev/mapper/vg01-lv_t3ebs           5232512     44928   5187584   1% /u02/admin/t3ebs
/dev/mapper/vg01-lv_t4ebs           5232512     44932   5187580   1% /u02/admin/t4ebs
/dev/mapper/vg01-lv_crs             1046288     33056   1013232   4% /u01/crs
/dev/mapper/vg01-lv_oracle          9426688   4405308   5021380  47% /u01/app/oracle
/dev/mapper/vg00-lv_varlog          2094992    371892   1723100  18% /var/log
/dev/mapper/vg01-lv_db112           8378240   6260624   2117616  75% /u01/app/oracle/product/11.2.0/db_2
/dev/mapper/vg01-lv_db113           8378240   5907824   2470416  71% /u01/app/oracle/product/11.2.0/db_3
/dev/mapper/vg00-lv_varlogaudit      522000     64984    457016  13% /var/log/audit
b30svrxt-ebsap01:/u03/data/appld1  20511360   6295680  13167232  33% /u03/data/appld1
b30svrxt-ebsap01:/u03/data/applt1  20511360    473568  18989344   3% /u03/data/applt1
b30svrxt-ebsap01:/u03/data/applt2  20511360    606560  18856352   4% /u03/data/applt2
b30svrxt-ebsap01:/u03/data/appld2  20511360   1220672  18242240   7% /u03/data/appld2
b30svrxt-ebsap01:/u03/data/applt3  10190144     33888   9631968   1% /u03/data/applt3
b30svrxp-oraap50:/software        314419200 208213504 106205696  67% /software
home_ap:/home/ap                   15718400   8736544   6981856  56% /home/ap
tmpfs                               6566644         0   6566644   0% /run/user/501
/dev/mapper/p_oraback1            104841216  16766084  88075132  16% /u04/oraback
/dev/mapper/vg01-lv_rear            6281088   4731824   1549264  76% /rear
/dev/loop0                           715422    715422         0 100% /cdrom
tmpfs                               6566644         0   6566644   0% /run/user/601

At one stage I tried to download the backup.tar.gz file from the source server to the destination server on which rear recovery was going on using sftp but the download happened partially. Post that sftp session killed.

gdha commented at 2021-05-04 12:01:

@sunilckhatri Perhaps we should remove the local spare disk:
image

It makes no sense to keep the rear image and archive on a local disk. What if this system breaks - how will you retrieve the ISO image from and tar archive? The local spare disk has to be read as a disk that can be removed and stored safely. In case of disaster you can add the disk into another spare disk to retrieve the ISO image.

gdha commented at 2021-06-09 07:18:

@jsmeix What is your opinion on this matter? Should be remove the local spare disk as backup target or is this too short sighted?

jsmeix commented at 2021-06-09 12:11:

I think your comment in
https://github.com/rear/rear/issues/2607#issuecomment-831888189

The local spare disk has to be read as a disk that can be removed and stored safely.

explains it so I think the wording

local spare disk

should be replaced by

removable local disk

or

removable local spare disk

FYI:
In general I do not think a local spare disk must be removable.
It is good when it is removable but that is not mandatory for ReaR to be useful.
I am thinking about a single home user PC or Laptop with
two usual built-in disks where one disk is used for the system and
the other one for backups plus the bootable ReaR recovery system.
Of course when the whole PC burns down or the Laptop falls off the window
all is lost so the user will copy his backups also on external media
to be prepared for manual bare metal disaster recovery on new (different) hardware.
But most often neither the whole PC burns down nor the Laptop falls off the window.
ReaR on a built-in second disk is still useful (to some extent) for less final disasters
like soft errors (e.g. deleted essential files, broken filesystems, or system bootloader issues)
where booting the ReaR recovery system from the other disk (via plain BIOS/UEFI) still works
or when only the system disk breaks down where replacing it by a new disk helps.
Compared to ReaR on external USB disk ReaR on a built-in second disk
is more convenient for such less final disasters because
all what is needed for such kind of disaster recovery is built-in and ready-to-use.
In particular with a Laptop that means one external piece less that one has to care about
(e.g. when travelling one cannot forget the built-in disk).
On the other hand with ReaR on a small USB stick one is prepared even for final disasters
except the Laptop bag that contains the Laptop and the ReaR USB stick burns down ;-)

github-actions commented at 2021-08-09 02:08:

Stale issue message


[Export of Github issue for rear/rear.]