#1152 Issue closed: ReaR version 2.0 will no longer use basebackup.txt and timestamp.txt for incremental backup

Labels: support / question, fixed / solved / done, external tool, not ReaR / invalid

gkanmaz opened issue at 2017-01-05 06:32:

Hello,

After rear upgrade to version 1.19, I have just noticed that basebackup.txt and timestamp.txt files are not updated.

  • rear version (/usr/sbin/rear -V): Relax-and-Recover 1.19 / Git
  • OS version (cat /etc/rear/os.conf or lsb_release -a): Ubuntu 14.04 LTS
  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
    OUTPUT=ISO
    BACKUP=NETFS
    BACKUP_TYPE=incremental
    BACKUP_PROG=tar
    FULLBACKUPDAY="Mon"
    BACKUP_URL="nfs://10.10.9.251/volume1/NFS/rear/"
    BACKUP_PROG_COMPRESS_OPTIONS="--gzip"
    BACKUP_PROG_COMPRESS_SUFFIX=".gz"
    BACKUP_PROG_EXCLUDE=( '/tmp/' '/dev/shm/' )
    BACKUP_OPTIONS="nfsvers=3,nolock"

Relax-and-Recover (rear) Issue Template

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

  • rear version (/usr/sbin/rear -V):
  • 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):
  • Brief description of the issue
  • Work-around, if any

jsmeix commented at 2017-01-05 09:39:

@gkanmaz
And what exactly goes wrong now for you?

I implemented real incremental plus differential backup
after the ReaR 1.19 release which was on Oct 11 2016.

Since I implemented real incremental plus differential backup
there are no loger the timestamp.txt and basebackup.txt files,
see my commit from Nov. 18 2016:
https://github.com/rear/rear/commit/eca18f9459ea78d440061e005c35713918985ecd

I.e. you do not use the ReaR 1.19 release
but some current ReaR GitHub master code.

All needed information is now calculated from
the backup file names.

All that happens in 070_set_backup_archive.sh see
https://raw.githubusercontent.com/rear/rear/master/usr/share/rear/prep/NETFS/default/070_set_backup_archive.sh

I tried to implement it so that it works in a backward compatible way
as far as possible - except that now BACKUP_TYPE=incremental
is real incremental backup and for the previous behaviour one
needs now BACKUP_TYPE=differential, cf.
https://github.com/rear/rear/issues/1073#issuecomment-264127724

See default.conf how now real incremental or differential backup
works.

gkanmaz commented at 2017-01-05 10:04:

@jsmeix

I have below script runs daily in order to prune incremental and full backup files older than last full backup date. The script uses date value in timestamp.txt file.

Source of the script : https://www.harperink.de/?p=2735

#!/bin/bash
SYNOLOGY_BASE="/volume1/NFS/rear/"
cd $SYNOLOGY_BASE

for dir in ls -1;
do
tar_dosya_sayisi=ls $SYNOLOGY_BASE$dir/*.tar.gz | wc -l
if [[ -f "$SYNOLOGY_BASE$dir/timestamp.txt" && $tar_dosya_sayisi > 1 ]]
then
echo "$dir - $tar_dosya_sayisi"
cd $SYNOLOGY_BASE$dir
find $SYNOLOGY_BASE$dir/*tar.gz -type f ! -newer $SYNOLOGY_BASE$dir/timestamp.txt | xargs rm -f
fi
done

jsmeix commented at 2017-01-05 10:19:

You need to adapt your script so that
all needed information is calculated
from the backup file names.

This is not an issue in ReaR but in that script
(a third-party script - from ReaR's point of view).

jsmeix commented at 2017-01-05 10:25:

FYI:
My personal opinion to prune backups based on whatever information
in whatever additional files is unreliably.
To prune old files I would implement it in a way to query
the files directly - not any indirect other source of information
(cf. RFC 1925 item 6a: "It is always possible to add another
level of indirection").
In case of backups I would even try to inspect the content
of the backup if possible to get the needed information and
use the backup file dates only as fallback.

jsmeix commented at 2017-01-05 10:31:

I added a notification comment to
https://www.harperink.de/?p=2735
as
https://www.harperink.de/?p=2735#comment-28214

[Export of Github issue for rear/rear.]