#2531 Issue closed: Recover from HTTP Location

Labels: enhancement, no-issue-activity

sissieadmin opened issue at 2020-11-27 20:49:

  • ReaR version: Relax-and-Recover 2.3 Git

  • OS version: Ubuntu 18.04.05 LTS Bionic

  • Hardware: KVM Guest

  • System architecture: x86_64

  • Firmware: GRUB

  • Storage: Virtual Disk under KVM

  • Storage layout:

vda 30G disk
|-vda1 1024M part
|-vda2 1M part
|_vda3 1G part /boot
|_ubuntu--vg-ubuntu--lv 20G lvm /

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

Attempting to recover backup from HTTP location due to lack of access to physical media in a remote VPS environment.

I want to be able to revert a machine to a backup image over the network, right now I'm thinking over HTTP. I am stuck with a hosting service that does not offer backups or any webconsole access (only SSH after boot), so I cannot rely on interactive bootable media. This looked like a tool that 'may' be able to do this, but I'm a little confused by the HTTP, or any other network support.

Is this use case supported? I have a test environment I can play with.

jsmeix commented at 2020-11-30 11:12:

When using BACKUP=NETFS we support those BACKUP_URL schemes
that are described in "man rear" cf.
https://github.com/rear/rear/blob/master/doc/rear.8.adoc

The basic idea behind BACKUP=NETFS is to use a mountable thingy
(usually a NFS share on a remote NFS server)
so that the remote storage location
(whereto the backup gets written during "rear mkbackup"
and wherefrom the backup is read druring "rear recover")
appears as part of the locally accessible file system of the system
where "rear mkbackup" is run (the original system) and in the exact same way also
where "rear recover" is run (in the ReaR recovery system on replacement hardware).

The crucial point is that the ReaR recovery system runs inside a ramdisk
on the replacement hardware (so things work independent of local disks).
Therefore it is not (easily) possible during "rear recover" to download the
whole backup.tar.gz (several GiB - possibly even up to some TiB) because
the download target would be in the ramdisk.

Depending on what backup program is used (by default 'tar') it would be possible
to restore the backup during "rear recover" when a download from a HTTP location
could be streamed into the backup restore program like

curl http://rear.backup.server/path/to/backup.tar.gz | tar xz ...

Currently this is not supported in ReaR.

You could play around with that manually inside the ReaR recovery system
(by default 'curl' is included in the ReaR recovery system)
and if you get things working as you need it in your particular environment
we would appreciate a GitHub pull request from you
at least as some proof of concept so we could have a look
or ideally even as some basically working solution.

gdha commented at 2020-12-02 17:12:

@sissieadmin Love to see a PR once you succeeded your recovery attempt as I'm sure others will find this an interesting feature to have. Thanks in advance.

sissieadmin commented at 2020-12-24 00:46:

@jsmeix and @gdha

Sorry for the dead air. I'm unlikely to be able to provide a PR for this myself.

I'm still exploring options for this situation and have ruled over a dozen other programs. In short, I do not specifically need to use HTTP as the location, but need a way to restore a server that does not have any extra partitioning or any opportunity for PXE.

Would restoring a local backup on the current single partition be possible?

The documentation seems unclear about this, in that it says "restore from local disk" which can imply rescue partitions. Would Rear support having an edit made to Grub which boots and installs, hands-free, from an image on the one partition/filesystem I have?

This is a use-case that seems very rare nowadays, and Rear seems like the only option that 'may' support it.

github-actions commented at 2021-02-22 02:05:

Stale issue message

[Export of Github issue for rear/rear.]