10:45 a.m.
I updated to F36 a few days ago and everything seemed to go smoothly
until I noticed my regular nightly backups were failing. I use
Borgbackup and the configuration has been stable for a long time with
no problems. The actual backup does seem to succeed, but Borg runs a
post-backup repository check that is now failing, even for backups
taken before the system upgrade.
I've reported this:
https://mail.google.com/mail/u/1/?zx=60aw7rldu1gf&pli=1#inbox
poc
11:20 a.m.
16.05.22, 17:45 +0200, Patrick O'Callaghan:
I updated to F36 a few days ago and everything seemed to go smoothly
until I noticed my regular nightly backups were failing. I use
Borgbackup and the configuration has been stable for a long time with
no problems. The actual backup does seem to succeed, but Borg runs a
post-backup repository check that is now failing, even for backups
taken before the system upgrade.
Could be caused by the update to borg 1.2. You might want to take a look
at this bug report:
https://github.com/borgbackup/borg/issues/6687
I've reported this:
https://mail.google.com/mail/u/1/?zx=60aw7rldu1gf&pli=1#inbox
I don't get where this link is supposed to lead to.
--
Regards
mks
2:56 p.m.
On Mon, 2022-05-16 at 18:20 +0200, Markus Schönhaber wrote:
16.05.22, 17:45 +0200, Patrick O'Callaghan:
> I updated to F36 a few days ago and everything seemed to go
> smoothly
> until I noticed my regular nightly backups were failing. I use
> Borgbackup and the configuration has been stable for a long time
> with
> no problems. The actual backup does seem to succeed, but Borg runs
> a
> post-backup repository check that is now failing, even for backups
> taken before the system upgrade.
Could be caused by the update to borg 1.2. You might want to take a
look
at this bug report:
https://github.com/borgbackup/borg/issues/6687
I did consider that. However the upgrade to Borg 1.2 happened on April
12, weeks before the system upgrade to Fedora 36, and there were no
errors in the intervening time. Also, the built-in validation check on
the config file says it's all fine.
> I've reported this:
> https://mail.google.com/mail/u/1/?zx=60aw7rldu1gf&pli=1#inbox
I don't get where this link is supposed to lead to.
Sorry, that should have been:
https://bugzilla.redhat.com/show_bug.cgi?id=2086497
poc
5:08 p.m.
On Mon, 16 May 2022 20:56:10 +0100
Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
On Mon, 2022-05-16 at 18:20 +0200, Markus Schönhaber wrote:
> 16.05.22, 17:45 +0200, Patrick O'Callaghan:
>
> > I updated to F36 a few days ago and everything seemed to go
> > smoothly
> > until I noticed my regular nightly backups were failing. I use
> > Borgbackup and the configuration has been stable for a long time
> > with
> > no problems. The actual backup does seem to succeed, but Borg runs
> > a
> > post-backup repository check that is now failing, even for backups
> > taken before the system upgrade.
>
I upgraded a laptop to F36 few days ago and borgmatic runs without
error, including the check. I suspect something else is happening.
Try increasing borgmatic’s verbosity to see the borg error message.
borgmatic-1.6.0 does have some breaking changes, but that is the
current version for both 35 and 36.
Also, my systems are using borgbackup-1.1.17-1.fc35 and
borgbackup-1.2.0-1.fc36. How did you get 1.2.0 on F35?
Jim
> Could be caused by the update to borg 1.2. You might want to
take a
> look
> at this bug report:
> https://github.com/borgbackup/borg/issues/6687
>
I did consider that. However the upgrade to Borg 1.2 happened on April
12, weeks before the system upgrade to Fedora 36, and there were no
errors in the intervening time. Also, the built-in validation check on
the config file says it's all fine.
> > I've reported this:
> > https://mail.google.com/mail/u/1/?zx=60aw7rldu1gf&pli=1#inbox
>
> I don't get where this link is supposed to lead to.
Sorry, that should have been:
https://bugzilla.redhat.com/show_bug.cgi?id=2086497
poc
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
4:48 a.m.
On Mon, 2022-05-16 at 16:08 -0600, James Szinger wrote:
On Mon, 16 May 2022 20:56:10 +0100
Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
> On Mon, 2022-05-16 at 18:20 +0200, Markus Schönhaber wrote:
> > 16.05.22, 17:45 +0200, Patrick O'Callaghan:
> >
> > > I updated to F36 a few days ago and everything seemed to go
> > > smoothly
> > > until I noticed my regular nightly backups were failing. I use
> > > Borgbackup and the configuration has been stable for a long
> > > time
> > > with
> > > no problems. The actual backup does seem to succeed, but Borg
> > > runs
> > > a
> > > post-backup repository check that is now failing, even for
> > > backups
> > > taken before the system upgrade.
> >
I upgraded a laptop to F36 few days ago and borgmatic runs without
error, including the check. I suspect something else is happening.
Try increasing borgmatic’s verbosity to see the borg error message.
I may do that. However the Borg (not Borgmatic) BZ is reporting errors
related to 1.2. I'm not sure it's the same thing as my errors only
appeared after the F35->F36 update and I had been running Borg 1.2
before that.
borgmatic-1.6.0 does have some breaking changes, but that is the
current version for both 35 and 36.
Also, my systems are using borgbackup-1.1.17-1.fc35 and
borgbackup-1.2.0-1.fc36. How did you get 1.2.0 on F35?
I simply updated with dnf and there it was. Didn´t do anything special.
1.1x was the version on F35's initial release, but it changed
subsequently.
poc
6:11 a.m.
17.05.22, 11:48 +0200, Patrick O'Callaghan:
On Mon, 2022-05-16 at 16:08 -0600, James Szinger wrote:
> Also, my systems are using borgbackup-1.1.17-1.fc35 and
> borgbackup-1.2.0-1.fc36. How did you get 1.2.0 on F35?
I simply updated with dnf and there it was. Didn´t do anything special.
1.1x was the version on F35's initial release, but it changed
subsequently.
Hard to believe:
https://packages.fedoraproject.org/pkgs/borgbackup/borgbackup/
1.1.17 is what dnf shows as available on my F35 systems.
--
Regards
mks
7:12 a.m.
On Tue, 2022-05-17 at 13:11 +0200, Markus Schönhaber wrote:
17.05.22, 11:48 +0200, Patrick O'Callaghan:
> On Mon, 2022-05-16 at 16:08 -0600, James Szinger wrote:
> > Also, my systems are using borgbackup-1.1.17-1.fc35 and
> > borgbackup-1.2.0-1.fc36. How did you get 1.2.0 on F35?
>
> I simply updated with dnf and there it was. Didn´t do anything
> special.
> 1.1x was the version on F35's initial release, but it changed
> subsequently.
Hard to believe:
https://packages.fedoraproject.org/pkgs/borgbackup/borgbackup/
1.1.17 is what dnf shows as available on my F35 systems.
I've looked again and you're right. The 1.2 update did come with F36
after all. Hopefully upstream will fix it.
poc
2:12 p.m.
On 5/16/22 08:45, Patrick O'Callaghan wrote:
I updated to F36 a few days ago and everything seemed to go smoothly
until I noticed my regular nightly backups were failing. I use
Borgbackup and the configuration has been stable for a long time with
no problems. The actual backup does seem to succeed, but Borg runs a
post-backup repository check that is now failing,
That might be an indication that one of your backups was interrupted.
If you're running borg on a laptop, you should take steps to make sure
that the system will not suspend in the middle of a backup. I recommend
using systemd-inhibit to prevent system suspending:
https://github.com/gordonmessmer/ansible-borg-client/
4:15 p.m.
On Fri, 2022-05-20 at 12:12 -0700, Gordon Messmer wrote:
On 5/16/22 08:45, Patrick O'Callaghan wrote:
> I updated to F36 a few days ago and everything seemed to go
> smoothly
> until I noticed my regular nightly backups were failing. I use
> Borgbackup and the configuration has been stable for a long time
> with
> no problems. The actual backup does seem to succeed, but Borg runs
> a
> post-backup repository check that is now failing,
That might be an indication that one of your backups was
interrupted.
If you're running borg on a laptop, you should take steps to make
sure
that the system will not suspend in the middle of a backup. I
recommend
using systemd-inhibit to prevent system suspending:
https://github.com/gordonmessmer/ansible-borg-client/
Thanks, but it's a desktop and the issue appears to be related to the
latest version of Borg. The check errors happen across all of my
existing backups, not just one.
poc
8:20 p.m.
On 5/20/22 14:15, Patrick O'Callaghan wrote:
Thanks, but it's a desktop and the issue appears to be related to
the
latest version of Borg. The check errors happen across all of my
existing backups, not just one.
As a result of deduplication, it's expected that all (or most) of your
backups will share blocks of data. If there's corruption in the backup
data, it is not surprising that it would affect all of them and not just
one.
Don't assume that the current version is broken. You've dismissed
https://github.com/borgbackup/borg/issues/6687 several times for dubious
reasons. The conversation there included numerous troubleshooting
steps, and I suggest you go through all of them. If you still have
problems, collect a log of all of the commands you've run and the output
they provided, and add that to a bug report.
6:32 a.m.
On Fri, 2022-05-20 at 18:20 -0700, Gordon Messmer wrote:
On 5/20/22 14:15, Patrick O'Callaghan wrote:
> Thanks, but it's a desktop and the issue appears to be related to
> the
> latest version of Borg. The check errors happen across all of my
> existing backups, not just one.
As a result of deduplication, it's expected that all (or most) of
your
backups will share blocks of data. If there's corruption in the
backup
data, it is not surprising that it would affect all of them and not
just
one.
Don't assume that the current version is broken. You've dismissed
https://github.com/borgbackup/borg/issues/6687 several times for
dubious
reasons. The conversation there included numerous troubleshooting
steps, and I suggest you go through all of them. If you still have
problems, collect a log of all of the commands you've run and the
output
they provided, and add that to a bug report.
I haven't "dismissed" anything. The significant point is that these
errors only appeared on upgrading to 1.2. I'm watching that bug thread
and will add to it if I can say something useful.
However I'll take your point about trying the troubleshooting steps. I
haven't done so to date as my experience with Borg is limited.
poc
8:23 a.m.
On Sat, 2022-05-21 at 12:32 +0100, Patrick O'Callaghan wrote:
On Fri, 2022-05-20 at 18:20 -0700, Gordon Messmer wrote:
> On 5/20/22 14:15, Patrick O'Callaghan wrote:
> > Thanks, but it's a desktop and the issue appears to be related to
> > the
> > latest version of Borg. The check errors happen across all of my
> > existing backups, not just one.
>
>
> As a result of deduplication, it's expected that all (or most) of
> your
> backups will share blocks of data. If there's corruption in the
> backup
> data, it is not surprising that it would affect all of them and not
> just
> one.
>
> Don't assume that the current version is broken. You've dismissed
> https://github.com/borgbackup/borg/issues/6687 several times for
> dubious
> reasons. The conversation there included numerous troubleshooting
> steps, and I suggest you go through all of them. If you still have
> problems, collect a log of all of the commands you've run and the
> output
> they provided, and add that to a bug report.
I haven't "dismissed" anything. The significant point is that these
errors only appeared on upgrading to 1.2. I'm watching that bug
thread
and will add to it if I can say something useful.
However I'll take your point about trying the troubleshooting steps.
I
haven't done so to date as my experience with Borg is limited.
poc
I managed to fix it using 'borg check --repair'. My backup drive is a
BTRFS RAID1, so after using Btrfs to check there were no physical
errors, I copied the Borg repository ('cp -R', really fast because of
COW), then ran the repair. It reported a single error from an
unimportant file (which presumably was causing the shower of errors due
to de-duplication), and the repair fixed it.
Thanks for the various suggestions.
poc
703
days inactive
709
days old
11 comments
4 participants
participants (4)
-
Gordon Messmer -
James Szinger -
Markus Schönhaber -
Patrick O'Callaghan