Yes from Mike's email it does seem there is a problem with
rdiff-backup if the destination filesystem is accessed via
I hadn't realised you use sshfs, the script you gave
appeared to use rdiff-backup's internal connection method.
Yet I use sshfs to mount a remote source directory (for a
source machine which cannot run rdiff-backup) and I have
never had any problems with it, my remote filesystem is
ext4 (previously reiserfs), the destination filesystem is
ext4. I have always used rdiff-backup switches --no-eas
and --no-acls which may or may not be significant, and I
backup from an LVM snapshot of the source.
What are the underlying filesystems for the sources (/etc
and /home) and for the destination (YYY.domain.nl
Free File Recovery from Whenever
On 14/05/2014 13:43, M. Verkerk wrote:
Thanks for your response!
Some of these files are from inactive users and I’m
quite sure their files weren’t changed during the
Did you read the email from Mike Fleetwood? These
are similar error messages, allegedley caused by
retrieving wrong hid and gid on NFS file systems. I’m
using a remote filesystem as well, SSHFS, over here!
I have applied this patch and running a backup at
this very moment. Unfortunately it’s taking quite long
because I had to interrupt a previous backup and rdiff
is busy with ‘regressing’.
similar situation was discussed here quite
recently, see http://lists.gnu.org/archive/html/rdiff-backup-users/2014-03/msg00012.html
The cause in this case, and probably in yours, is
that the source data is changing while the backup
is proceeding. I note that in your case some of
the source files that are missing in backup have
not changed, but maybe their metadata changed?
What filesystem are they on?
If you really need to backup the missing files,
using a static copy of the source (e.g. a
snapshot) should solve the problem. If the missing
files are unimportant, Chris Wilson suggested a
way to stop these messages appearing.