#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):
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:///tmp/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=usb:///dev/disk/by-label/REAR-000
BACKUP_TYPE=incremental
FULLBACKUPDAY="Sat"
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/*' )
#NETFS_KEEP_OLD_BACKUP_COPY=y
USB_SUFFIX="rear/$HOSTNAME/Backups"
USB_RETAIN_BACKUP_NR=8
SSH_ROOT_PASSWORD='$1$HGjk3XUV$lid3Nd3k01Kht1mpMscLw1'
- 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
usr/share/rear/prep/NETFS/default/070_set_backup_archive.sh
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.
rear-FBD02PSS.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:¶
@dcz01
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.
FYI:
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.]