I'm not sure why you are having problems with bpc-rsync 3.1.2 and 3.1.3-beta0. Maybe try higher levels of logging and adding -vv to the remote rsync. How quickly does it fail? Is it some ssh-related issue?
I finally was able to get ubuntu to boot on my machine with selinux turned on in permissive mode, although it's clearly not configured correctly. I can see default selinux file attributes with ls -Z. And I can change them with chcon or semanage fcontext. But the actual files I set don't have any xattr settings. I assume all those commands are doing is updating files below /etc/selinux/targeted/contexts/files. Directly running rsync -X to copy those files doesn't preserve their selinux attributes. Anyhow, I separately reconfirmed that a user xattr setting on a regular file is correctly backed up and restored. Craig On Mon, May 25, 2020 at 3:43 PM <backu...@kosowsky.org> wrote: > Thanks Craig. > This problem was bothering me for the longest of times... but I always > assumed it was due to files changing or some other spurious factors... > But now that I am backing up against fixed snapshots, it has become > easier to one-by-one track down unexpected bugs & error messages... > > The only remaining issue I see now is with SELinux extended attributes > :) > > Plus, the challenges with hangs on bpc-rsyn 3.1.2 and 3.1.3-beta0 > > Craig Barratt via BackupPC-users wrote at about 13:08:31 -0700 on Monday, > May 25, 2020: > > Jeff, > > > > Thanks for figuring that out. I pushed a fix > > < > https://github.com/backuppc/rsync-bpc/commit/96e890fc3e5bb53f6618bd8650e8400f355b243a > > > > so the warning doesn't get printed on zero-length files. > > > > Craig > > > > On Mon, May 25, 2020 at 8:08 AM <backu...@kosowsky.org> wrote: > > > > > Presumably the problem is in rsync-bpc: bpc_sysCalls.c > > > > > > int bpc_sysCall_checkFileMatch(char *fileName, char *tmpName, struct > > > file_struct *rsyncFile, > > > char *file_sum, off_t fileSize) > > > { > > > bpc_attrib_file *fileOrig, *file; > > > char poolPath[BPC_MAXPATHLEN]; > > > > > > if ( !(fileOrig = bpc_attribCache_getFile(&acNew, fileName, 0, > 0)) ) { > > > /* > > > * Hmmm. The file doesn't exist, but we got deltas > suggesting the > > > file is > > > * unchanged. So that means the generator found a matching > pool > > > file. > > > * Let's try the same thing. > > > */ > > > if ( bpc_sysCall_poolFileCheck(fileName, rsyncFile) > > > || !(fileOrig = bpc_attribCache_getFile(&acNew, > fileName, > > > 0, 0)) ) { > > > bpc_logErrf("bpc_sysCall_checkFileMatch(%s): file doesn't > > > exist\n", fileName); > > > return -1; > > > } > > > } > > > ... > > > > > > But the zero length file (with md5sum > > > d41d8cd98f00b204e9800998ecf8427e) is not in the pool. > > > > > > Presumably, one should add a check to eliminate... > > > > > > backu...@kosowsky.org wrote at about 10:36:55 -0400 on Monday, May > 25, > > > 2020: > > > > Seems like these are all the zero length files... > > > > Could it be that backuppc is checking for file length rather than > file > > > existence??? > > > > > > > > > > > > Note: when I delete the backup and run it again, the *exact* same > > > > "file doesn't exist' errors reappears (even though a new btrfs > snapshot > > > > has been created). So I am pretty sure it is not a filesystem > issue > > > > but rather likely a bug in backuppc... > > > > > > > > > > > > backu...@kosowsky.org wrote at about 10:00:31 -0400 on Monday, > May 25, > > > 2020: > > > > > I am still occasionally but not at all consistently getting > errors > > > of form: > > > > > > > > > Rbpc_sysCall_checkFileMatch(var/lib/spamassassin/3.004002/updates_spamassassin_org/STATISTICS-set3-72_scores.cf.txt): > > > file doesn't exist > > > > > > > > > > Here is some background: > > > > > - Only seems to occur on full backups > > > > > - These messages correspond to files that have changed or been > added > > > since the previous backup > > > > > - However, they only occur on some incrementals and only for a > small > > > subset of the changed files, even when they do occur > > > > > - The files are still backed up properly > > > > > - The files never 'vanished' or changed since I am using > read-only > > > btrfs snapshots > > > > > - My system is rock-solid and I have not had any other file > system > > > troubles > > > > > > > > > > Is this really an error? > > > > > What is causing it? > > > > > Why does it happen seemingly randomly? > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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/ > > > > > _______________________________________________ > > 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/
