#1285 Issue closed: ReaR backups too old files for incremental backups¶
Labels: enhancement, documentation, needs sponsorship,
won't fix / can't fix / obsolete
dcz01 opened issue at 2017-04-12 10:17:¶
ReaR backups too much¶
- rear version (/usr/sbin/rear -V): Relax-and-Recover 2.00 / Git
- OS version (cat /etc/rear/os.conf or lsb_release -a): RHEL6
- 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=nfs://
BACKUP_URL=cifs://S0100EDE/BRP-Backup
BACKUP_OPTIONS="cred=/etc/rear/cifs,sec=ntlmsspi"
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*/*' )
SSH_ROOT_PASSWORD='$1$HGjk3XUV$lid3Nd3k01Kht1mpMscLw1'
- Are you using legacy BIOS or UEFI boot? BIOS
- Brief description of the issue: ReaR backup with tar does always an incremental backup six days long with one full backup on saturday. But in the incremental backups are always the database dumps from the same day and the day before. The dump from the day before should not be there or?
- Work-around, if any: None
I did an search over the archive for investigating why the filesize of
the archive is not about 13 or 14 GB where it should be. The real size
now is 26 or 27 GB for one incremental backup.
With the following command i listed the files in the archive:
dd if=/mnt/BRP-Backup/FBD01PSS/2017-04-04-0500-I.tar.gz |
/usr/bin/openssl aes256 -d -k brpbackup123 | tar -tzvf - >>
/tmp/restore3.txt
In the pictures are first the text file of the listing command and then the cron schedules for the backups.
jsmeix commented at 2017-04-12 11:05:¶
The relevant code is in
prep/NETFS/default/070_set_backup_archive.sh
in particular this part (excerpts)
case "$create_backup_type" in
...
(incremental)
...
if test "$latest_incremental_backup" ; then
# A latest incremental backup that is based on the latest full backup is found:
local latest_incremental_backup_file_name=$( basename $latest_incremental_backup )
LogPrint "Latest incremental backup found ($latest_incremental_backup_file_name) that is newer than the latest full backup"
local latest_incremental_backup_date=$( echo $latest_incremental_backup_file_name | grep -o "$date_glob_regex" )
BACKUP_PROG_CREATE_NEWER_OPTIONS="--newer=$latest_incremental_backup_date -V $latest_incremental_backup_file_name"
LogPrint "Performing incremental backup for files newer than $latest_incremental_backup_date using backup archive '$new_incremental_backup_file_name'"
so that when you run "rear mkbackup/mkbackuponly"
in verbose mode (which you don't as far as I see)
you would get a nice info message (LogPrint)
that shows you what date will be used for the
tar ... --newer=DATE
call.
Either the DATE value is somehow wrong determined
in prep/NETFS/default/070_set_backup_archive.sh
then it is an issue in ReaR or the DATE value looks right
but 'tar ... --newer=DATE' seems to backup more files
then it is probably an issue in 'tar'.
To debug issues that are related to ReaR you need to
run /usr/sbin/rear with debugging enabled, i.e.
"rear -d -D mkbackup/mkbackuponly",
cf. "Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
To see the actual 'tar' command that is called by rear
inspect the backup.log file.
jsmeix commented at 2017-04-12 11:14:¶
For documentation how 'tar ... --newer=DATE'
should behave, see
https://www.gnu.org/software/tar/manual/tar.html#SEC117
I.e. run 'stat' on your database dump files and check
if the 'Modify' and 'Change' dates in the 'stat' output
match what 'tar ... --newer=DATE' does in your case.
dcz01 commented at 2017-04-12 12:57:¶
@jsmeix Now i ran "rear -d -D mkbackuponly" with the same result, that
ReaR backs the same file up which the previous archive had.
The full log file is attached.
Here is also the output from the "stat" command:
jsmeix commented at 2017-04-12 13:13:¶
Your rear-FBD01PSS.txt contains
++ BACKUP_PROG_CREATE_NEWER_OPTIONS='--newer=2017-04-12 -V 2017-04-12-0500-I.tar.gz'
which means 'tar' should be called as
tar ... --newer=2017-04-12
which should backup all files where mtime or ctime (or both)
are newer than 2017-04-12.
I assume "newer than 2017-04-12" means all where
mtime or ctime is later than 2017-04-12 at 00:00 time.
You need to verify in your backup.log file
that 'tar' is acually called as
tar ... --newer=2017-04-12
and that there are no warning or error messages from 'tar'
about that date setting.
Your 'stat' shows that both mtime and ctime of your
pg_dump_YYYY-MM-DD files are all older
than 2017-04-12 except pg_dump_2017-04-12
so that - when 'tar' works as documented,
only your pg_dump_2017-04-12 should be in the backup.
From my current point of view
(I assume 'tar' is actually called with '--newer=2017-04-12')
it seems this issue is in 'tar' and not in ReaR.
jsmeix commented at 2017-04-12 13:27:¶
For me 'tar --newer' works well on command line.
Example (in my ReaR GitHub checkout):
# cp usr/share/rear/conf/default.conf usr/share/rear/conf/dummy.conf # stat usr/share/rear/conf/d*.conf | egrep 'File:|Modify:|Change:' File: 'usr/share/rear/conf/default.conf' Modify: 2017-04-11 16:10:38.817390944 +0200 Change: 2017-04-11 16:10:38.817390944 +0200 File: 'usr/share/rear/conf/dummy.conf' Modify: 2017-04-12 15:24:19.310609526 +0200 Change: 2017-04-12 15:24:19.310609526 +0200 # tar --newer=2017-04-11 -cvf /tmp/testy.tar usr/share/rear/conf/d*.conf tar: Option --after-date: Treating date '2017-04-11' as 2017-04-11 00:00:00 usr/share/rear/conf/default.conf usr/share/rear/conf/dummy.conf # tar -tvf /tmp/testy.tar -rw-r--r-- root/root 84587 2017-04-11 16:10 usr/share/rear/conf/default.conf -rw-r--r-- root/root 84587 2017-04-12 15:24 usr/share/rear/conf/dummy.conf # tar --newer=2017-04-12 -cvf /tmp/testy.tar usr/share/rear/conf/d*.conf tar: Option --after-date: Treating date '2017-04-12' as 2017-04-12 00:00:00 tar: usr/share/rear/conf/default.conf: file is unchanged; not dumped usr/share/rear/conf/dummy.conf # tar -tvf /tmp/testy.tar -rw-r--r-- root/root 84587 2017-04-12 15:24 usr/share/rear/conf/dummy.conf
dcz01 commented at 2017-04-12 13:59:¶
Well right now it is working correct and works fine.
But i will wait until tomorrow and see if the backup of tonight at 05:00
(AM) works too.
Then we'll see if the nightly backup holds only one or two copies of and
database dump.
I'll write tomorrow if it worked.
dcz01 commented at 2017-04-13 06:51:¶
@jsmeix The backup tonight has done the same. It backed two versions of
database dumps up.
And in the backup.log is the right parameter for the "tar" command
set:
--newer=2017-04-12 -V 2017-04-12-1353-I.tar.gz
Now i think the problem is an logical one... The database dumps are done
at 03:00 (AM) and ReaR starts at 05:00 (AM), so when the
--newer=2017-04-12 starts deciding the files at 00:00 at 12.04.2017 then
really two dumps are choosen to be backed up.
The two are 12.04.2017 at 03:00 (AM) and 13.04.2017 at 03:00 (AM).
Is there not the opportunity to change ReaR, so that the exactly backs up only the new or changed files from the last incremental backup (maybe timestamp of the archive)?
jsmeix commented at 2017-04-13 06:55:¶
Sleeping over an issue always helps,
I think I know now what happens:
Example:
On 2017-04-11 at 04:00 you do a database dump.
On 2017-04-11 at 05:00 you do a backup.
On 2017-04-12 at 04:00 you do another database dump.
On 2017-04-12 at 05:00 you do another backup.
The second backup is run with 'tar --newer=2017-04-11'
cf.
https://github.com/rear/rear/issues/1285#issuecomment-293571107
but '--newer=2017-04-11' means "newer than 2017-04-11 at 00:00"
cf.
https://github.com/rear/rear/issues/1285#issuecomment-293575309
so that both database dumps are newer than 2017-04-11 at 00:00
and then both database dumps are in the second backup.
dcz01 commented at 2017-04-13 07:22:¶
But should it not be in our example the "tar --newer=2017-04-12" option
in the command?
Then it would be correct or should only the backup window of the
database dump be changed?
jsmeix commented at 2017-04-13 07:45:¶
Ha - @dcz01 you found out the same as me!
We did both comments simultaneously
but you won because your submitted
your comment 5 minutes eariler
while I was still writing my comment.
The DATE in 'tar --newer=DATE' is (and must be)
the DATE when the last backup was made.
Example:
On 2017-04-10 at 04:00 you do a database dump.
On 2017-04-10 at 05:00 you do a backup.
On 2017-04-11 you change the database.
On 2017-04-12 at 04:00 you do another database dump.
On 2017-04-12 at 05:00 you do another backup.
The second backup is run with 'tar --newer=2017-04-10'
to include all since the day when the last backup was made.
The root cause is that the DATE in 'tar --newer=DATE'
is only a day but no time at that day.
Example:
On 2017-04-11 at 01:00 you do a database dump.
On 2017-04-11 you add a 4GiB ISO image file.
On 2017-04-11 at 23:00 you do a backup.
On 2017-04-12 at 01:00 you do another database dump.
On 2017-04-11 you add another 4GiB ISO image file.
On 2017-04-12 at 23:00 you do another backup.
The second backup is run with 'tar --newer=2017-04-11'
so that it includes all since 2017-04-11 00:00
i.e. both database dumps plus both ISO image files.
I think an enhancement is needed to use a more specific
DATE for 'tar --newer=DATE' basically I think
that DATE should be at least DAY plus HOUR
perhaps even DAY plus HOUR plus MINUTE.
The only crucial point is that ReaR must work on the safe side
so that it must never happen that in a sequence of
incremental backups any tiny bit could be missing,
i.e. in a sequence of incremental backups
the backups should overlap a bit to be on the safe side.
jsmeix commented at 2017-04-13 07:51:¶
Regarding
https://github.com/rear/rear/issues/1285#issuecomment-293806225
"exactly backs up only the new or changed files from the last
incremental backup (maybe timestamp of the archive)?"
Careful!
Assume the backup starts on 2017-04-10 at 05:00
and takes two hours to complete i.e. up to 2017-04-10 07:00.
If the backup archive timestamp is 2017-04-10 05:00
things should be o.k but if the backup archive timestamp
is 2017-04-10 07:00 a subsequent incremental backup
that runs with tar --newer='2017-04-10 07:00'
may miss all files that changed between
2017-04-10 05:00 and 2017-04-10 07:00.
jsmeix commented at 2017-04-13 07:55:¶
What should be o.k. is the timestamp
in the backup archive filename because that is created
in prep/NETFS/default/070_set_backup_archive.sh
as described in the explanatory comments therein.
What might badly fail is to use the system modify or change
timestamps (as shown by 'stat') of the backup archive file
(note the difference "filename" above versus "file" here).
gdha commented at 2017-04-13 07:56:¶
@dcz01 @jsmeix Keep in mind that ReaR is not a backup solution, but focuses on DR. Did you try to integrate a (open source) backup solution with ReaR yet? Backup tools are better equipped to deal with such time sensitive backup tasks then ReaR. Just my 2cents...
jsmeix commented at 2017-04-13 08:09:¶
@gdha
I know, I know - and I wished ReaR never got added
that code for advanced backup functionality
(cf. my various other comments regarding all those
issues with incremental/differential backup in ReaR)
but as that code is already there in ReaR
my opinion is that then the code must work
reasonable well.
Cf. the similar issue
https://github.com/rear/rear/issues/1283
where ReaR got code added that actually
does not belong to ReaR's native task.
See also the various issues with BACKUP_URL=usb
that exist only because support for BACKUP_URL=usb
was added as some kind of "ad hoc addon hack"
instead of a properly designed integration in compliance
with the existing ReaR framework.
Frankly:
I do not like to work on that kind of code in ReaR
but I do it to avoid bug reports from SUSE users
who use existing functionality in ReaR and
rightfully expect that existing functionality in ReaR
works reasonably well.
Regarding how to get rid of existing functionality in ReaR
that we actually do no longer want to have in ReaR
because we cannot maintain it with reasonable effort
or because it is "plain wrong" implemented, see
https://github.com/rear/rear/issues/1173
dcz01 commented at 2017-04-13 08:18:¶
@gdha @jsmeix I know that you don't like to support or maintain the code
for "tar" or "rsync" backups with ReaR. I can understand that and i
accept that ReaR is actual an DR solution an no backup program...
But we searched for our clients (banks) a solution to backup their linux
servers from us (RHEL) which didn't need an separate server like TSM
(what many other clients use in combination with ReaR from us).
So ReaR works great since today with the "tar" backups and we like that
functions very much.
jsmeix commented at 2017-04-13 08:27:¶
And the good news for ReaR upstream is:
Because SUSE pays me I can work on such code in ReaR
and make it work reasonably well.
And why can SUSE pay me for that?
Because existing functionality in ReaR works reasonably well
for SUSE customers who use ReaR so that they buy SUSE
products (actually they pay for maintenance and support).
But I would never ever work on such code
on a voluntary base - Ugh!
@dcz01
don't worry, I work on ReaR upstream code
so that even Red Hat users get it ;-)
And why do I pay attention to Red Hat user issues?
Because basically always a Red Hat user issue
is also valid for SUSE users and the more
Red Hat users use current ReaR upstream code
the more issues get known in advance and
the less new issues happen to SUSE users.
In the end everybody wins.
I like free software!
dcz01 commented at 2017-04-13 08:36:¶
@jsmeix Well i must say that we actually don't use the real RHEL... Only
CentOS is our basic system for us and clients. But its excatly the same
so it works well too.
Thats a good thing if you get paid for updates in ReaR :-)
jsmeix commented at 2017-04-13 08:44:¶
@dcz01
only an offanded idea I think (but I did not test it)
a possible workaround with current ReaR code is to
do the database dump on 23:00
and the ReaR backup on 01:00
provided your timing during the night allows this.
Then this should happen:
On 2017-04-10 at 23:00 you do a database dump.
On 2017-04-11 at 01:00 you do a backup.
During 2017-04-11 daytime the database is in use.
On 2017-04-11 at 23:00 you do another database dump.
On 2017-04-12 at 01:00 you do another backup.
The second backup is run with 'tar --newer=2017-04-11'
so that it only includes the second database dump.
jsmeix commented at 2017-04-13 09:50:¶
Only FYI:
The behaviour that the DATE in 'tar --newer=DATE'
is only a DAY without HOUR or MINUTE exists
since the beginning according to
git log -p --follow
usr/share/rear/prep/NETFS/default/070_set_backup_archive.sh
that shows
commit 354486da3191dbfe5c6a4b896e34977be10697d5
...
BACKUP_PROG_X_OPTIONS="$BACKUP_PROG_X_OPTIONS --newer=$(cat ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/timestamp.txt)"
...
date '+%Y-%m-%d' > "${BUILD_DIR}/outputfs/${NETFS_PREFIX}/timestamp.txt"
jsmeix commented at 2017-04-13 12:24:¶
It seems the DATE in 'tar --newer=DATE' is a can of worms,
more specifically time zone setting is a can of worms.
On my SLES11 system
# export LC_ALL=POSIX # export LANG=POSIX # date +%Z CEST # echo Hello >hello # date Thu Apr 13 14:17:35 CEST 2017 # stat hello | egrep 'File:|Modify:|Change:' File: `hello' Modify: 2017-04-13 14:17:33.708371000 +0200 Change: 2017-04-13 14:17:33.708371000 +0200 # tar --newer=2017-04-13T14:16 -cvf /dev/null hello tar: Option --after-date: Treating date `2017-04-13T14:16' as 2017-04-13 09:16:00 hello # tar --newer=2017-04-13T14:18 -cvf /dev/null hello tar: Option --after-date: Treating date `2017-04-13T14:18' as 2017-04-13 09:18:00 hello # tar --newer=2017-04-13T19:16 -cvf /dev/null hello tar: Option --after-date: Treating date `2017-04-13T19:16' as 2017-04-13 14:16:00 hello # tar --newer=2017-04-13T19:18 -cvf /dev/null hello tar: Option --after-date: Treating date `2017-04-13T19:18' as 2017-04-13 14:18:00 tar: hello: file is unchanged; not dumped
note how 'tar' in SLES11 somehow misinterprets the specified
date as another (wrong) date (an offset of -5 hours) that
does not match the date that is shown by 'date' and 'stat'
so that it seems 'tar' in SLES11 has a bug.
In particular it seems 'tar' in SLES11 has a bug
because on SLES12 it works - i.e. the date in 'tar'
matches the date that is shown by 'date' and 'stat':
# export LC_ALL=POSIX # export LANG=POSIX # date +%Z CEST # echo Hello >hello # date Thu Apr 13 14:22:33 CEST 2017 # stat hello | egrep 'File:|Modify:|Change:' File: 'hello' Modify: 2017-04-13 14:22:27.955299761 +0200 Change: 2017-04-13 14:22:27.955299761 +0200 # tar --newer=2017-04-13T14:21 -cvf /dev/null hello tar: Option --after-date: Treating date '2017-04-13T14:21' as 2017-04-13 14:21:00 hello # tar --newer=2017-04-13T14:23 -cvf /dev/null hello tar: Option --after-date: Treating date '2017-04-13T14:23' as 2017-04-13 14:23:00 tar: hello: file is unchanged; not dumped
jsmeix commented at 2017-04-13 13:29:¶
The GNU tar documentation doesn't look promising
https://www.gnu.org/software/tar/manual/tar.html#SEC117
reads (excerpts)
to specify a particular date against which tar can compare when deciding whether or not to archive the files. `--after-date=date' `--newer=date' `-N date' Only store files newer than date. ... `--newer-mtime=date' Acts like `--after-date', but only looks at data modification times. [...] Please Note: `--after-date' and `--newer-mtime' should not be used for incremental backups. See section https://www.gnu.org/software/tar/manual/tar.html#SEC97 for proper way of creating incremental backups.
But as far as I understand
https://www.gnu.org/software/tar/manual/tar.html#SEC97
this conflicts with how a 'tar' backup is done in ReaR.
Their "proper way of creating incremental backups" with 'tar'
would result and need an additional metadata file
which would even more complicate the incremental
backup implementation in ReaR which I will not do.
The current incremental backup implementation
is already way beyond ReaR's native task, cf. my
https://github.com/rear/rear/issues/1285#issuecomment-293822278
dcz01 commented at 2017-04-13 13:49:¶
@jsmeix Yes, that implementation with the extra file for tracking the
changes and newer files between the old archive is complex.
But i found something in the 1.23 manual of tar:
-N, --newer=DATE-OR-FILE, --after-date=DATE-OR-FILE
only store files newer than DATE-OR-FILE
So you can give the --newer parameter an date or file to choose from for
the changes.
We would need the file then or?
jsmeix commented at 2017-04-13 13:51:¶
First and foremost:
There is no bug in ReaR.
The current 'tar --newer=yyyy-mm-dd' implementation works
correctly as implemented and as documented in 'tar'.
The current 'tar --newer=yyyy-mm-dd' form even works
with 'tar' in SLES11 that has a bug with the more
sophisticated 'tar --newer=yyyy-mm-ddThh:mm' form, cf.
https://github.com/rear/rear/issues/1285#issuecomment-293880670
while in contrast 'tar --newer=yyyy-mm-dd' works in SLE11:
# stat hello | egrep 'File:|Modify:|Change:' File: `hello' Modify: 2017-04-13 14:17:33.708371000 +0200 Change: 2017-04-13 14:17:33.708371000 +0200 # tar --newer=2017-04-13 -cvf /dev/null hello tar: Option --after-date: Treating date `2017-04-13' as 2017-04-13 00:00:00 hello # tar --newer=2017-04-14 -cvf /dev/null hello tar: Option --after-date: Treating date `2017-04-14' as 2017-04-14 00:00:00 tar: hello: file is unchanged; not dumped
Enhancing prep/NETFS/default/070_set_backup_archive.sh
to support 'tar --newer=yyyy-mm-ddThh:mm' results
regressions in SLES11 and it requires major adaptions
and rework and will only be done as time permits
for an unspecified future ReaR version when ReaR
does no longer support SLES11.
Preferably a contributor to ReaR may provide
a GitHub pull request that implements
'tar --newer=yyyy-mm-ddThh:mm' support properly
(perhaps even with a workaround for buggy tar versions)?
jsmeix commented at 2017-04-13 13:53:¶
@dcz01
bad luck for you because I will not implement changes
that cause regressions for SLES11 :-(
dcz01 commented at 2017-04-13 13:58:¶
@jsmeix Now i found a perfect solution for you:
http://www.linuxquestions.org/questions/linux-general-1/tar-newer-files-since-date-and-time-447002/
http://extreme.pcgameshardware.de/linux-und-sonstige-betriebssysteme/146687-problem-mit-tar-und-der-option-newer-date.html
You can give tar not only the date... In an string you can give it the date and time.
jsmeix commented at 2017-04-13 14:10:¶
@dcz01
I know how to provide date and time
as 'tar --newer=yyyy-mm-ddThh:mm'
but that does not work for me on SLES11.
Regarding your
https://github.com/rear/rear/issues/1285#issuecomment-293900724
to use a file instead of a specific date and time, see
https://github.com/rear/rear/issues/1285#issuecomment-293819555
I would appreciate it of you play around with it on your systems
and provide feedback here what fails and what works for you
in your particular case.
Perhaps you find a sufficiently simple and fail-safe method.
That I gave up here (at least for now) does not at all mean
I will not have a look when there is interesting new information.
It only means that from my current point of view I don't see
how I could implemement it in a sufficiently simple
and fail-safe way.
jsmeix commented at 2017-05-04 10:53:¶
Because of the bad experience with
'tar --newer=yyyy-mm-ddThh:mm'
on my SLES11 system in my above
https://github.com/rear/rear/issues/1285#issuecomment-293880670
I had the idea if it works when I also specify the seconds as in
'tar --newer=yyyy-mm-ddThh:mm:ss'
to avoid that 'tar' does no longer do its broken re-calculation
of the specified date/time value when it gets a precisely
specified date/time value.
But that also does not work:
# export LC_ALL=POSIX # export LANG=POSIX # date +%Z CEST # echo Hello >hello # date Thu May 4 12:42:36 CEST 2017 # stat hello | egrep 'File:|Modify:|Change:' File: `hello' Modify: 2017-05-04 12:42:32.000000000 +0200 Change: 2017-05-04 12:42:32.000000000 +0200 # tar --newer=2017-05-04T12:42:32 -cvf /dev/null hello tar: Option --after-date: Treating date `2017-05-04T12:42:32' as 2017-05-04 07:42:32 hello # tar --newer=2017-05-04T17:42:32 -cvf /dev/null hello tar: Option --after-date: Treating date `2017-05-04T17:42:32' as 2017-05-04 12:42:32 hello # tar --newer=2017-05-04T17:42:33 -cvf /dev/null hello tar: Option --after-date: Treating date `2017-05-04T17:42:33' as 2017-05-04 12:42:33 tar: hello: file is unchanged; not dumped
There is still the 5 hours offset when tar is "Treating date".
jsmeix commented at 2017-05-08 12:43:¶
With
https://github.com/rear/rear/pull/1350
merged
the incremental/differential backup timing granularity
(one day and the differentiating time is at 00:00)
plus its consequence is now at least documented
in default.conf.
I also documented in default.conf another shortcoming of
BACKUP_TYPE=incremental or BACKUP_TYPE=differential:
Because of '--newer=YYYY-MM-DD' files that have been deleted since the last backup are not recognized this way so that such files will get falsely restored during "rear recover".
Finally I added in default.conf some general info
about ReaR's internal backup methods:
In general regarding advanced backup functionality (like incremental and differential backup): ReaR is primarily a disaster recovery tool to recreate the basic system after a disaster happened. ReaR is is neither a backup software nor a backup management software and it is not meant to be one (cf. "Relax-and-Recover versus backup and restore" in https://en.opensuse.org/SDB:Disaster_Recovery). In particular do not expect too much from ReaR's internal backup methods like 'tar'. For simple tasks ReaR's internal backup methods should be o.k. but ReaR's internal backup methods are not meant as professional backup solutions. In general the backup and restore of the files is "external functionality" for ReaR. ReaR only calls an external tool and that tool does the backup and restore of the files. Use a professional backup solution in particular when you need advanced backup functionality.
[Export of Github issue for rear/rear.]