Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
gkanmaz opened this issue Jan 5, 2017 · 5 comments
Assignees
Labels
external tool The issue depends on other software e.g. third-party backup tools. fixed / solved / done not ReaR / invalid The root cause is not in the ReaR code or ReaR is misused. support / question

Comments

@gkanmaz
Copy link

gkanmaz commented Jan 5, 2017

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
@gkanmaz gkanmaz changed the title Version 1.19 doesn't update basebackup.txt and timestamp.txt Version 1.19 doesn't update basebackup.txt and timestamp.txt files Jan 5, 2017
@jsmeix jsmeix self-assigned this Jan 5, 2017
@jsmeix
Copy link
Member

jsmeix commented Jan 5, 2017

@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:
eca18f9

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.
#1073 (comment)

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

@jsmeix jsmeix changed the title Version 1.19 doesn't update basebackup.txt and timestamp.txt files ReaR version 2.0 will no longer use basebackup.txt and timestamp.txt for incremental backup Jan 5, 2017
@gkanmaz
Copy link
Author

gkanmaz commented Jan 5, 2017

@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 jsmeix added external tool The issue depends on other software e.g. third-party backup tools. fixed / solved / done not ReaR / invalid The root cause is not in the ReaR code or ReaR is misused. and removed waiting for info labels Jan 5, 2017
@jsmeix
Copy link
Member

jsmeix commented Jan 5, 2017

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 jsmeix closed this as completed Jan 5, 2017
@jsmeix
Copy link
Member

jsmeix commented Jan 5, 2017

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
Copy link
Member

jsmeix commented Jan 5, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external tool The issue depends on other software e.g. third-party backup tools. fixed / solved / done not ReaR / invalid The root cause is not in the ReaR code or ReaR is misused. support / question
Projects
None yet
Development

No branches or pull requests

2 participants