New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New kind of "backup" method: BACKUP=ZYPPER #1085

Open
jsmeix opened this Issue Nov 25, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@jsmeix
Contributor

jsmeix commented Nov 25, 2016

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
#732
and is intended to replace it.

In contrast to
#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.
#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

This comment has been minimized.

Show comment
Hide comment
@gozora

gozora Nov 25, 2016

Member

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.

Member

gozora commented Nov 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jsmeix

jsmeix Nov 25, 2016

Contributor

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
Contributor

jsmeix commented Nov 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gozora

gozora Nov 25, 2016

Member

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 ;-)).

Member

gozora commented Nov 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jsmeix

jsmeix Nov 25, 2016

Contributor

E.g for Red Hat one would keep it separated via

BACKUP=YUM

cf. what we learned about keeping separated backup
methods separated in
#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
#1085 (comment)

Contributor

jsmeix commented Nov 25, 2016

E.g for Red Hat one would keep it separated via

BACKUP=YUM

cf. what we learned about keeping separated backup
methods separated in
#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
#1085 (comment)

@jsmeix

This comment has been minimized.

Show comment
Hide comment
@jsmeix

jsmeix Feb 20, 2017

Contributor

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
Contributor

jsmeix commented Feb 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gdha

gdha Feb 20, 2017

Member

@jsmeix Have a nice opensuse hack week ;-)

Member

gdha commented Feb 20, 2017

@jsmeix Have a nice opensuse hack week ;-)

jsmeix added a commit that referenced this issue Feb 27, 2017

Merge pull request #1209 from jsmeix/ZYPPER_backup_method_issue1085
First partially working implementation of the
new ZYPPER backup method, see
#1085
@jsmeix

This comment has been minimized.

Show comment
Hide comment
@jsmeix

jsmeix Feb 27, 2017

Contributor

With
#1209
merged BACKUP=ZYPPER works now in a basic way
at least on SLES12, cf.
#1209 (comment)

Contributor

jsmeix commented Feb 27, 2017

With
#1209
merged BACKUP=ZYPPER works now in a basic way
at least on SLES12, cf.
#1209 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment