[Borgbackup] recommended check option

[Bzzzz]

On Wed, 10 May 2023 16:51:40 +0200
Boris Kirkorowicz <bkborg at kirk.de> wrote:

Hi,

> >>> "/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.
> 
> that seems not to be the case, since I can read it using cat and edit
> it using vi. The error remains the same. The text file contains some
> info about the repo:
> > [repository]
> > version = 1
> > segments_per_dir = 1000
> > max_segment_size = 524288000
> > append_only = 0
> > storage_quota = 0
> > additional_free_space = 0
> > id =
> > 180ba330d0a627f2259f0ec4132fef7a45d135cf774b6c41ec75755744d5bdf9

As I told you, the FS can say it can't read the file while you can
still manually copy it - I has this case 3 days ago with /boot/intrd…
declared unreadable, but when I manually copied it, there was no problem
(I rename the original one BAS_SECTOR and my copy the original name and
that was it, but it has no importance if it dies fast, as this HD is 10
yo).

> Could the error be that e.g. the id string is wrong, or something
> similar?

I don't think so (but I'm not sure, so Thomas may have the last word
about that), if it was that, the logic says it would complain another
way (such as: 'id' seems to be bad, did you cut the blue wire???)
 
> > 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.
> 
> The disks are brand new, initialized using ext4 just before running
> borg.

Yeah, but HOW did you "initialized" them?

Did you: mkfs.ext4 -cc … ?
Which formats disk(s) while performing a multi-patterns write/read (at
least 4 IIRC) in order to reallocate/mark bad sectors if found.

If disks have evolved, there is one of their spec that did not: the BER
(Binary Error Rate), it is at the same level it was with 40/80 GB
disks, so the chance you find bad sectors on big disks is very high.

ZE problem is, it is veeery looong, as it:
* writes the whole partition with the same pattern,
* reads the whole partition to see if there is/are error(s),
and loops on to the next pattern.

IIRC, the last disk I format with this option was a 3TB 7500RPM which
took something like 38 hours to achieve this kind of formatting…

> > 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).
> 
> AFAICS it applies to all repos. The backup took about four months to 
> complete, so formatting would not be that significant. So I hope that 
> the cause is something different and it could be repaired by another
> method.

It's your data, thus your ass Cochise ;-p)

To be clear, if it was for myself, home data I don't really care as the
important things have 2 different BB repos separated from the rest, but
if it was professional data, I certainly wouldn't leave it this way,
too much risks for a breakdown.

Also note that if it is pro, there is a big bottleneck somewhere, seeing
the time the 1st backup took, so the choice initially made probably may
not be the best.

Jean-Yves