• rear version (/usr/sbin/rear -V): 1.18 / Git
• OS version (cat /etc/rear/os.conf or lsb_release -a):

OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=6

• rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

OUTPUT=ISO
OUTPUT_URL=file:///opt/brp/rear
BACKUP=NETFS
BACKUP_PROG=tar
#BACKUP_PROG_CRYPT_ENABLED=1
#BACKUP_PROG_CRYPT_KEY=brpbackup123
#BACKUP_PROG_CRYPT_OPTIONS="/usr/bin/openssl aes256 -salt -k"
#BACKUP_PROG_DECRYPT_OPTIONS="/usr/bin/openssl aes256 -d -k"
#BACKUP_URL=nfs://
BACKUP_URL=cifs://notesrechte/BRP-Backup
BACKUP_OPTIONS="cred=/etc/rear/cifs"
BACKUP_TYPE=incremental
FULLBACKUPDAY="Sat"
BACKUP_PROG_EXCLUDE=( '/tmp/*' '/dev/shm/*' $VAR_DIR/output/\* '/mnt/*' '/media/*' '/var/lib/pgsql/9.3/data/base/*' '/var/lib/pgsql/9.3/data/global/*' '/var/lib/pgsql/9.3/data/pg*/*' )

I found a little bug in the incremental solution of rear.
rear is actual working with differential backups based on the last full backup. so it needs only to restore the last full and the newest differential.
this is not the right incremental backup and restore because rear is so backing up every day a lot more than needed.
is this so intended?

because we are backing up every day an postgres database (which does an self full backup every day) so that the backup every day gets to large to transmit it from the client to the data center.

here i found some info about that if needed:
http://typesofbackup.com/incremental-vs-differential-vs-full-backup/
http://paulwhippconsulting.com/blog/using-tar-for-full-and-incremental-backups/