A two way sync script based that adds script fault tolerance from obackup project.
A two way sync script based that adds script fault tolerance from obackup project along with multiple usefull options.
## About
@ -9,14 +9,15 @@ Having created obackup script in order to make reliable quick backups, i searche
While unison handles these scenarios, it's pretty messy to configure, slow, won't handle ACLs and won't resume if something bad happened.
Then i read about bitpocket, a nice script provided by sickill https://github.com/sickill/bitpocket.git
Then i read about bitpocket, a nice script provided by Marcin Kulik (sickill) at https://github.com/sickill/bitpocket.git
Bitpocked inspired me to write my own implementation of a two way sync script, implementing features i wanted among:
- Fault tolerance with resume scenarios
- Email alerts
- Logging facility
- Soft deletition and multiple backups handling
- Before / after command execution
- Time control
Osync uses a master / slave sync schema. It can sync local or remote directories. By definition, master replica should always be a local directory on the system osync runs on.
Also, osync uses pidlocks to prevent multiple concurrent sync processes on/to the same master / slave replica. Be sure a sync process is finished before launching next one.
@ -33,7 +34,11 @@ First, grab a fresh copy of osync and make it executable:
$ git clone https://github.com/deajan/osync
$ chmod +x ./osync.sh
Then, edit the sync.conf file according to your needs.
There is no need to intialize anything. You can begin sync with two already filled directories.
You only have to copy the sync.conf file to let's say your.conf and then edit it according to your needs.
Osync needs a pair of private / public RSA keys to perform remote SSH connections.
Also, using SUDO_EXEC option requires to configure /etc/sudoers file.
Documentation is being written, meanwhile you can check Obackup documentation at http://netpower.fr/projects/obackup/documentation.html for the two configurations points above.
## Usage
@ -45,13 +50,17 @@ If everything went well, you may run the actual configuration with one of the fo
$ ./osync.sh /path/to/your.conf
$ ./osync.sh /path/to/your.conf --verbose
$ ./osync.sh /path/to/your.conf --no-maxtime
Verbose option will display which files and attrs are actually synchronized.
No-Maxtime option will disable execution time checks, which is usefull for big initial sync tasks that might take long time. Next runs should then only propagate changes and take much less time.
Once you're confident about your fist runs, you may add osync as cron task with:
$ ./osync.sh /path/to/your.conf --silent
You may then find osync output in /var/log/osync-*.log
Also, you may always find detailed rsync command results at /tmp/osync_* if verbose switch wasn't specified.