Issue title: Support for Recovering A Partition From The Same Partition With No External Source
 Issue body: * 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):

I expect this to be a "no" considering how ReaR tends to work, but I'm stuck in a situation where I have no control over the network (no PXE booting), and no ability to add a secondary partition or USB device. This is a VPS that provides no backups or any support for snapshotting that would normally allow me to achieve this easily.

But I have to come up with a way to back up and restore a full image of a system with no extra storage, no network source like PXE, other than the partition I am supposed to restore.

Is this even possible?
 Comments: 
 Comment 0: @sissieadmin If your cloud provider allows nothing then it becomes very difficult. At least they should foresee some kind of snapshotting. If nothing is possible I would start looking for another VPS provider.
 Comment 1: > @sissieadmin If your cloud provider allows nothing then it becomes very difficult. At least they should foresee some kind of snapshotting. If nothing is possible I would start looking for another VPS provider.

That's what I was afraid of.

Unfortunately this is a situation I have inherited, but I have ruled out a couple dozen options for accomplishing what I need to do, and perhaps this may be enough to drive a change.
 Comment 2: > @sissieadmin If your cloud provider allows nothing then it becomes very difficult. At least they should foresee some kind of snapshotting. If nothing is possible I would start looking for another VPS provider.

Thank you anyway. I know this is a very unusual situation, I had already concluded that it was unlikely to be doable.
 Comment 3: @sissieadmin 
you need at least one separated whole disk where the ReaR stuff
(ReaR recovery system plus the backup) can be stored
and wherefrom the ReaR recovery system can be booted
and wherefrom the backup can be restored.

You cannot do that with one the same disk via separated partitions.

Reason:
During "rear recover" the target system disk(s) get completely
recreated from scratch starting with `parted mklabel` command(s)
followed by `parted mkpart` commands that completely destroy
all existing partitioning information on the disk.

So you need at least two disks:
The system's normal operating disk and a second disk for ReaR.

Because that second disk is usually a USB disk
the matching method in ReaR is called "USB"
which is set up in etc/rear/local.conf like
```
OUTPUT=USB
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
```
as described in
http://relax-and-recover.org/documentation/getting-started

The exact same "USB" method also works with a second built-in disk.

So your VPS provider would have to provide you
a VPS with two separated virtual disks.

FYI:
I used ReaR on QEMU/KVM virtual machines with two virtual disks
to simulate a USB disk when there are issues with ReaR's "USB" method.

 Comment 4: @sissieadmin 
as always sleeping over an issue helps me to better see how things actually are.

In short:
It is possible to use ReaR only on a single system disk with limited functionality
according to what one can reasonably expect in such a limited environment.

What is possible in such a limited environment is basically only
a plain restore of a backup that is stored on a separated partition
on that single system disk.

Obviously when that single system disk gets damaged
(in particular when the partition table gets damaged
or when bootloader things get corrupted) all is lost.

But what can be recovered are so called "soft errors" in the operating sytem
like deleted or corrupted essential files - i.e. all where a plain restore of a
backup of the files helps where the restore is run from "outside" i.e. from
within the booted ReaR recovery system so that the backup restore does not
depend on some files (programs libraries whatever) of the operating sytem.

I used a KVM/QEMU virtual machine with this disk layout:
```
# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT

NAME        KNAME     PKNAME   TRAN TYPE FSTYPE   SIZE MOUNTPOINT
/dev/sda    /dev/sda           ata  disk           10G 
|-/dev/sda1 /dev/sda1 /dev/sda      part            8M 
|-/dev/sda2 /dev/sda2 /dev/sda      part ext4     3.6G /
|-/dev/sda3 /dev/sda3 /dev/sda      part ext3     5.4G /other
`-/dev/sda4 /dev/sda4 /dev/sda      part swap     1.1G [SWAP]
```
Intentionally I did not use the complicated openSUSE btrfs structure,
cf. "btrfs" in https://en.opensuse.org/SDB:Disaster_Recovery

I used current ReaR upstream GitHub master code as described in
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery

You use ReaR version 2.3 which is too old for that
because the new "mountonly" workflow is nice to have here.
You could mount things manually and then things could
also work with ReaR 2.3 but I did not (and will not) test that.

I use this etc/rear/local.conf
```
localhost:~/rear.github.master # grep -v '^#' etc/rear/local.conf 

OUTPUT=ISO
OUTPUT_URL=null
BACKUP=NETFS
BACKUP_URL=file:///other/rear
SSH_ROOT_PASSWORD='rear'
USE_DHCLIENT="yes"
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="3"
FIRMWARE_FILES=( 'no' )
MODULES=( 'loaded_modules' )
GRUB_RESCUE=y
```

I use `FIRMWARE_FILES=( 'no' )` and `MODULES=( 'loaded_modules' )`
to get a small ReaR recovery system and I don't need more for
recovery on the exact same (virtual) machine.

The crucial part is `GRUB_RESCUE=y`
see usr/share/rear/conf/default.conf what it does (excerpt)
```
Note that GRUB_RESCUE is the only functionality
where "rear mkbackup" or "rear mkrescue"
changes the currently running system.
It changes the currently running system even
in a critical way because it changes the bootloader
of the currently running system.
The main reason for the GRUB_RESCUE functionality
is to be quickly able to recover a system from soft errors
(like deleting all of /lib/)
```

After `mkdir /other/rear` I did
```
localhost:~/rear.github.master # usr/sbin/rear -D mkbackup

Relax-and-Recover 2.6 / Git
Running rear mkbackup (PID 7882 date 2021-02-24 13:46:20)
Using log file: /root/rear.github.master/var/log/rear/rear-localhost.log
Running workflow mkbackup on the normal/original system
Using backup archive '/other/rear/localhost/backup.tar.gz'
Using '/usr/bin/mkisofs' to create ISO filesystem images
Adding backup directory mountpoint 'fs:/other' to EXCLUDE_RECREATE
Using autodetected kernel '/boot/vmlinuz-5.3.18-46-default' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /root/rear.github.master/var/lib/rear/layout/disklayout.conf
Excluding component fs:/other in EXCLUDE_RECREATE
Marking component 'fs:/other' as done in /root/rear.github.master/var/lib/rear/layout/disktodo.conf
Disabling excluded components in /root/rear.github.master/var/lib/rear/layout/disklayout.conf
Disabling component 'fs ... /other' in /root/rear.github.master/var/lib/rear/layout/disklayout.conf
Using sysconfig bootloader 'grub2'
Verifying that the entries in /root/rear.github.master/var/lib/rear/layout/disklayout.conf are correct
Created disk layout (check the results in /root/rear.github.master/var/lib/rear/layout/disklayout.conf)
Creating recovery system root filesystem skeleton layout
Handling network interface 'eth0'
eth0 is a physical device
Handled network interface 'eth0'
Included current keyboard mapping (via 'dumpkeys -f')
Included default US keyboard mapping /usr/share/kbd/keymaps/legacy/i386/qwerty/defkeymap.map.gz
Included other keyboard mappings in /usr/share/kbd/keymaps
Copying logfile /root/rear.github.master/var/log/rear/rear-localhost.log into initramfs as '/tmp/rear-localhost-partial-2021-02-24T13:46:24+01:00.log'
Copying files and directories
Copying binaries and libraries
Copying only currently loaded kernel modules (MODULES contains 'loaded_modules')
Omit copying files in /lib*/firmware/ (FIRMWARE_FILES='no')
Skip copying broken symlink '/etc/resolv.conf' target '/run/netconfig/resolv.conf' on /proc/ /sys/ /dev/ or /run/
Skip copying broken symlink '/etc/mtab' target '/proc/19035/mounts' on /proc/ /sys/ /dev/ or /run/
Testing that the recovery system in /tmp/rear.Mg6xH5guyYRQS8M/rootfs contains a usable system
Testing each binary with 'ldd' and look for 'not found' libraries within the recovery system
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (60288965 bytes) in 11 seconds
Making ISO image
Wrote ISO image: /root/rear.github.master/var/lib/rear/output/rear-localhost.iso (69M)
Setting up GRUB_RESCUE: Adding Relax-and-Recover rescue system to the local GRUB 2 configuration.
Finished GRUB_RESCUE setup: Added 'Relax-and-Recover' GRUB 2 menu entry.
Making backup (using backup method NETFS)
Creating tar archive '/other/rear/localhost/backup.tar.gz'
Preparing archive operation
Archived 39 MiB [avg 10152 KiB/sec] 
...
Archived 1034 MiB [avg 4271 KiB/sec] 
OK
WARNING: tar ended with return code 1 and below output (last 5 lines):
  ---snip---
  tar: /sys: file changed as we read it
  ----------
This means that files have been modified during the archiving
process. As a result the backup may not be completely consistent
or may not be a perfect copy of the system. Relax-and-Recover
will continue, however it is highly advisable to verify the
backup in order to be sure to safely recover this system.

Archived 1034 MiB in 251 seconds [avg 4220 KiB/sec]
Exiting rear mkbackup (PID 7882) and its descendant processes ...
Running exit tasks
You should also rm -Rf /tmp/rear.Mg6xH5guyYRQS8M
```

Now making a "soft error":
```
localhost:~/rear.github.master # rm -r /lib*

localhost:~/rear.github.master # ls
-bash: /usr/bin/ls: No such file or directory

localhost:~/rear.github.master # cat /etc/fstab
-bash: /usr/bin/cat: No such file or directory

localhost:~/rear.github.master # reboot
-bash: /sbin/reboot: No such file or directory
```
pretty broken system so recovery is needed.

Rebooting the system via hard power off
shows the new GRUB boot menue entry:
```
Relax-and-Recover
```
This boots the ReaR recovery system.

The ReaR recovery system bootloader files are in particular
```
/boot/rear-initrd.cgz
/boot/rear-kernel
```
When those files get deleted or damaged 
the ReaR recovery system cannot be booted.

I logged in via ssh into the booted ReaR recovery system
(one can do things also directly on the ReaR recovery system console
 but I prefer working from remote via my usual `xterm` terminal program).

In the ReaR recovery system I did:
```
Welcome to Relax-and-Recover. Run "rear recover" to restore your system !

RESCUE localhost:~ # lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME        KNAME     PKNAME   TRAN TYPE FSTYPE   SIZE MOUNTPOINT
/dev/sda    /dev/sda           ata  disk           10G 
|-/dev/sda1 /dev/sda1 /dev/sda      part            8M 
|-/dev/sda2 /dev/sda2 /dev/sda      part ext4     3.6G 
|-/dev/sda3 /dev/sda3 /dev/sda      part ext3     5.4G 
`-/dev/sda4 /dev/sda4 /dev/sda      part swap     1.1G 

RESCUE localhost:~ # mkdir /other
RESCUE localhost:~ # mount /dev/sda3 /other
RESCUE localhost:~ # find /other
/other
/other/lost+found
/other/rear
/other/rear/localhost
/other/rear/localhost/backup.log
/other/rear/localhost/backup.tar.gz

RESCUE localhost:~ # rear -h
...
List of commands:
 recover         recover the system
 restoreonly     only restore the backup
 mountonly       use ReaR as live media to mount and repair the system
 opaladmin       administrate TCG Opal 2-compliant self-encrypting disks

RESCUE localhost:~ # rear -D mountonly
Relax-and-Recover 2.6 / Git
Running rear mountonly (PID 789 date 2021-02-24 14:08:31)
Using log file: /var/log/rear/rear-localhost.log
Running workflow mountonly within the ReaR rescue/recovery system
Comparing disks
Device sda has expected (same) size 10737418240 bytes (will be used for 'mountonly')
Disk configuration looks identical
UserInput -I DISK_LAYOUT_PROCEED_RECOVERY needed in /usr/share/rear/layout/prep-for-mount/default/250_compare_disks.sh line 148
Proceed with 'mountonly' (yes) otherwise manual disk layout configuration is enforced
(default 'yes' timeout 30 seconds)

UserInput: No real user input (empty or only spaces) - using default input
UserInput: No choices - result is 'yes'
User confirmed to proceed with 'mountonly'
Marking component '/dev/sda' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/sda1' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/sda2' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/sda3' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/sda4' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'fs:/' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'swap:/dev/sda4' as done in /var/lib/rear/layout/disktodo.conf
Start target system mount.
Mounting filesystem /
Disk layout processed.
Finished 'mountonly'. The target system is mounted at '/mnt/local'.
Exiting rear mountonly (PID 789) and its descendant processes ...
Running exit tasks
You should also rm -Rf /tmp/rear.4bBQ4Pgj0Yrb79k

# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME        KNAME     PKNAME   TRAN TYPE FSTYPE   SIZE MOUNTPOINT
/dev/sda    /dev/sda           ata  disk           10G 
|-/dev/sda1 /dev/sda1 /dev/sda      part            8M 
|-/dev/sda2 /dev/sda2 /dev/sda      part ext4     3.6G /mnt/local
|-/dev/sda3 /dev/sda3 /dev/sda      part ext3     5.4G /other
`-/dev/sda4 /dev/sda4 /dev/sda      part swap     1.1G

RESCUE localhost:~ # rear -D restoreonly
Relax-and-Recover 2.6 / Git
Running rear restoreonly (PID 1991 date 2021-02-24 14:10:00)
Using log file: /var/log/rear/rear-localhost.1991.log
Running workflow restoreonly within the ReaR rescue/recovery system
Using backup archive '/other/rear/localhost/backup.tar.gz'
Calculating backup archive size
Backup archive size is 1.1G     /other/rear/localhost/backup.tar.gz (compressed)
Restoring from '/other/rear/localhost/backup.tar.gz' (restore log in /var/lib/rear/restore/restoreonly.backup.tar.gz.1991.restore.log) ...
Backup restore program 'tar' started in subshell (PID=2665)
Restored 160 MiB [avg. 54699 KiB/sec] 
...
Restored 2580 MiB [avg. 23592 KiB/sec] 
OK
Restored 2606 MiB in 115 seconds [avg. 23211 KiB/sec]
Restoring finished (verify backup restore log messages in /var/lib/rear/restore/restoreonly.backup.tar.gz.1991.restore.log)
Created SELinux /mnt/local/.autorelabel file : after reboot SELinux will relabel all files
Recreating directories (with permissions) from /var/lib/rear/recovery/directories_permissions_owner_group
Finished 'restoreonly'. The target system is mounted at '/mnt/local'.
Saving /var/log/rear/rear-localhost.1991.log as /var/log/rear/rear-localhost.log
Exiting rear restoreonly (PID 1991) and its descendant processes ...
Running exit tasks
You should also rm -Rf /tmp/rear.bUKCW0XuvmAx9rD

RESCUE localhost:~ # chroot /mnt/local

localhost:/ # ls
.autorelabel  bin  boot  dev  etc  home  lib  lib64  lost+found  mnt  opt  other  proc  root  run  sbin  selinux  srv  sys  tmp  usr  var

localhost:/ # cat /etc/fstab
UUID=980f784c-d80f-49c4-9f05-1fd06058057b  /       ext4  defaults      0  1
UUID=c4468e8c-99df-4a9b-868b-f19ef9a6d59d  /other  ext3  data=ordered  0  2
UUID=e7ba193b-b702-4250-8b39-c6c1c9d1ccd1  swap    swap  defaults      0  0

localhost:/ # exit
exit

RESCUE localhost:~ # reboot
umounting all filesystems
...
syncing disks... waiting 3 seconds before reboot
```

The rebooted restored system works again normally
(at least for me in my quick above test).


{'source': 'GithubIssues', 'repo_name_with_owner': 'rear/rear', 'issue_id': 785649315, 'repo_stars': 710.0}