Re: cross-platform backup tool Traceback of failed backup

[Robert Nichols]

I finally had time to track this down, and it's not the fault of rdiff-backup.

Somehow (and I have no idea how) I managed to delete _all_ of the empty 
directories in the mirror. This goes undetected until one of those empty 
directories is deleted in the source. That causes the next backup session to 
fail in the manner shown below.

My only complaint about rdiff-backup is that "verify" does not complain about directories 
that are present (albeit empty) in the metadata file but missing in the mirror. That situation is a 
"time bomb" that can cause a mysterious failure in some future backup session. I'll post 
an RFE about that.

--
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.

On 11/1/22 12:49 PM, Robert Nichols wrote:
> Right now I have a repeatable test case that I'm trying to trim down to 
> something that does not involve 20GB of data.
>
> I'm doing the testing and seeing the failure with a local filesystem copy on 
> the 2.1.3b3 server -- no remote access involved.
>
> On 10/30/22 8:44 AM, Robert Nichols wrote:
> > OK, I'll do that. Unfortunately, the problem is not 100% repeatable. After 
> > reverting the archive to the previous state (it had verified OK prior to this 
> > failing session), a re-run of this same backup completed successfully. This 
> > isn't the first time I've encountered this error, and it seems I'll have to 
> > wait for the next Fedora kernel update to see if it happens again.
> > > On 10/30/22 3:11 AM, EricZolf wrote:
> > > Hi Robert,
> > >
> > > could be a regression indeed. Do you mind creating an issue with the exact call 
> > > you used?
> > >
> > > Thanks, Eric
> > >
> > > PS: Fedora, good distro choice :-)
> > >
> > >
> > > On 29/10/2022 17:28, Robert Nichols wrote:
> > > > Can someone please make sense of this traceback from a rdiff-backup 2.0.5 
> > > > client backing up to a rdiff-backup 2.1.3b3 server.
> > > >
> > > > The directory /usr/lib/modules/5.19.12-200.fc36.x86_64/extra is deleted since 
> > > > the previous backup. The entire /usr/lib/modules/5.19.12-200.fc36.x86_64 
> > > > subtree was deleted by the most recent kernel update. It exists and verifies OK 
> > > > in the previous backup.
> > > >
> > > > Warning: Local version 2.0.5 does not match remote version 2.1.3b3.
> > > > Exception 'Either diff '<RORPath/140364064494144:
> > > >      Index=('usr', 'lib', 'modules', '5.19.12-200.fc36.x86_64', 'extra')
> > > >      Data={'type': None, 'filetype': 'snapshot'}>' or base 
> > > > '<RPath/140364064904528:
> > > >      Path=/media/sysbk/lenovo-F36/usr/lib/modules/5.19.12-200.fc36.x86_64/extra
> > > >      Index=('usr', 'lib', 'modules', '5.19.12-200.fc36.x86_64', 'extra')
> > > >      Connection=LocalConnection
> > > >      Data={'type': None}>' must be a directory' raised of class '<class 
> > > > 'AssertionError'>':
> [snipped]