#1091 PR merged: Split restoreonly workflow from recover workflow¶
Labels: enhancement, fixed / solved / done
jsmeix opened issue at 2016-11-29 16:08:¶
Now there is a new restoreonly workflow
that is a part of the (unchanged) recover workflow
namely the part that does only restore a backup,
see
https://github.com/rear/rear/issues/987
which is a prerequirement for
https://github.com/rear/rear/issues/1088
"support multiple backups".
jsmeix commented at 2016-11-29 16:16:¶
If there are no furious objections I will merge it soon.
I tested that usual "rear mkbackup" and "rear recover"
still work (at least for me).
gdha commented at 2016-11-29 16:26:¶
@jsmeix only merge it when you are 100% sure it won't break the recover workflow.
jsmeix commented at 2016-11-29 16:32:¶
There are two additional other workflows that are
other parts of the (unchanged) recover workflow:
layoutonly: recreate only the disk layout
finalizeonly: only finalize the recovery
For me 'layoutonly' followed by 'restoreonly' seemd to work
but the final 'finalizeonly' failed to install the bootloader.
I.e. currently the recover workflow is not yet correctly
split into separated sub-workflows.
What works for me is 'recover' which restores an initial
backup of the basic system and installs the bootloader
followed by 'restoreonly' that restores an additional backup.
One must use the new '-C' option to specify the right
config files for 'recover' versus 'restoreonly'.
Here an example that had worked for me:
d25:~/rear # grep -v '^#' etc/rear/local.conf
OUTPUT=ISO
SSH_ROOT_PASSWORD="rear"
USE_DHCLIENT="yes"
d25:~/rear # grep -v '^#' etc/rear/base.conf
this_file_name=$( basename ${BASH_SOURCE[0]} )
LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}.log"
BACKUP_PROG_EXCLUDE=( /root/* /home/* )
BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}"
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://10.160.4.244/nfs
d25:~/rear # grep -v '^#' etc/rear/rest.conf
this_file_name=$( basename ${BASH_SOURCE[0]} )
LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}.log"
BACKUP_ONLY_INCLUDE="yes"
BACKUP_PROG_INCLUDE=( /root/* /home/* )
BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}"
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://10.160.4.244/nfs
d25:~/rear # usr/sbin/rear -C base -d -D mkbackup
Relax-and-Recover 1.19 / Git
Using log file: /root/rear/var/log/rear/rear-d25.log
Sourcing additional configuration file '/root/rear/etc/rear/base.conf'
Using backup archive 'backup-base.tar.gz'
Creating disk layout
Creating root filesystem layout
Copying logfile /root/rear/var/log/rear/rear-d25.log into initramfs as '/tmp/rear-d25-mkbackup-base-partial-2016-11-29T16:17:38+01:00.log'
Copying files and directories
Copying binaries and libraries
Copying kernel modules
Creating initramfs
Making ISO image
Wrote ISO image: /root/rear/var/lib/rear/output/rear-d25.iso (150M)
Copying resulting files to nfs location
Saving /root/rear/var/log/rear/rear-d25.log as rear-d25-mkbackup-base.log to network output location
Creating tar archive '/tmp/rear.5HVHqErloTlXdAE/outputfs/d25/backup-base.tar.gz'
Archived 1249 MiB [avg 8647 KiB/sec] OK
Archived 1249 MiB in 149 seconds [avg 8589 KiB/sec]
Saving /root/rear/var/log/rear/rear-d25.log as /root/rear/var/log/rear/rear-d25-mkbackup-base.log
d25:~/rear # usr/sbin/rear -C rest -d -D mkbackuponly
Relax-and-Recover 1.19 / Git
Using log file: /root/rear/var/log/rear/rear-d25.log
Sourcing additional configuration file '/root/rear/etc/rear/rest.conf'
Using backup archive 'backup-rest.tar.gz'
Creating disk layout
Creating tar archive '/tmp/rear.5UTB72OsoKkZkEB/outputfs/d25/backup-rest.tar.gz'
Archived 158 MiB [avg 23257 KiB/sec] OK
Archived 158 MiB in 8 seconds [avg 20350 KiB/sec]
Saving /root/rear/var/log/rear/rear-d25.log as /root/rear/var/log/rear/rear-d25-mkbackuponly-rest.log
That results on the NFS server those files:
README VERSION backup-base.log backup-base.tar.gz backup-rest.log backup-rest.tar.gz rear-d25-mkbackup-base.log rear-d25.iso
The var/log/rear/rear-d25-mkbackuponly-rest.log
is curently not yet copied to the NFS server.
The recovery looks like this:
RESCUE d25:~ # rear -C base -d -D recover Relax-and-Recover 1.19 / Git Using log file: /var/log/rear/rear-d25.log Sourcing additional configuration file '/etc/rear/base.conf' Running workflow recover within the ReaR rescue/recovery system Starting required daemons for NFS: RPC portmapper (portmap or rpcbind) and rpc.statd if available. Started RPC portmapper 'rpcbind'. RPC portmapper 'rpcbind' available. Started rpc.statd. RPC status rpc.statd available. Using backup archive 'backup-base.tar.gz' NOTICE: Will do driver migration Calculating backup archive size Backup archive size is 1.3G /tmp/rear.AXfryZMO4qR9DI4/outputfs/d25/backup-base.tar.gz (compressed) Comparing disks. Disk configuration is identical, proceeding with restore. Start system layout restoration. Creating partitions for disk /dev/sda (msdos) Creating filesystem of type ext4 with mount point / on /dev/sda2. Mounting filesystem / Creating swap on /dev/sda1 Disk layout created. Restoring from '/tmp/rear.AXfryZMO4qR9DI4/outputfs/d25/backup-base.tar.gz'... Restored 2704 MiB [avg 76936 KiB/sec] OK Restored 2704 MiB in 37 seconds [avg 74857 KiB/sec] Restoring finished. Restore the Mountpoints (with permissions) from /var/lib/rear/recovery/mountpoint_permissions Installing GRUB2 boot loader Finished recovering your system. You can explore it under '/mnt/local'. Saving /var/log/rear/rear-d25.log as /var/log/rear/rear-d25-recover-base.log RESCUE d25:~ # rear -C rest -d -D restoreonly Relax-and-Recover 1.19 / Git Using log file: /var/log/rear/rear-d25.log Sourcing additional configuration file '/etc/rear/rest.conf' Running workflow restoreonly within the ReaR rescue/recovery system Starting required daemons for NFS: RPC portmapper (portmap or rpcbind) and rpc.statd if available. Started RPC portmapper 'rpcbind'. RPC portmapper 'rpcbind' available. RPC status rpc.statd available. Using backup archive 'backup-rest.tar.gz' NOTICE: Will do driver migration Calculating backup archive size Backup archive size is 160M /tmp/rear.XRRC8EHMewgstLn/outputfs/d25/backup-rest.tar.gz (compressed) Restoring from '/tmp/rear.XRRC8EHMewgstLn/outputfs/d25/backup-rest.tar.gz'... Restored 34 MiB [avg 17415 KiB/sec] OK Restored 34 MiB in 3 seconds [avg 11610 KiB/sec] Restoring finished. Restore the Mountpoints (with permissions) from /var/lib/rear/recovery/mountpoint_permissions Finished recovering your system. You can explore it under '/mnt/local'. Saving /var/log/rear/rear-d25.log as /var/log/rear/rear-d25-restoreonly-rest.log RESCUE d25:~ # reboot umounting all filesystems ... syncing disks... waiting 3 seconds before reboot
jsmeix commented at 2016-11-29 16:35:¶
@gdha
I cannot be 100% sure because I cannot test all and everything.
I really tried hard to implement all in an only-additional way
(i.e. without changing any current behaviour).
But I am not a 100% perfect machine ;-)
gdha commented at 2016-11-29 16:43:¶
@jsmeix sure understood (nobody is prefect ;)
Do I understand it correctly that the restoreonly is only useful when
we had a previous mkbackuponly?
jsmeix commented at 2016-11-29 16:58:¶
Normally one or more restoreonly would match
one or more previous mkbackuponly when it is used
as I did above (i.e. for multiple backups).
But I intend that restoreonly should also be useful
when it is used as described in
https://github.com/rear/rear/issues/987
i.e. to recover a system from soft errors
(like deleting all of /lib/) or in general when
the disk layout is not damaged but one cannot
restore the backup from within the running system.
jsmeix commented at 2016-11-29 17:28:¶
The current restoreonly workflow does not yet work
for the usecase as described in
https://github.com/rear/rear/issues/987
because currently there is nothing mounted
at /mnt/local.
With manual mounting the right stuff at /mnt/local before
the restoreonly workflow seems to work for me:
f231:~ # rm -rf /lib* f231:~ # cat /etc/rear/local.conf -bash: /usr/bin/cat: No such file or directory f231:~ # reboot -bash: /sbin/reboot: No such file or directory f231:~ # init 6 -bash: /sbin/init: No such file or directory I did a hard power off switch and booted the local "Relax-and-Recover" GRUB entry then in the recovery system I did: RESCUE f231:~ # mount /dev/sda2 /mnt/local RESCUE f231:~ # RESCUE f231:~ # mount | grep sd /dev/sda2 on /mnt/local type ext4 (rw,relatime,data=ordered) RESCUE f231:~ # RESCUE f231:~ # rear -d -D restoreonly Relax-and-Recover 1.19 / Git Using log file: /var/log/rear/rear-f231.log Running workflow restoreonly within the ReaR rescue/recovery system Starting required daemons for NFS: RPC portmapper (portmap or rpcbind) and rpc.statd if available. Started RPC portmapper 'rpcbind'. RPC portmapper 'rpcbind' available. Started rpc.statd. RPC status rpc.statd available. Using backup archive 'backup.tar.gz' NOTICE: Will do driver migration Calculating backup archive size Backup archive size is 1.2G /tmp/rear.VSrN7cjHqW8Hggh/outputfs/f231/backup.tar.gz (compressed) Restoring from '/tmp/rear.VSrN7cjHqW8Hggh/outputfs/f231/backup.tar.gz'... Restored 2406 MiB [avg 60097 KiB/sec] OK Restored 2406 MiB in 42 seconds [avg 58666 KiB/sec] Restoring finished. Restore the Mountpoints (with permissions) from /var/lib/rear/recovery/mountpoint_permissions Finished recovering your system. You can explore it under '/mnt/local'. RESCUE f231:~ # find /mnt/local/lib* | wc -l 4131 RESCUE f231:~ # reboot umounting all filesystems ... I booted the original system entry in GRUB and I am back to normal operation: f231:~ # mount | grep sda /dev/sda2 on / type ext4 (rw,relatime,data=ordered) f231:~ # grep -v '^#' /etc/rear/local.conf OUTPUT=ISO BACKUP=NETFS BACKUP_OPTIONS="nfsvers=3,nolock" BACKUP_URL=nfs://10.160.4.244/nfs SSH_ROOT_PASSWORD="rear" USE_DHCLIENT="yes" KEEP_BUILD_DIR="" GRUB_RESCUE="yes"
jsmeix commented at 2016-11-30 09:01:¶
Slept over it for one night,
still no dark foreboding,
I think I merge it today.
Of course its current state is only an initial step
but I think it is a first step into the right direction
that should be in GitHub master code so that also
others can easily try it out and report shortcomings
or even regressions that I overlooked so that I could
get things fixed before the official ReaR 2.0 release.
jsmeix commented at 2016-11-30 09:04:¶
Regarding
https://github.com/rear/rear/pull/1091#issuecomment-263638707
The current restoreonly workflow implements
only what its name tells (strictly speaking):
Currently it only restores - nothing more.
I.e. the current restoreonly workflow does not implement
https://github.com/rear/rear/issues/987
cf.
https://github.com/rear/rear/issues/987#issue-173428037
What is needed to recover from such soft errors is to get the tree of filesystems mounted at /mnt/local and then restore the backup therein.
The "get the tree of filesystems mounted at /mnt/local" part
is currently missing - and as far as I see - that part will get
really complicated.
Reason:
Currently - as far as I know - mounting the tree of filesystems
at /mnt/local happens somewhat intermixed with recreating
the layout which is - as far as I see - basically a broken design
in the current "rear recover" implementation.
As far as I know the current "rear recover" implementation
works disk-device by disk-device and for each one it does
partitioning, making filesystem(s), and mounting it/them.
As far as I can imagine this way leads to (currently unsolvable)
issues with "interwoven mounts", cf.
https://github.com/rear/rear/commit/548965e045ac33c8aa02d5d284d590e7c0846ac9
and
https://github.com/rear/rear/issues/497#issuecomment-67485838
and
https://bugzilla.opensuse.org/show_bug.cgi?id=908854#c3
A clean design would split the recreating layout part into
separated sub-parts and it would do each sub-part for
all used device nodes and/or filesystem-like thingies:
Clean up all used disk devices
cf.
https://github.com/rear/rear/issues/799
Create lower level block devices (i.e. partitions)
on all used disk devices (i.e. run parted)
Create higher level block devices (e.g. LVM)
Create filesystems on the right block devices
(i.e. run mkfs.*)
Create btrfs subvolumes (if needed)
Mounting of filesystems and/or btrfs subvolumes
to create the target tree of filesystem-like thingies
below /mnt/local
[Export of Github issue for rear/rear.]