bup backup job: failed to generate recovery info.

[Peter Nunn]

I'm trying to use Kup on my KDE system and have bup hooked up to a synology nas on my network via a network share (cifs).

The files seem to be getting transferred OK, but every time I run the backup it fails with 

Could not create "/home/pnunn/.bup/objects/pack/pack-064d1ae7067f73ff315fa1662fc587496e6e00f3.vol000+200.par2": File already exists.
b'pack-064d1ae7067f73ff315fa1662fc587496e6e00f3' par2 create: failed (6)


Exit code: 6
Kup did not successfully complete the bup backup job: failed to generate recovery info.

These files do exist on the system, from days ago, and are all 0 size (the ones that are failing).

I've deleted them to see if that fixes it (No loss if it breaks things because if I can't sort this out I'll have to blow it all away and try something else anyway).

Is there a better fix for this?  Bup is 0.32

[Greg Troxel]

Peter Nunn <ped...@gmail.com> writes:

> I'm trying to use Kup on my KDE system and have bup hooked up to a synology
> nas on my network via a network share (cifs).

I'll comment but note that I do not use Kup (being a command-line type)
and I do not use cifs (being a unix type).

I would be suspicious of cifs and/or the implementations, as I haven't
seen this kind of report before, but OTOH presumably synology stuff works.

[pruned and formatted slightly for dicsussion]

> The files seem to be getting transferred OK, but every time I run the
> backup it fails with
> Could not create
> "/home/pnunn/.bup/objects/pack/pack-064d1ae7067f73ff315fa1662fc587496e6e00f3.vol000+200.par2":
> File already exists.
> b'pack-064d1ae7067f73ff315fa1662fc587496e6e00f3' par2 create: failed (6)
>

> These files do exist on the system, from days ago, and are all 0 size (the
> ones that are failing).

I am having a hard time reconciling these two statements. The packfile
id is a hash, and it depends on the backup. But yet the file exists
and had an ctime/mtime from before the backup?

Are you sure all the clocks are right?

Could it really be that you did a backup, it failed, and you tried
again, but nothing changed?

> I've deleted them to see if that fixes it (No loss if it breaks things
> because if I can't sort this out I'll have to blow it all away and try
> something else anyway).
>
> Is there a better fix for this? Bup is 0.32

You can run "bup fsck -g" to generate parity from the backup you have.

I would run "bup fsck" first to see if there is anything else wrong.

[Peter Nunn]

Thanks for the help Greg.

While I was mucking around with this today, I deleted pretty much all of the previous backups (despite the fact that it was saying that none of them had completed), then ran the backup again and it finally went to completion.

I'll be interested to see what happens from here on in, but I'll get back on here if there are any more problems.

Again, thanks heaps for the help. I'll keep the command line tools in mind (probably a better option in the long run anyway).

Peter.

[Rob Browning]

Peter Nunn <ped...@gmail.com> writes:

> Thanks for the help Greg.
>
> While I was mucking around with this today, I deleted pretty much all of
> the previous backups (despite the fact that it was saying that none of them
> had completed), then ran the backup again and it finally went to completion.
>
> I'll be interested to see what happens from here on in, but I'll get back
> on here if there are any more problems.
>
> Again, thanks heaps for the help. I'll keep the command line tools in mind
> (probably a better option in the long run anyway).

Glad you got it working. For what it's worth, I think we've had some
reports off and on of trouble where cifs was involved (though don't know
that we've ever determined for sure that cifs in particular was the
issue).

For example: https://groups.google.com/g/bup-list/c/T4WIFmjPs0w/m/7uPPYsqzAgAJ

--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4