This is a bug. I was able to reproduce it and have created an issue for
it here:
https://github.com/sol1/rdiff-backup/issues/9
You can try to work around your problem by:
1) using '--check-destination-dir'; then
2) look at the name of your current_mirror file (and there must only be
one of them). In your case, it looks like that name would be:
/run/media/miborn/WD1TB/T450s_rdiff-backup/rdiff-backup-data/current_mirror.2016-07-21T22:41:21+02:00.data
3) look in 'rdiff-backup-data/long_filename_data/' and remove (but keep
somewhere safe, just in case) any files there that have a date in their
filename that is greater or equal to the date in the current_mirror
filename. In your case, it looks like there will at least be:
/run/media/miborn/WD1TB/T450s_rdiff-backup/rdiff-backup-data/long_filename_data/1.2016-07-30T16:25:41+02:00.diff.gz
That *should* fix things for you, but I give no guarantees.
I am a little puzzled about why the date of the file in the
long_filename_data/ directory is greater than (instead of equal to) the
date of your current_mirror (after having regressed the repository). I
guess that would be possible if you regressed your repository backward
more than just a single increment.
On 8/20/2016 7:13 AM, Michael Born wrote:
Dear rdiff-backup users.
After years of trouble-free rdiff-backup usage I have a big problem with
a weekly backup I started some months ago.
My OpenSUSE 13.2 64bit /home/user (ext4) has been successfully backuped
to my USB3 hdd (ext4) with enough free space on it.
Since after the 11th incremental backup I get this Exception:
Fri Aug 19 19:21:05 2016 Exception 'Path:
/run/media/miborn/WD1TB/T450s_rdiff-backup/rdiff-backup-data/long_filename_data/1.2016-07-30T16:25:41+02:00.diff.gz
Index: ('long_filename_data', '1.2016-07-30T16:25:41+02:00.diff.gz')
Data: {'acl': <rdiff_backup.eas_acls.AccessControlLists instance at
0x7eff65474050>, 'uid': 1000, 'perms': 420, 'type': 'reg', 'gname':
'users', 'ea': <rdiff_backup.eas_acls.ExtendedAttributes instance at
0x7eff65464ea8>, 'ctime': 1470554687, 'devloc': 65025L, 'uname':
'miborn', 'nlink': 1, 'gid': 100, 'mtime': 1469825388, 'atime':
1471028717, 'inode': 58597284, 'size': 62}' raised of class '<type
'exceptions.AssertionError'>':
File "/usr/lib64/python2.7/site-packages/rdiff_backup/robust.py", line
32, in check_common_error
try: return function(*args)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/increment.py",
line 43, in Increment
incrp = makediff(new, mirror, incpref)
File "/usr/lib64/python2.7/site-packages/rdiff_backup/increment.py",
line 79, in makediff
if compress: diff = get_inc(incpref, "diff.gz")
File "/usr/lib64/python2.7/site-packages/rdiff_backup/increment.py",
line 123, in get_inc
assert not incrp.lstat(), incrp
(more output here: http://pastebin.com/czKdWATg )
The following doesn't work any more after the Exception.
miborn@hnb533:~> rdiff-backup --list-increments -v9
...
Fri Aug 19 23:37:23 2016 Fatal Error: Previous backup to
/run/media/miborn/WD1TB/T450s_rdiff-backup seems to have failed.
Rerun rdiff-backup with --check-destination-dir option to revert
directory to state before unsuccessful session.
After running the --check-destination-dir command I can list the backups
(see here: http://pastebin.com/zcZq6Sbh ), but re-running (incrementing)
the backup only runs in the Exception again.
Could anybody help debugging that problem?
Is this problem known and does a solution exist?
For testing I did the following things.
1. I created a new backup (new/empty destination dir). There, the backup
finished without an error.
2. I removed the last incremental backup with the help of that script:
http://www.timedicer.co.uk/programs/help/rdiff-backup-regress.sh.php
But, the incremental backup did run into the same Exception again.
3. I used the option --exclude
/home/miborn/.kde4/share/apps/okular/docdata/ to exclude the file where
the Exception happened before. Unfortunately rdiff-backup presented me a
new error message:
File "/usr/lib64/python2.7/gzip.py", line 432, in seek
raise IOError('Negative seek in write mode')
(longer message see here: http://pastebin.com/G64SrnVn )
4. I checked the access rights of the .xml file that was listed before
the exception and also the .diff.gz file of the backup. All rights seem
all right to me. The backup is always run as the user and the user has
write access to the USB disk.
Cheers,
Michael
PS: my command line is:
time rdiff-backup -v9 --exclude
/home/miborn/.kde4/share/apps/okular/docdata/ --exclude
/home/miborn/.cache --exclude /home/miborn/MediathekView/ --exclude
/home/miborn/mnt --exclude /home/miborn/yEd --exclude /home/miborn/mnt2
--exclude /home/miborn/Videos --exclude /home/miborn/.local/share/Trash/
--exclude /home/miborn/.local/share/Steam /home/miborn
/run/media/miborn/WD1TB/T450s_rdiff-backup
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
