Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
New kind of "backup" method: BACKUP=ZYPPER #1085
I like to implement a new kind of "backup" method:
It is not an usual file-based backup/restore method
This new kind of "backup" method does not work
During "rear mkbackup" it will basically save
This issue emerged as successor of
In contrast to
Why BACKUP=ZYPPER and not BACKUP=RPM?
Because zypper provides RPM packages repositories
When BACKUP=ZYPPER works o.k. and
The intended use-case why I think ReaR should
As far as I know one reason why users like ReaR so much is
From that I conclude that basically nobody is interested
As far as I know another reason why users like ReaR so much
Why not make them even more happy so that they can
Perhaps you may wonder about why a user should use
As far as I know in big environments (with hundreds
As far as I know in big environments they use the
Therefore the intended use-case for
Use the Linux distribution's installer to set up
Another use-case for ReaR system deployment
And what is the ultimate goal behind all that?
My ultimate goal is to get ReaR out of the "rear seat"
My ultimate goal is to move ReaR forward
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.
This was referenced
Nov 25, 2016
BACKUP=ZYPPER only works on systems
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
Regarding what package repositories will be used
mass-deployment via "rear recover" probably together with "RECOVERY_UPDATE_URL", cf. https://github.com/rear/rear/issues/841
hmm, fully understand you monetary reasons, we all need to eat from time to time ;-).
E.g for Red Hat one would keep it separated via
cf. what we learned about keeping separated backup
With support for multiple backup methods in ReaR
My actual main reason for using 'zypper' is that I know it
I like to get a first usable result soon
If BACKUP=ZYPPER works well, I could perhaps