The gsync configuration information is fund in the file /etc/gandi/gsync.conf.

A complete and detailed description of this file may be found here: Gsync How-to (French)

Here is an example configuration:

## Gandi synchronization example config file

# See http://wiki.gandi.net/fr/hosting/manage-disk/gsync

# This document is written in yaml, for more information see
# http://www.yaml.org/spec/1.2/spec.html 
#
# DO NOT mix spaces and tabs in this document, just use spaces.

# loglevel takes four values:
#  - err   (report errors)
#  - warn  (report warnings and errors)
#  - info
#  - debug

loglevel: info # (err, warn, info, debug)

# webserver setups common parts of the webserver
# if it is used below. 

webserver:
    port: 8843
    # options below are to be implemented
    # maxlen: 
    # secure:
    #    ssl_certificate: 
    #    ssl_private_key: 

# Gsync engine works with repositories. A repository is storage
# location and a set of configuration specifying what files should
# be synchronized, using which plugin, wether to export it to the
# webserver for read/write access, etc.

# Almost each parameter is optionnal, allowing you to build various
# setups. An example below, keep one month worth of /home, with a daily
# backup -- and a few more below:

repositories:
    homes:
        type: versioning
        path: /srv/backup/homes/
        monitor:
            - /home
        filters:
            default: True
            '^/home/jack/': False
            '\.log$': False
            '/\.': False
            '~$': False
        intervals:
            snap:
                count: 30
                delay: 86400

## A "versioning" plugin has a working .snapshot() method that
## hardlinks new copies of the monitored files on a regular basis.
#
# You define a new repository by its name:
#    slash_tmp:
# 
#        type: versioning  ## and specify a type,
#        path: /tmp/kalou  ## and a path
#
## The "monitor" section defines what directories we'll register
## with inotify and the kernel. We'll receive events for subdirectories
## too, thanks to some awful hacks in the middle.
#
#        monitor:
#            - /home/pb/doc/test
# 
## The "filters" help avoiding synchronizing bogus files
## Log files change too often, mysql files would be synchronized
## but corrupted. They're not interesting here
#        filters:
#            default: False
#            '\.log$': False
#            '\.pid$': False
#            '/mysql/': False
#            '^/var/tmp': True
#            '^/home/pb': True
#
## The "intervals" section configure how much versions
## you want to keep depending of the snapshot age.
#
#        intervals:
#            hourly:
#                delay: 3600
#                count: 5
#            daily:
#                delay: 86400
#                count: 7


# "remote" plugin knows how to send files to a remote REST webserver.
# Using this plugin we can synchronize webservers or just remotely
# backup files on a master server.
#
#
#    remote:    
#        type: remote                                  
#        path: 'http://toto:password@1.2.3:8080/local_repo/'
#        monitor:
#            - /home/pb/doc
#            - /var/tmp

# Here is how we could setup the webserver. The "local_files" plugin
# does not exist yet, but could be used for simple file synchronization.
#
# You could use a "versionning" plugin too, for remote backup.
#
#    dumb_webserver:
#        type: local_files
#        path: /srv/data/exported/
#
## The "export" keyword simply connects the repository to the
## webserver. Hence, a "remote" client can use it.
#        export:
#            login: 'test'
#            password: 'nosuchthing'

# Simulator is just used for debugging purposes.
#    simul:
#        type: simulator
#        path: none
#        filters:
#            default: False
#
#        intervals:
#            hourly:
#                delay: 3600
#                count: 5
#            daily:
#                delay: 86400
#                count: 7