#987 Issue closed: RFC: Implement a backup restore workflow that can work on its own.¶
Labels: enhancement, won't fix / can't fix / obsolete
jsmeix opened issue at 2016-08-26 11:05:¶
Hereby I ask for comments whether or not it could make sense
to have a new "rear restoreonly" workflow as counterpart
of "rear mkbackuponly".
The following issue triggered this RFC:
http://lists.relax-and-recover.org/pipermail/rear-users/2016-August/003414.html
It reads (excerpts):
> Is there a way to skip deleting the partitions? > so just a way to then get REAR to copy the files back ... in the recovery system "rear recover" ... should use the disk as is, only restore the backup and exit? I.e. you ask for a counterpart of "rear mkbackuponly" in the recovery system like "rear restoreonly"
The main use-cases that I have in mind for "restoreonly"
is the main use-case for GRUB_RESCUE, see default.conf:
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/) without digging out the rear recovery boot medium.
After soft errors like deleting all of /lib/ there is no need
to recreate partitioning and filesystems.
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.
After backup restore one needs probably additionally
recreating the initrd and reinstalling the bootloader
because after backup restore the kernel could have
changed (replaced by an older kernel from the backup).
My personal interest is to try to clean up the currently
single-big-and-fat "recover" workflow, see
http://lists.relax-and-recover.org/pipermail/rear-users/2016-August/003418.html
(excerpts)
> ... by deactivating all entries > in disklayout.conf one can skip successfully that during > "rear recover" any partitions are deleted, created, and > that any filesystems are created. But what does not work is that when I only deactivate the 'disk' and 'part' entries but keep the 'fs' and 'swap' entries, then "rear recover" fails ... Currently "rear recover" is not prepared to skip only certain parts of partitioning and making filesystems. ... when I do partitioning plus creating filesystems plus mounting alltogether at /mnt/local manually, then "rear recover" proceeeds for me ... it restores the backup. After backup restore it fails when installing the bootloader (GRUB 2 in my case) so that I also need to do this stuff manually
It seems there are currently some "obscure"
interdependencies in the whole "recover" workflow
so that it either works as a whole or not at all.
I would like to investigate why that is and
if I could clean it up so that separated parts
of the "recover" workflow can run separated.
A "restoreonly" workflow would be only a nice
side-effect of such an overall clean-up.
gdha commented at 2016-09-29 09:26:¶
@jsmeix is that not the purpose of real backup software? Rear should be strong in DR, and leave the restore of missing files to the backup software. IMHO - we shouldn't please everybody.
schlomo commented at 2016-09-29 09:41:¶
Patches are always welcome, especially if they help some users without
harming anybody else.
I also would not spend core team time on that right now.
Am 29.09.2016 11:26 vorm. schrieb "gdha" notifications@github.com:
@jsmeix https://github.com/jsmeix is that not the purpose of real
backup software? Rear should be strong in DR, and leave the restore of
missing files to the backup software. IMHO - we shouldn't please everybody.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/issues/987#issuecomment-250415937, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAGMCEWoNVgs2wCXlmLkhi2uo3Q_UlFjks5qu4RVgaJpZM4Jt-Sp
.
jsmeix commented at 2016-09-29 09:54:¶
Many thanks for your feedback!
This is certainly not a high-priority issue for me.
As time permits I will have a look if it can be done
with reasonable effort and without the risk to
cause regressions elsewhere.
jsmeix commented at 2016-11-25 19:33:¶
It seems this one is the exact matching required counterpart
if "Multiple Backup Methods" can be done as described in
https://github.com/rear/rear/issues/1088#issuecomment-262981954
and subsequent comments.
jsmeix commented at 2016-11-30 11:55:¶
https://github.com/rear/rear/pull/1091
provides an initial version of a restoreonly workflow
that implements only what its name tells (strictly speaking):
Currently it only restores - nothing more, see
https://github.com/rear/rear/pull/1091#issuecomment-263819775
where I also describe why I think it could be rather complicated
to get the tree of filesystems mounted at /mnt/local.
Therefore I will not implement a full-featured
restoreonly workflow soon which means I change
this issue milestone back to "Rear future".
gdha commented at 2017-01-17 12:44:¶
@jsmeix was this not implemented already?
jsmeix commented at 2017-01-17 12:56:¶
A "restoreonly" workflow is implemented but
that does not implement what is actually requested here,
see my above comment
https://github.com/rear/rear/issues/987#issuecomment-263856063
To make it more clear what is actually requested here
I change the subject of this issue from
Have "rear restoreonly" as counterpart of "rear mkbackuponly"
to
Implement a backup restore workflow that can work on its own.
[Export of Github issue for rear/rear.]