Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG  Not logged in ELOG logo
icon5.gif   Real-time mirroring?, posted by Frank Baptista on Mon Apr 26 15:40:36 2021 
    icon2.gif   Re: Real-time mirroring?, posted by Sebastian Schenk on Mon Apr 26 16:41:50 2021 
       icon2.gif   Re: Real-time mirroring?, posted by Frank Baptista on Fri Apr 30 20:29:45 2021 
          icon2.gif   Re: Real-time mirroring?, posted by Sebastian Schenk on Fri Apr 30 21:13:39 2021 
             icon2.gif   Re: Real-time mirroring?, posted by Frank Baptista on Fri Apr 30 21:55:23 2021 
Message ID: 69360     Entry time: Fri Apr 30 20:29:45 2021     In reply to: 69357     Reply to this: 69361
Icon: Reply  Author: Frank Baptista  Author Email: 
Category: Question  OS: Windows  ELOG Version: V3.1.3-fd7f1e2 
Subject: Re: Real-time mirroring? 

Hi Sebatian,

Thank you for taking the time to answer...very much appreciated!

Although I'm running Windows OS, I do understand your approach, and will work on an analogous solution.

Our setup is interesting -- we're running many temperature chambers, each one having a dedicated computer running a unique instance of ELOG, each of which is regularly updated to let users know what the progress is for the lengthy temperature testing.  All of these individual logbooks regularly synchronize to a common 'mirror' ELOG server, which shows all the logbooks in one location.  Users can view all the logbooks on one screen, by connecting to the mirror server.  Since this can be done remotely, it also makes it convenient to add "updates" remotely to the mirror server, which eventually synchronizes with each individual computer at the temperature chambers.  As you might imagine, if there is a user doing an update at the temperature chamber computer while another user enters an update remotely to the mirror server, there is a chance of having a record conflict.

I was trying to avoid conflicts by having real-time mirroring, where a change on either end is detected and immediately "synchronized", thereby reducing or eliminating conflicts.

In any case, if I do come up with a good solution for Windows, I'll be sure to share what I did.


Sebastian Schenk wrote:

Hello Frank,

It seems, you are using the mirror function of elog. It should resolve conflicts by itself acording to the documented rules. (
As I don't use this function, I can't say how good it works.

If you don't want to use this function, I would suggest using the "Execute new | edit | delete" feature to trigger a script after each change of elog entries.
This script could itself run "rsync" or your sync solution to make the sync and
should afterwards call "killall -HUP elogd" on the remote to let elog re-read the config (and this sould also update the indices)
(see Server Configuration

If you have a sync-solution, which itself permanently observes folders for changes and syncs it by itself,
It should have the option to run a command after sucessful sync or you need an other method to call "killall -HUP elogd" after sync.

Personally I would recommend the mirror function as it has a internal conflict resolution.
I hope this helps.

Best wishes,

PS: I don't know anything about your setup, but maybe there is a solution, where you don't need the local servers.
As I think, the mirror function is mainly for backup reasons of a main server to a secondary one or similar.

Frank Baptista wrote:


We have a number of local ELOG servers, all mirrored to a single "remote" ELOG server.  We have users that create updates at the local server, and some at the remote server, which can run the risk of record conflicts.  Right now, the local servers perform a "Mirror cron" every 5 minutes, but even that leaves the door open to potential conflicts.

I found an open-source JAVA-based app called DirSync Pro ( which is capable of performing real-time mirroring, and has conflict handling.  I "took it for a spin", and it does do what it claims.  However, because each ELOG server performs record "indexing", it doesn't recognize records that aren't part of the current list of records. Restarting the ELOG server obviously corrects that, but I was wondering if there is another way to get the server to recognize newer "remotely-generated" records without restarting the server.

As always, I'm appreciative for the outstanding working that has been done to make ELOG the great application that it is!





ELOG V3.1.4-80633ba