#1519 Issue closed: Incremental/differential backups on one same day do not work

Labels: support / question, fixed / solved / done

dcz01 opened issue at 2017-09-27 14:15:

Open Bug from #1145

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • rear version (/usr/sbin/rear -V): Relax-and-Recover 2.2 / 2017-07-20
  • OS version (cat /etc/rear/os.conf or lsb_release -a):
  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
BACKUP_PROG_CRYPT_OPTIONS="/usr/bin/openssl aes256 -salt -k"
BACKUP_PROG_DECRYPT_OPTIONS="/usr/bin/openssl aes256 -d -k"
BACKUP_PROG_EXCLUDE=( '/tmp/*' '/dev/shm/*' $VAR_DIR/output/\* '/opt/tivoli/tsm/rear/*' '/mnt/*' '/media/*' '/var/lib/pgsql/*/data/base/*' '/var/lib/pgsql/*/data/global/*' '/var/lib/pgsql/*/data/pg*/*' '/var/lib/pgsql/*/backups/*' )
  • Are you using legacy BIOS or UEFI boot? BIOS.
  • Brief description of the issue: No real incremental backups are made external at USB devices.
  • Work-around, if any: None.

I tested the new implemented feature from ReaR 2.1 to backup the whole server to USB devices.
But always when i started a backup the program does an full backup.
@jsmeix So i think there is an issue open in #1145.

insgesamt 14G
drwxr-x---. 2 root root 4,0K 27. Sep 16:06 .
drwxr-xr-x. 5 root root 4,0K 27. Sep 11:51 ..
-rw-r--r--. 1 root root 1,4G 27. Sep 14:55 2017-09-27-1450-F.tar.gz
-rw-r--r--. 1 root root 1,4G 27. Sep 15:25 2017-09-27-1522-I.tar.gz
-rw-r--r--. 1 root root 1,4G 27. Sep 15:31 2017-09-27-1528-I.tar.gz
-rw-r--r--. 1 root root 1,4G 27. Sep 15:38 2017-09-27-1534-I.tar.gz
-rw-r--r--. 1 root root 1,4G 27. Sep 15:44 2017-09-27-1541-I.tar.gz
-rw-r--r--. 1 root root 1,4G 27. Sep 15:53 2017-09-27-1549-I.tar.gz
-rw-r--r--. 1 root root 1,4G 27. Sep 15:57 2017-09-27-1554-I.tar.gz
-rw-r--r--. 1 root root 1,4G 27. Sep 16:02 2017-09-27-1558-I.tar.gz
-rw-r--r--. 1 root root 1,4G 27. Sep 16:06 2017-09-27-1602-I.tar.gz
-rw-r--r--. 1 root root 6,5M 27. Sep 16:06 backup.log
-rw-r--r--. 1 root root 1,4G 27. Sep 11:54 backup.tar.gz
-rw-r--r--. 1 root root    0 27. Sep 16:06 selinux.autorelabel

jsmeix commented at 2017-09-27 14:37:

Inspect your ReaR log file preferably when you run it as

rear -d -D mkbackup

what goes on on your particular system why ReaR decides in
to do a full backup.

jsmeix commented at 2017-09-27 14:46:

For me your YYYY-MM-DD-HHMM-I.tar.gz files
seem to prove that ReaR does an incremental backup
but for whatever unknown reason your backup program
seems to result that those incremental backups are
always of size 1.4 G.
I.e. inspect what your particular backup program actually does
when it is called in the way how ReaR calls it when it does
an incremental backup.

jsmeix commented at 2017-09-27 14:48:

I should have looked closer:
All your YYYY-MM-DD-HHMM-I.tar.gz files
are on the same day 2017-09-27.
Now things are clear.
Read usr/share/rear/conf/default.conf what there is
documented about "timing granularity for incremental
and differential backup".

dcz01 commented at 2017-09-27 14:50:

Well them are on the same day but that wasn't prior on the normal incremental tar backup an problem.
It worked fine always and on the same day.
Here is my log.

dcz01 commented at 2017-09-28 06:38:

@jsmeix Well i found my own fault...
I restored the whole system to another machine to test the backup and restore to usb for an client and then all files of the system get the change date of the day of restore.
So i tested today and the backup works normal and fine.
Thanks for your fast answers.

jsmeix commented at 2017-09-28 07:40:

thank you very much for your explanation what the
actual root cause of your issue was and even more
thanks for your explicit confirmation that there is
no issue in ReaR.

It helps (at least me) a lot to have an explicit confirmation
when there was no (possibly obscure) issue in ReaR.

I did not change my code that implements
incremental/differential backup so that I assumed
it still works. But I feared a change elsewhere
(e.g. something like https://github.com/rear/rear/pull/1475)
might have caused new issues for incremental/differential
backup in whatever unexpected sublte way.

[Export of Github issue for rear/rear.]