Backup methods

[Anatoli]

 > Well, sort of.  It is a method that is actually focused around doing 
backups.  It happens to make use of the replication protocol because 
that is actually the smart way to do it.  I did detail the differences 
in my message.

I suggest you try to use it in your deployments and then share with us 
your real-world experience, like how reliable it is, how well the 
compression works, how easy it is to recover something if both master 
and the backup instances become unaccessible (disk failure in both or 
both servers are stolen (this is a SME office, not a tier 4 datacenter) 
and the backups from an external location should be brought in), what 
data is missing (if at all) after a backup recovery, how incremental 
backups are done, etc. I tried it in a /real deployment/ a year ago when 
it was just released and my conclusion was that it was not well-suited 
for a SME environment (at least at that moment).


 > Honestly I believe that's the wrong way to go about it

What about mysqldump > dump.sql, then mysql < dump.sql? Also a wrong way 
and didn't have to be implemented? I bet this is the most deployed 
method for DB backups in the real SME world (like cron mysqldump 
--routines --all-databases | xz -9 > /bu/`date 
+%y%m%d_%H%M`_full.sql.xz), though there are replication solutions 
available too. The Unix way is about minimalist, modular software.

*From:* Jason L Tibbitts Iii
*Sent:* Thursday, May 10, 2018 16:38
*To:* Anatoli
*Cc:* Info-cyrus
*Subject:* Re: Backup methods

>>>>> "A" == Anatoli  <me at anatoli.ws> writes:

A> What you mention is highly related to the replication backup
A> we were talking about in the previous mails.

Well, sort of.  It is a method that is actually focused around doing
backups.  It happens to make use of the replication protocol because
that is actually the smart way to do it.  I did detail the differences
in my message.

A> In both cases, a copy of the master data is made, which requires
A> twice the space of real usage (Cyrus Backups tries to apply
A> compression on stored data, not sure how well it works).

As I mentioned, the documentation discusses this.

A> What is really needed, IMO, for SME environments is the ability for
A> Cyrus to sync to disk all data, so one can take a hot copy of that
A> data with standard UNIX tools and then handle it accordingly. Once a
A> recovery is needed, one just copies a backup to the Cyrus dir and
A> starts the service.

Honestly I believe that's the wrong way to go about it, but it's
certainly one way to do things if you have no backup solution integrated
into the software.  But hey, it's your data.  I only wanted to mention
that there really is an existing backup solution which wasn't being
discussed.

  - J<



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20180510/0d8824e6/attachment.html>