#1062 Issue closed: Incremental Backup does not work¶
Labels: bug, cleanup, waiting for info,
fixed / solved / done
jottschi opened issue at 2016-11-08 22:17:¶
rear Version 1.18 and 1.19
OS: Univention Corporate Server UCS 4.1 (a Debian deriviate)
config like this:
https://www.harperink.de/?p=2735
BACKUP=NETFS
OUTPUT=ISO
CDROM_SIZE=20
BACKUP_URL=nfs://xxx.xxx.xxx.xxx/volume2/LinuxDR/rear
ISO_DIR=/mnt/ISO
ISO_PREFIX=”rear-$HOSTNAME”
BACKUP_PROG_EXCLUDE=( ‘/tmp/’ ‘/dev/shm/’ ‘/mnt/’ ‘/media/’
$VAR_DIR/output/* )
BACKUP_SELINUX_DISABLE=1
BACKUP_TYPE=incremental
FULLBACKUPDAY=Fri
ReaR make ONE Friday Full, the Incrementals are emtpy:
backup.log¶
2016-11-08 23:04:37 tar --warning=no-xdev --sparse --block-number --totals --verbose --no-wildcards-match-slash --one-f ile-system --ignore-failed-read --anchored --newer=2016-11-06 -V 2016-11-06-0015-F.tar.gz --newer=2016-11-06 -V 2016-11 -06-0015-F.tar.gz --gzip -X /tmp/rear.cOzXajRKBps57OC/tmp/backup-exclude.txt -C / -c -f - / /home /home/groups/REPAIR / var/log/rear/rear-ucs.log | cat BACKUP_PROG_CRYPT_KEY | dd of=/tmp/rear.cOzXajRKBps57OC/outputfs/ucs/2016-11-08-2303-I.tar.gz tar: More than one threshold date Try `tar --help' or `tar --usage' for more information. 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.000221423 s, 0.0 kB/s
There is a hickup in the tar command :-(
Ralph
jsmeix commented at 2016-11-09 08:48:¶
It seems that "BACKUP_TYPE=incremental" stuff
causes more and more issues.
This is perhaps a good example why we should try
to avoid to add more and more backup-related
features into ReaR, cf.
https://github.com/rear/rear/issues/1059#issuecomment-259078847
I will have a look what goes on here.
But don't expect too much from me right now.
I never used "BACKUP_TYPE=incremental".
@gdha
I also added you as assignee because you did some
fixes regarding "BACKUP_TYPE=incremental".
Could you also have a look what goes on here?
Perhaps for you the issue is more obvious?
jsmeix commented at 2016-11-09 08:52:¶
@jottschi
you wrote
"Incremental Backup over netfs does not work"
which seems to indicate that it does work for you
with a non-NETFS backup method.
Is this ture and if yes with what non-NETFS backup method
does BACKUP_TYPE=incremental work for you?
FYI:
According to
https://github.com/rear/rear/issues/974
it seems in general BACKUP=NETFS
plus BACKUP_TYPE=incremental
should work.
jsmeix commented at 2016-11-09 11:21:¶
Regarding
BACKUP_TYPE=incremental and non-NETFS backup method:
usr/share/rear/conf/default.conf reads (excerpt):
# Define BACKUP_TYPE (default empty means full backup) or # incremental (only with BACKUP=NETFS and BACKUP_PROG=tar).
I.e. BACKUP_TYPE=incremental is only implemented
for the NETFS backup method.
jsmeix commented at 2016-11-09 11:36:¶
I can confirm that BACKUP_TYPE=incremental does not work,
at least it does not work sufficiently well out of the box.
On my SLES12-SP2 system with current rear master code:
# grep -v ^# etc/rear/local.conf
OUTPUT=ISO
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://10.160.4.244/nfs
REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" snapper chattr lsattr )
COPY_AS_IS=( "${COPY_AS_IS[@]}" /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default )
BACKUP_PROG_INCLUDE=( '/var/cache/*' '/var/lib/mailman/*' '/var/tmp/*' '/var/lib/pgsql/*' '/usr/local/*' '/opt/*' '/var/lib/libvirt/images/*' '/boot/grub2/i386/*' '/var/opt/*' '/srv/*' '/boot/grub2/x86_64/*' '/var/lib/mariadb/*' '/var/spool/*' '/var/lib/mysql/*' '/tmp/*' '/home/*' '/var/log/*' '/var/lib/named/*' '/var/lib/machines/*' )
POST_RECOVERY_SCRIPT=( 'if snapper --no-dbus -r $TARGET_FS_ROOT get-config | grep -q "^QGROUP.*[0-9]/[0-9]" ; then snapper --no-dbus -r $TARGET_FS_ROOT set-config QGROUP= ; snapper --no-dbus -r $TARGET_FS_ROOT setup-quota && echo snapper setup-quota done || echo snapper setup-quota failed ; else echo snapper setup-quota not used ; fi' )
SSH_ROOT_PASSWORD="rear"
USE_DHCLIENT="yes"
KEEP_BUILD_DIR=""
BACKUP_TYPE="incremental"
FULLBACKUPDAY="Wed"
First run of "rear mkbackup" results on the NFS server
/nfs # ls -lh d108 total 993M -rw------- 1 nobody nogroup 825M Nov 9 11:59 2016-11-09-1157-F.tar.gz -rw------- 1 nobody nogroup 202 Nov 9 11:57 README -rw------- 1 nobody nogroup 262 Nov 9 11:57 VERSION -rw------- 1 nobody nogroup 9.6M Nov 9 11:59 backup.log -rw------- 1 nobody nogroup 150M Nov 9 11:57 rear-d108.iso -rw------- 1 nobody nogroup 8.5M Nov 9 11:57 rear.log
and in rear-d108.log (excerpt)
+ source /root/rear/usr/share/rear/prep/NETFS/default/070_set_backup_archive.sh
+++ url_scheme nfs://10.160.4.244/nfs
+++ local url=nfs://10.160.4.244/nfs
+++ local scheme=nfs
+++ grep -q :
+++ echo nfs
+++ echo nfs
++ local scheme=nfs
++ case "$TAPE_DEVICE:$scheme" in
++ '[' incremental == incremental ']'
+++ ls
++ for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
++ restorearchive=AUTHORS
++ for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
++ restorearchive=COPYING
++ for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
++ restorearchive=Makefile
++ for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
++ restorearchive=README.adoc
++ for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
++ restorearchive=doc
++ for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
++ restorearchive=etc
++ for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
++ restorearchive=packaging
++ for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
++ restorearchive=usr
++ for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
++ restorearchive=var
+++ date +%a
++ '[' Wed = Wed ']'
++ Log 'It is Full-Backup-Day'
++ test 1 -gt 0
+++ Stamp
+++ date '+%Y-%m-%d %H:%M:%S.%N '
++ echo '2016-11-09 11:57:07.965978168 It is Full-Backup-Day'
2016-11-09 11:57:07.965978168 It is Full-Backup-Day
++ rm -f /tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/timestamp.txt
++ '[' -f /tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/timestamp.txt ']'
++ '[' '!' -f /tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/basebackup.txt ']'
++ rm -f /tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/timestamp.txt
++ Log 'Timestamp-Files screwd - Performing Full-Backup'
++ test 1 -gt 0
+++ Stamp
+++ date '+%Y-%m-%d %H:%M:%S.%N '
++ echo '2016-11-09 11:57:07.968021464 Timestamp-Files screwd - Performing Full-Backup'
2016-11-09 11:57:07.968021464 Timestamp-Files screwd - Performing Full-Backup
++ '[' -f /tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/timestamp.txt ']'
+++ date +%Y-%m-%d-%H%M
++ backuparchive=/tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/2016-11-09-1157-F.tar.gz
++ date +%Y-%m-%d
/root/rear/usr/share/rear/prep/NETFS/default/070_set_backup_archive.sh: line 46: /tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/timestamp.txt: No such file or directory
+++ date +%Y-%m-%d-%H%M
++ echo 2016-11-09-1157-F.tar.gz
/root/rear/usr/share/rear/prep/NETFS/default/070_set_backup_archive.sh: line 47: /tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/basebackup.txt: No such file or directory
+++ date +%Y-%m-%d-%H%M
++ BACKUP_PROG_X_OPTIONS=' -V 2016-11-09-1157-F.tar.gz'
++ Log 'Performing Full-Backup /tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/2016-11-09-1157-F.tar.gz'
++ test 1 -gt 0
+++ Stamp
+++ date '+%Y-%m-%d %H:%M:%S.%N '
++ echo '2016-11-09 11:57:07.972137674 Performing Full-Backup /tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/2016-11-09-1157-F.tar.gz'
2016-11-09 11:57:07.972137674 Performing Full-Backup /tmp/rear.nIfGXfAbJDj05Rh/outputfs/d108/2016-11-09-1157-F.tar.gz
++ NETFS_KEEP_OLD_BACKUP_COPY=
+ test 1
+ Debug 'Leaving debugscripts mode (back to previous bash flags and options settings).'
Some minutes later (on the same day)
a second run of "rear mkbackup" results on the NFS server
nfs # ls -lh d108 total 1.8G -rw------- 1 nobody nogroup 825M Nov 9 11:59 2016-11-09-1157-F.tar.gz -rw------- 1 nobody nogroup 825M Nov 9 12:12 2016-11-09-1209-F.tar.gz -rw------- 1 nobody nogroup 202 Nov 9 12:10 README -rw------- 1 nobody nogroup 262 Nov 9 12:10 VERSION -rw------- 1 nobody nogroup 9.6M Nov 9 12:12 backup.log -rw-r--r-- 1 nobody nogroup 25 Nov 9 12:09 basebackup.txt -rw------- 1 nobody nogroup 150M Nov 9 12:10 rear-d108.iso -rw------- 1 nobody nogroup 8.5M Nov 9 12:10 rear.log -rw-r--r-- 1 nobody nogroup 11 Nov 9 12:09 timestamp.txt
Now the missing files basebackup.txt and timestamp.txt are there.
Therefore the first bug seems to be that those files are
not created when the initial full backup id done.
But rear-d108.log shows why I got a second full backup
for my second "rear mkbackup" run instead of an differential backup:
+ source /root/rear/usr/share/rear/prep/NETFS/default/070_set_backup_archive.sh
+++ url_scheme nfs://10.160.4.244/nfs
+++ local url=nfs://10.160.4.244/nfs
+++ local scheme=nfs
+++ grep -q :
+++ echo nfs
+++ echo nfs
++ local scheme=nfs
++ case "$TAPE_DEVICE:$scheme" in
++ '[' incremental == incremental ']'
+++ ls /tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/2016-11-09-1157-F.tar.gz
++ for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
++ restorearchive=/tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/2016-11-09-1157-F.tar.gz
+++ date +%a
++ '[' Wed = Wed ']'
++ Log 'It is Full-Backup-Day'
++ test 1 -gt 0
+++ Stamp
+++ date '+%Y-%m-%d %H:%M:%S.%N '
++ echo '2016-11-09 12:09:35.653538566 It is Full-Backup-Day'
2016-11-09 12:09:35.653538566 It is Full-Backup-Day
++ rm -f /tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/timestamp.txt
++ '[' -f /tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/timestamp.txt ']'
++ '[' '!' -f /tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/basebackup.txt ']'
++ rm -f /tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/timestamp.txt
++ Log 'Timestamp-Files screwd - Performing Full-Backup'
++ test 1 -gt 0
+++ Stamp
+++ date '+%Y-%m-%d %H:%M:%S.%N '
++ echo '2016-11-09 12:09:35.661399879 Timestamp-Files screwd - Performing Full-Backup'
2016-11-09 12:09:35.661399879 Timestamp-Files screwd - Performing Full-Backup
++ '[' -f /tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/timestamp.txt ']'
+++ date +%Y-%m-%d-%H%M
++ backuparchive=/tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/2016-11-09-1209-F.tar.gz
++ date +%Y-%m-%d
+++ date +%Y-%m-%d-%H%M
++ echo 2016-11-09-1209-F.tar.gz
+++ date +%Y-%m-%d-%H%M
++ BACKUP_PROG_X_OPTIONS=' -V 2016-11-09-1209-F.tar.gz'
++ Log 'Performing Full-Backup /tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/2016-11-09-1209-F.tar.gz'
++ test 1 -gt 0
+++ Stamp
+++ date '+%Y-%m-%d %H:%M:%S.%N '
++ echo '2016-11-09 12:09:35.683016386 Performing Full-Backup /tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/2016-11-09-1209-F.tar.gz'
2016-11-09 12:09:35.683016386 Performing Full-Backup /tmp/rear.GGFucs3Uy8VXOTK/outputfs/d108/2016-11-09-1209-F.tar.gz
++ NETFS_KEEP_OLD_BACKUP_COPY=
+ test 1
+ Debug 'Leaving debugscripts mode (back to previous bash flags and options settings).'
It states "Timestamp-Files screwd" but that is not right
because my timestamp.txt looks right:
nfs # cat d108/timestamp.txt 2016-11-09
So the second bug is that BACKUP_TYPE=incremental
does not work at least when "rear mkbackup" is run two times
on the same day.
I will try to clean it up and fix the issues...
jsmeix commented at 2016-11-09 12:13:¶
I think I found out why during my first "rear mkbackup" run
the command
for i in '$(ls ${BUILD_DIR}/outputfs/${NETFS_PREFIX}/*${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX})'
results unexpected files:
It is because of the nullglob bash option, see usr/sbin/rear
# Set some bash options: # With nullglob set when e.g. for foo*bar no file matches are found, then foo*bar is removed # (e.g. "ls foo*bar" becomes plain "ls" without "foo*bar: No such file or directory" error). # The extglob shell option enables several extended pattern matching operators. shopt -s nullglob extglob
jsmeix commented at 2016-11-11 13:12:¶
I did some fixes and clean up
some parts of incremental backup, see
https://github.com/rear/rear/pull/1066
@jottschi
I cannot reproduce your duplicated tar options
-06-0015-F.tar.gz--newer=2016-11-06 -V 2016-11-06-0015-F.tar.gz --newer=2016-11-06 -V 2016-11-06-0015-F.tar.gz
In my "rear -d -D mkbackup" and "rear -d -D recover"
log files I only have a single entry like
++ BACKUP_PROG_X_OPTIONS=' --newer=2016-11-09 -V 2016-11-09-1213-F.tar.gz'
@jottschi
could you test if it works for you with my
https://github.com/rear/rear/pull/1066
jottschi commented at 2016-11-11 13:13:¶
Hallo Johannes
Danke für die schnelle Reaktion.
Ich probiere es am Wochenende aus.
Am 11.11.2016 14:12 schrieb "Johannes Meixner" notifications@github.com:
I did some fixes and clean up
some parts of incremental backup, see
#1066 https://github.com/rear/rear/pull/1066@jottschi https://github.com/jottschi
I cannot reproduce your duplicated tar options-06-0015-F.tar.gz--newer=2016-11-06 -V 2016-11-06-0015-F.tar.gz --newer=2016-11-06 -V 2016-11-06-0015-F.tar.gz
In my "rear -d -D mkbackup" and "rear -d -D recover"
log files I only have a single entry like++ BACKUP_PROG_X_OPTIONS=' --newer=2016-11-09 -V 2016-11-09-1213-F.tar.gz'
@jottschi https://github.com/jottschi
could you test if it works for you with my
#1066 https://github.com/rear/rear/pull/1066—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/issues/1062#issuecomment-259954276, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AG-zstUJXUYlqfJkqrV-8GIVGBX9sUVOks5q9GmhgaJpZM4Ks-dx
.
jsmeix commented at 2016-11-11 13:35:¶
While working on
https://github.com/rear/rear/pull/1066
I understood why the incremental backup feature
should have never beed added into the current ReaR code.
The current ReaR code supports only one single backup archive
but incremental backup restore means to restore two
backup archives, first a full backup archive and
then an incremental/differential backup archive.
But restore/NETFS/default/400_restore_backup.sh is only
prepared to properly restore one single backup archive.
Therefore the current incremental backup feature
implementation must be a dirty hack that does
not fit well into the rest of the ReaR code.
Accordingly my
https://github.com/rear/rear/pull/1066
has to add even more dirty hacks to make the
incremental backup feature at least appear a bit better
to the user - but its current implementation is ugly.
A proper incremental backup feature implementation
needs as precondition in ReaR generic support
for multiple backup archives.
And support for multiple backup archives is some first
step towards "Multiple Backup Methods" cf.
https://github.com/rear/rear/issues/769
jsmeix commented at 2016-11-15 13:28:¶
With
https://github.com/rear/rear/pull/1066
merged, BACKUP_TYPE="incremental"
works now sufficiently well for me, see in particular
https://github.com/rear/rear/pull/1066#issuecomment-260638160
Nevertheless the current incremental backup implementation
is basically a dirty hack (several special case handling for it
spread over several scripts), cf. above my
https://github.com/rear/rear/issues/1062#issuecomment-259958396
@jottschi
please test with current ReaR GitHub master code
if it also works sufficiently well for you (but do not expect
too much from the curent incremental backup implementation).
In general how to test the current ReaR GitHub master code:
Basically "git clone" it into a directory and
then run rear from within that directory like:
# git clone https://github.com/rear/rear.git # cd rear # vi etc/rear/local.conf # usr/sbin/rear -d -D mkbackup
jsmeix commented at 2016-11-15 13:40:¶
@danboid regarding your
https://github.com/rear/rear/issues/1065#issuecomment-260188833
"does incremental backup to a samba share work?"
Please test with current ReaR GitHub master code
if the curent incremental backup implementation
works sufficiently well for you.
I never used a Samba share as a ReaR output location
(OUTPUT_URL=cifs:// or via BACKUP_URL=cifs://)
or in any other way - simply put: I do not use Samba.
danboid commented at 2016-11-15 13:50:¶
Hi jsmeix!
I think I read in one of these bug reports that the old incremental code didn't work if you tried to do an incremental update more than once a day? I presume that should be fixed now?
Does using incremental mode now backup to flat, uncompressed files instead of 1/2 tarballs?
If I wanted to run incremental backups via cron job, are there any X11 tray applets I could use to show me when rear is doing a backup / incremental sync and hopefully show progress (as a percentage) too? If its using rsync then maybe grsync could be used?
jsmeix commented at 2016-11-16 10:28:¶
With
https://github.com/rear/rear/pull/1066
merged, I consider this issue as sufficiently fixed.
Because the current incremental backup implementation
is basically a dirty hack (see my above comments in this issue)
do not expect too much from the curent incremental backup
implementation.
In general regarding issues with the backup:
Relax-and-Recover is neither a backup software nor a
backup management software and it is not meant to be one, cf.
"Relax-and-Recover (rear) versus backup and restore" in
https://en.opensuse.org/SDB:Disaster_Recovery
The general basic question is if more and more backup related
features should be added to ReaR because each feature requires
that someone volunteers to continuously maintain that feature
in the future (i.e. fix bugs and adapt it for future changes).
In general see also
https://github.com/rear/rear/issues/769
jsmeix commented at 2016-11-16 12:57:¶
Regarding
https://github.com/rear/rear/issues/1062#issuecomment-259958396
see
https://github.com/rear/rear/issues/1069
jsmeix commented at 2016-11-18 12:55:¶
FYI:
Currently I am doing a lot of cleanup and enhancements regarding
incremental/differential backup, see
https://github.com/rear/rear/issues/1069
and
https://github.com/rear/rear/pull/1071
Perhaps experienced GitHub users who
also use incremental/differential backup
may like to try out my current branch on
https://github.com/jsmeix/rear/tree/Support_multiple_restore_archives_issue1069
and provide me feedback.
[Export of Github issue for rear/rear.]