[Borgbackup] recommended check option

[Bzzzz]

On Wed, 10 May 2023 12:31:07 +0200
Boris Kirkorowicz <bkborg at kirk.de> wrote:

Hi,

> first, I tried with one of the smaller repos that were not affected:
> > # borg check --repository-only /mnt/rs1219a/usrlocal/
> > Failed to create/acquire the lock /mnt/rs1219a/usrlocal/lock
> > (timeout).
>
> It is the same with all repos. The repos are not encrypted. So I
> wonder what is meant with the failing lock. All I found was
> break-lock, and so I tried
>
> > # borg break-lock /mnt/rs1219a/usrlocal/
> > # borg -v check --repository-only /mnt/rs1219a/usrlocal/
> > Starting repository check
> > Local Exception
> > Traceback (most recent call last):
> >   File "/usr/lib64/python3.10/site-packages/borg/archiver.py", line
> > 5213, in main exit_code = archiver.run(args)
> >   File "/usr/lib64/python3.10/site-packages/borg/archiver.py", line
> > 5144, in run return set_ec(func(args))
> >   File "/usr/lib64/python3.10/site-packages/borg/archiver.py", line
> > 183, in wrapper return method(self, args, repository=repository,
> > **kwargs) File
> > "/usr/lib64/python3.10/site-packages/borg/archiver.py", line 343,
> > in do_check if not repository.check(repair=args.repair,
> > save_space=args.save_space, max_duration=args.max_duration): File
> > "/usr/lib64/python3.10/site-packages/borg/repository.py", line
> > 1026, in check self.save_config(self.path, self.config) File
> > "/usr/lib64/python3.10/site-packages/borg/repository.py", line 332,
> > in save_config secure_erase(old_config_path,
> > avoid_collateral_damage=True) File
> > "/usr/lib64/python3.10/site-packages/borg/helpers/fs.py", line 199,
> > in secure_erase with open(path, 'r+b') as fd: OSError: [Errno 5]
> > Input/output error: '/mnt/rs1219a/usrlocal/config.old'
                                               ^^^^^^^^^^
Apparently, you have a problem on the above file, very possibly a bad
sector which renders it unreadable, this might be bad for the rest of
the repo.

Copying a bad file often works (I just have had the case), but this
won't solve the main problem, as BB wants to read the bad one - at this
point, my contention is BB wants to read any existing file there.

This is a problem as it could have two origin: a random bad sector on a
big disk, which needs to be fixed before removing the file to avoid to
hit on a BB file in the future, or it can be your disk dying.

Anyway, you'll have to find and fix the bad sector correctly, to either
have it relocated or marked as bad in the FS.

So, fix the bad sector, copy the repo on another disk (where you'll run
the BB check) and do what's needed for the original disk (smart long
test and formatting in ext4 with destructive patterns, which can take
a looong time if the disk is big).

I don't know for the rest as I only use NFS, which have the advantage
of putting things on hold if the repo isn't available anymore (eg:
reboot for some reason) and takes back where it was when the repo is
back online.

Jean-Yves