It is an ext4 filesystem. The directories are plain ASCII -- no
strange characters in any way. The `rsync` process on the Linux client
runs as root, and I have verified root has access to these files
without any issue. There are plenty of inodes free (`df -i` shows that
filesystem as only 5% used). There is no file corruption -- all the
data is good.
There is a seemingly weird coincidence here though... my backups have
been running nightly for years. However, in late 2017 I updated
BackupPC on my Fedora box, and `--one-file-system` was added to the
rsync args without me realizing. This caused all backups from that
point forward to a few days ago to be missing all the new files and
modifications in `/home`, which is a mountpoint for a local LVM ext4
partition. It seems that every file and directory that falls into this
category are now failing with this "vanished" error. Is it possible
that BackupPC is confused because it is expecting to find these files
in prior backups?
I will try the debugging you suggest.
Regards,
Raman
On Wed, May 8, 2019 at 1:44 AM Craig Barratt via BackupPC-users
<backuppc-users@lists.sourceforge.net> wrote:
>
> What sort of filesystem is this? Do those directory names contain non-ascii
> characters?
>
> However, the "file has vanished" error shouldn't occur on a directory, so
> something strange is going on.
>
> I'd recommend turning on additional debug in rsync (eg, add -vvv to
> $Conf{RsyncArgs}, and also look at the --debug option) and looking in the
> XferLOG file. When the initial file list is sent, are those directories and
> their contents present in the file list?
>
> Craig
>
> On Tue, May 7, 2019 at 4:26 PM Michael Stowe <michael.st...@member.mensa.org>
> wrote:
>>
>> On 2019-05-07 13:39, Raman Gupta wrote:
>>
>> Certain directories (and their contents) on one of my hosts are not getting
>> backed up at all, even with a “Full” backup.
>>
>> I use rsync as my Xfer method, with BackupPC 4.3.0 on Fedora (rpms
>> BackupPC-4.3.0-1.fc29.x86_64, BackupPC-XS-0.58-1.fc29.x86_64).
>>
>> Looking at the backup logs, I see messages like the following related to the
>> directories that are not being backed up:
>>
>> file has vanished: “/home/raman/x/y/a” file has vanished:
>> “/home/raman/x/y/b” file has vanished: “/home/raman/x/y/c”
>>
>> I have other directories and files successfully backed up in
>> “/home/raman/x/y”, but the directories “a”, “b”, and “c” (and their content)
>> are not being backed up.
>>
>> Note that these files have not vanished — they are not ephemeral and they
>> haven't been touched in days. For example:
>>
>> File: /home/raman/x/y/a
>> Size: 4096 Blocks: 8 IO Block: 4096 directory
>>
>> Device: fd08h/64776d Inode: 33037482 Links: 5 Access: (0775/drwxrwxr-x) Uid:
>> ( 1000/ raman) Gid: ( 1000/ raman) Context:
>> unconfined_u:object_r:user_home_t:s0 Access: 2019-05-07 05:05:17.288857497
>> -0400 Modify: 2019-04-30 00:56:22.914849594 -0400 Change: 2019-04-30
>> 00:56:22.914849594 -0400 Birth: –
>>
>> Any idea what might be happening here?
>>
>> Regards, Raman
>>
>> “File has vanished” issues can be tricky to diagnose if the file appears to
>> be there. What rsync is really telling you is that it built a file list, and
>> some of the files or directories from that list are not accessible when it
>> actually went to read them. Actually being deleted or ephemeral files are
>> two reasons, but there are others, from filename encoding issues to inode
>> changes to complications with remotely mounted filesystems to corruption
>> issues to complex file permissions.
>>
>> While I might check the file's details both before and after the rsync run
>> to look for changes, I recommend ensuring that these files are reliably
>> accessible by the rsync user, check the logs for any problems, and working
>> through filesystem issues. (XFS is notorious for this sort of thing.) Also,
>> if the volume is anything other than a local mount, that's where I'd look
>> first for issues; be aware that rsync's high read volume often exposes
>> issues not evident under less stressful usage.
>>
>> _______________________________________________
>> BackupPC-users mailing list
>> BackupPC-users@lists.sourceforge.net
>> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
>> Wiki: http://backuppc.wiki.sourceforge.net
>> Project: http://backuppc.sourceforge.net/
>
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
