#1085 Issue closed: New kind of "backup" method: BACKUP=ZYPPER¶
Labels: enhancement, fixed / solved / done
jsmeix opened issue at 2016-11-25 09:44:¶
I like to implement a new kind of "backup" method:
BACKUP=ZYPPER
It is not an usual file-based backup/restore method
where one can get the files of an old system
back as they had been before.
This new kind of "backup" method does not work
on files but on RPM packages.
During "rear mkbackup" it will basically save
only the list of installed RPM packages and
during "rear recover" it will basically
only install those RPM packages.
This issue emerged as successor of
https://github.com/rear/rear/issues/732
and is intended to replace it.
In contrast to
https://github.com/rear/rear/issues/732
where a whole new workflow was intended to be implemented
the new BACKUP=ZYPPER method is intended to provide the
same functionality i.e. "install a system from scratch" but
BACKUP=ZYPPER integrates much nicer into the
existing ReaR framework.
Why BACKUP=ZYPPER and not BACKUP=RPM?
Because zypper provides RPM packages repositories
management, i.e. using the higher level 'zypper' instead
of the low-level 'rpm' saves me much implementation work
because I do not have to implement RPM repositories
management in ReaR but can just let zypper do that, cf.
https://en.opensuse.org/SDB:Disaster_Recovery
"Generic system installation with the plain SUSE installation system"
where I also used 'zypper' in my installation script
(a few 'zypper' commands did all the stuff).
When BACKUP=ZYPPER works o.k. and
when users are interested in using ReaR also
for system deployment, it should be (relatively) easy
to add more such kind of "backup" methods to also
support other software package installers in ReaR.
The intended use-case why I think ReaR should
support system deployment:
As far as I know one reason why users like ReaR so much is
that ReaR is one same disaster recovery tool that they can
use on all their various different kind of Linux systems
(e.g. Debian, Red Hat, SUSE, Ubuntu, ...), cf.
"Native disaster recovery with AutoYaST is deprecated"
in
https://en.opensuse.org/SDB:Disaster_Recovery
From that I conclude that basically nobody is interested
in a Linux distributior specific disaster recovery tool.
As far as I know another reason why users like ReaR so much
is that ReaR is pure bash (the native system administration
language) which means they can (relatively) easily adapt it
as they need it for their various kind of Linux systems.
Why not make them even more happy so that they can
also use ReaR generically for all kind of installations
on all kind of their Linux systems?
Perhaps you may wonder about why a user should use
ReaR for system installation when each Linux distribution
already comes with its own specific installer?
As far as I know in big environments (with hundreds
or even thousands of systems) nobody uses the
Linux distribution's installers to manually install
each particular system.
In big environments they use whatever deployment tool
for mass-installations (e.g. AutoYaST for SUSE).
As far as I know in big environments they use the
Linux distribution's installers basically only during
their initial evaluation and testing phase until they
know what they want to get.
Then they set up their deployment tool and let it do
the actual productive mass-deployments.
Therefore the intended use-case for
ReaR system deployment is:
Use the Linux distribution's installer to set up
one or several "template systems".
On each of those "template systems"
run "rear mkbackup" and do the actual productive
mass-deployment via "rear recover" probably
together with "RECOVERY_UPDATE_URL", cf.
https://github.com/rear/rear/issues/841
Another use-case for ReaR system deployment
could be when systems get re-installed regularly
to maintain 100% clean and 100% updated systems
like thin clients or any other systems without local data
storage where only the plain operating system and
application binaries are stored on local disk, nowadays
also servers with data storage via SAN.
And what is the ultimate goal behind all that?
My ultimate goal is to get ReaR out of the "rear seat"
and put it on a "front seat" - even more:
I would like to get ReaR on the "driver's seat".
My ultimate goal is to move ReaR forward
from something where its users basically say
ReaR is nice tool that we have to be better prepared in case a disaster happens but that we hopefully never have to actually use.
to something where its users could say
ReaR is an essential part of our system administration. ReaR is THE deployment tool and at the same time ReaR is THE backup and recovery tool for all our various different kind of Linux systems.
Cf.
"Let's face it: Deployment via the recovery installer is a must" at
https://en.opensuse.org/SDB:Disaster_Recovery
gozora commented at 2016-11-25 11:31:¶
Hello @jsmeix,
Looks like SuSE only feature, or am I wrong?
Once package list to install list is saved, from which source will they
be installed during deployment? (DVD, official repos, local repos ...)?
V.
jsmeix commented at 2016-11-25 13:29:¶
BACKUP=ZYPPER only works on systems
where 'zypper' is there, cf. above:
When BACKUP=ZYPPER works o.k. and when users are interested in using ReaR also for system deployment, it should be (relatively) easiy to add more such kind of "backup" methods to also support other software package installers in ReaR.
Of course I will first implement something for
the systems of the company that pays my salary ;-)
Then people from Red Hat, Debian, Ubuntu,...
could implement same functionality for their
software package installers (based on my work).
Regarding what package repositories will be used
during "rear recover":
By default the ones that are active on the original system
(i.e. basically what 'zypper lr -u' shows), but anything
else will also be possible, cf. above
mass-deployment via "rear recover" probably together with "RECOVERY_UPDATE_URL", cf. https://github.com/rear/rear/issues/841
gozora commented at 2016-11-25 15:01:¶
hmm, fully understand you monetary reasons, we all need to eat from time
to time ;-).
Anyhow didn't you thought about something more generic (then ZYPPER)?
Because if e.g. RH guys add their code (e.g. for Yum) naming could
become confusing over time ... (just an idea, in general I don't have
anything against zypper ;-)).
jsmeix commented at 2016-11-25 15:17:¶
E.g for Red Hat one would keep it separated via
BACKUP=YUM
cf. what we learned about keeping separated backup
methods separated in
https://github.com/rear/rear/pull/1048
With support for multiple backup methods in ReaR
it does no longer matter on what particular backup method
the user must decide - he can freely combine what he likes.
My actual main reason for using 'zypper' is that I know it
and that I already have some experience how to use it
on plain command line for installation from scatch, cf.
"Generic system installation with the plain SUSE installation system"
in
https://en.opensuse.org/SDB:Disaster_Recovery
I like to get a first usable result soon
so that I and others can play around with it to see
how all that actually works (or fails) in practice.
Therefore I like to avoid unexpected troubles
with low-level implementation details.
If BACKUP=ZYPPER works well, I could perhaps
implement a generic BACKUP=RPM later if needed, cf.
"Why BACKUP=ZYPPER and not BACKUP=RPM?" in
https://github.com/rear/rear/issues/1085#issue-191661559
jsmeix commented at 2017-02-20 10:17:¶
This is the matching openSUSE Hack Week project:
https://hackweek.suse.com/15/projects/2242
Relax-and-Recover: New kind of "backup" method: BACKUP=ZYPPER
gdha commented at 2017-02-20 12:13:¶
@jsmeix Have a nice opensuse hack week ;-)
jsmeix commented at 2017-02-27 15:49:¶
With
https://github.com/rear/rear/pull/1209
merged BACKUP=ZYPPER works now in a basic way
at least on SLES12, cf.
https://github.com/rear/rear/pull/1209#issuecomment-282757853
jsmeix commented at 2020-03-06 13:46:¶
Because there is zero user response for BACKUP=ZYPPER
(in particular zero SUSE user response) I leave it as is.
[Export of Github issue for rear/rear.]