|
> 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@xxxxxxxxxx> 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< |
---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
