#2553 Issue closed: Support for Recovering A Partition From The Same Partition With No External Source¶
Labels: support / question, fixed / solved / done,
special hardware or VM
sissieadmin opened issue at 2021-01-14 04:52:¶
-
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?
gdha commented at 2021-01-15 15:04:¶
@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.
sissieadmin commented at 2021-01-16 02:37:¶
@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.
sissieadmin commented at 2021-01-16 02:38:¶
@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 but needed to confirm that the few solutions I have found are not applicable.
jsmeix commented at 2021-02-23 15:18:¶
@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.
jsmeix commented at 2021-02-24 13:20:¶
@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
...
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).
[Export of Github issue for rear/rear.]