> On 22. Jan 2018, at 20:47, tech-lists <tech-li...@zyxst.net> wrote:
>> On 22/01/2018 16:38, Paul Vixie wrote:
>> for live sync you'll have to run software inside the guest that knows
>> how to properly freeze state. for example if there's a live database of
>> any kind you'll want it to be in its quiet state before you sync from
>> it. in those situations, i do use rsync.
> Yeah, thought it might be this. Sorry I wasn't more clear initially
> about the use case.
> Basically, the production server is in a datacentre and the reserve
> server is on a very fast vdsl service. The reason for the reserve server
> is, if the production server fails then I swap DNS to point at the
> reserved server and the guests on it without interruption of service.
> All guests are running databases (mysql) though they aren't especially
> busy. So I guess the best bet would be mysql replication for the
> databases and rsync for everything except mysql?
> thanks everyone who took the time to answer
For the database, mysql replication is the way to go (otherwise you would need
to stop/lock the server every time you do a snapshot and you'll get
near-realtime replication which will always be more current than your
snapshots). For the system I'd suggest to create automation for the setup, so
you can apply changes to both systems without a need to sync/clone/copy from
one to the other. For anything else left (data files on disk, non-system,
non-package, non-config) use regular rsync (or zfs send if your setup permits -
I'd stick with rsync).
p.s. Make sure to include monitoring (especially replication latency and data
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to
email@example.com mailing list
To unsubscribe, send any mail to