#2838 Issue closed: How to perform restore via sshfs when target environment is different to the source

Labels: support / question, fixed / solved / done

ZENAdmin-Ops opened issue at 2022-07-14 05:11:

Relax-and-Recover (ReaR) Issue Template

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

This isn't an "issue", but rather a question/howto.

I am successfully using ReaR to backup to a remote system via sshfs.

I want to perform a test restore, to confirm that I can restore the backup and to identify potential issues like the one that I have encountered here.

So, I am trying to restore the backup into a test VM on the remote host.

So, the remote environment is different to the source.

The sshfs backup consists of a recovery ISO and a tar archive.

I am booting the recovery ISO in my target VM and then rear will need to connect to the backup host across sshfs to access the tar archive.

I have networking configured in the rear recovery environment.

However, rear recover, cannot access the tar archive

By default, the recovery ISO appears to be looking for the tar archive in the location that it was present during the backup. Which makes sense if I'm performing the restore from the same location.

However, I don't want to touch the original system. I just want to confirm that the backup works and that I can restore it.

I think that I need to modify two files in the recovery environment so that I can change the behaviour of rear recovery

  1. Use a modified rear.conf file where I can specify the local URL to the sshfs server
  2. Modify ssh_config, because I'm using a different port for ssh when performing this test restore

I've tried mounting the recovery ISO with isomount, but I can't locate the relevant files/folders mentioned above.

Am also open to other suggestions if I am going about this the wrong way.

jsmeix commented at 2022-07-14 06:41:

@ZENAdmin-Ops

without your etc/rear/local.conf it is basically impossible
to guess how you actually made your ISO and your backup.

Without your "rear -D recover" debug log output it is impossible
to see how it actually failed in your specific case, see the
section "Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery

Mounting the ISO in the running ReaR recovery system
should be usually useless because normally the ISO
contains not the backup but only the files of the
ReaR recovery system (kernel and initrd).

Normally the replacement hardware or VM
where you run "rear recover" would be in the same
network environment where your original system is
(where you had run "rear mkbackup") so it works same
to access your backup.tar.gz via network.

When your replacement hardware or VM
is in a different network environment
compared to where your original system is,
you need to adapt /etc/rear/local.conf
in the running ReaR recovery system
as needed to access your backup.tar.gz
from the different network environment.

ZENAdmin-Ops commented at 2022-07-14 07:07:

@jsmeix

I've been thinking about this since my earlier post, you confirmed my thoughts. Thanks.

[Export of Github issue for rear/rear.]