Craig,
Thanks for looking into this been using BackupPC for many years and have
been very happy with the way it has performed.
I'm glad that the info I provided was of some use and hopefully it helps
in resolving the bug. Other than a bit annoying to see the error this
issue isn't affecting
It should only affect rsync-bpc 3.1.3+. 3.1.2 and 3.0.9 use the original
style of handling long path and filename strings (just a large fixed size
is used).
Craig
On Tue, Jan 12, 2021 at 5:28 PM wrote:
> Craig Barratt via BackupPC-users wrote at about 15:32:27 +1100 on Tuesday,
> January 12,
Craig Barratt via BackupPC-users wrote at about 15:32:27 +1100 on Tuesday,
January 12, 2021:
> Pete,
>
> Thanks for the additional information. It's definitely a bug (same one
> reported by Alexander), and it's certainly due to the significant rewrite I
> did between rsync-bpc 3.1.2 and
Pete,
Thanks for the additional information. It's definitely a bug (same one
reported by Alexander), and it's certainly due to the significant rewrite I
did between rsync-bpc 3.1.2 and 3.1.3 on how long strings (used in many
places for file names, paths etc) are handled. Somehow the file name
Since Craig helped me chase various error bugs last spring/summer,
most of the errors and semi-errors in my backuppc backups have gone
away.
Using btrfs-snapshots for Linux and shadow backups for Windoze really
helped get rid of all the 'vanished' files issues...
However, in looking through the
Craig,
# su -m backuppc -c '/usr/share/BackupPC/bin/BackupPC_zcat
9dea1ea7cd900fa4fcd3e24f86ad0be8'
/usr/share/man/man1/alt-java-java-1.8.0-openjdk-1.8.0.275.b01-0.el7_9.x86_64.1.gz
Not sure if this is useful but
$ ls -l /usr/share/man/man1/alt-java*
lrwxrwxrwx 1 root root 31 Dec 18 08:08
Pete,
Thanks for that. Yes, this is exactly the same issue that Alexander
reported: https://github.com/backuppc/rsync-bpc/issues/18
One more step: what's the output from:
BackupPC_zcat 9dea1ea7cd900fa4fcd3e24f86ad0be8
Thanks,
Craig
On Mon, Jan 11, 2021 at 10:32 PM Pete Geenhuizen
wrote:
>
Thank you for the correct syntax here's what I get now.
'froot/fetc/falternatives/attrib' => {
'compress' => 3,
'digest' => '9dea1ea7cd900fa4fcd3e24f86ad0be8',
'gid' => 0,
'inode' => 562108,
'mode' => 511,
'mtime' => 0,
'name' => 'froot/fetc/falternatives/attrib',
11.01.2021 3:07, backu...@kosowsky.org пишет:
Pete Geenhuizen wrote at about 14:38:17 -0500 on Sunday, January 10, 2021:
>
> /usr/share/BackupPC/bin/BackupPC_zcat
> ./attrib_d4c95788f1e2e67ddadd2e2ff26e0fc6 |wc
> 0 0 0
>
>
Pete Geenhuizen wrote at about 14:38:17 -0500 on Sunday, January 10, 2021:
>
> /usr/share/BackupPC/bin/BackupPC_zcat
> ./attrib_d4c95788f1e2e67ddadd2e2ff26e0fc6 |wc
> 0 0 0
>
> /usr/share/BackupPC/bin/BackupPC_attribPrint
>
/usr/share/BackupPC/bin/BackupPC_zcat
./attrib_d4c95788f1e2e67ddadd2e2ff26e0fc6 |wc
0 0 0
/usr/share/BackupPC/bin/BackupPC_attribPrint
/etc/alternatives/froot/fetc/falternatives/attrib
$attrib = {
};
All the attrib_ files that I find are 0 length.
On 1/9/21 10:42 PM,
Excellent point - yes it does look like it's the same issue. The error does
mention a mangled file path, which it shouldn't know about.
Pete - please look in the attrib file of the parent directory (as in that
issue) to see if the signature is the same.
Craig
On Sun, Jan 10, 2021 at 5:22 PM
Seems the same as https://github.com/backuppc/rsync-bpc/issues/18
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:
Pete,
Also, it would be good to see if that attrib file exists or has some
problem. What happens when you look in that directory on a full (filled)
backup? There should be a single file there with the name attrib_DIGEST,
where DIGEST is the 32 hex digits of the md5 digest. What happens when
Peter,
Ok, those are all the latest versions. The next step is to increase the
debug level (eg, XferLogLevel to 7 and "-vv" to rsync-bpc args) and send me
a healthy portion of the log (eg, a couple of thousand lines up until the
error, and a few hundred lines after the error).
Craig
On Sat,
Craig,
Thanks for the response, these are the versions that I'm running
BackupPC4-4.4.0-2.el7.fws.x86_64
BackupPC-XS-0.62-2.el7.fws.x86_64
rsync-bpc-3.1.3.0-2.el7.fws.x86_64
Pete
On 1/8/21 9:08 PM, Craig Barratt wrote:
This should be fixed in the latest version of rsync-bpc. What
versions
This should be fixed in the latest version of rsync-bpc. What versions are
you using (BackupPC, rsync-bpc and backuppc-xs)?
Craig
On Sat, Jan 9, 2021 at 8:08 AM Pete Geenhuizen
wrote:
> After a recent kernel update for Centos 7 I started seeing the following
> error on 2 hosts. I didn't give
After a recent kernel update for Centos 7 I started seeing the following
error on 2 hosts. I didn't give it much thought figuring that it
probably would disappear when the next level 0 backup was done, but nope
the error persists.
file has vanished:
18 matches
Mail list logo
