hello Daniel,

thank you for your quick answer, I reply inline:

On 27.10.23 08:23, Daniel Sahlberg wrote:
Den fre 27 okt. 2023 kl 07:30 skrev Felix Natter <felix.nat...@sidact.com>:

    Dear svn experts,

    I do a daily dump+backup of my svn server. Without any known trigger
    (no server crash, except about 2 months ago I had a single I/O
    error on the
    ProxMox virtualization server), the dump of one repo failed with:

    svnadmin: E200046: LZ4 decompression failed

    The svnadmin verify I ran to double check that also failed for
    that one repo:

    verifying /repos/X/Y...
    * Error verifying repository metadata.
    svnadmin: E160004: Checksum mismatch in item at offset 18983705 of
    length 11921122 bytes in file /repos/X/Y/db/revs/0/221

    After I restored X/Y from the last backup, and ran a
    dump/backup/verify,
    everything is fine for 4 days now.

Good thing you did the dump/backup and verify steps!

Do I understand the issue occurred about a week ago, you restored the backup and now it has been working fine for the last 4 days? As compared with the known I/O error 2 month ago (ie, a lot earlier)?

Yes, the I/O error occurred earlier and did not have consequences for "svnadmin dump/verify".

With the current (4 days ago) corruption, I did not see any I/O errors. SMART is also green
(please see below).

    I couldn't find an error in the system logs (especially no I/O
    errors).
    The repos are on a HDD (in my experience they last longer than SSDs
    with lots of write activity, i.e. daily dumps/backups/etc...).

    Question: Can I rule out software failure?

It is difficult to rule out, but there are not many reports of this failure so I would guess it is more likely to be a corrupted bit of data on your HDD.
Ok, thanks.

    I am running svn 1.14.1
    on ALMA Linux 8.x. Shall I install on a new HDD?

You should probably check the SMART stats on the drive (on the virtualisation host!) or any other indications you might have on an upcoming failure to see if the HDD is indeed the issue.

I do not see a single problem in "smartctl -a /dev/sda" (I started a long test
with -t long earlier this week):

https://pastebin.com/7hi31CUg

But then I never identified a failing HDD using SMART...

Many Thanks and Best Regards,

Felix


    No action needed?
    Any other advice?

    Many Thanks in Advance and Best Regards,
    Felix


Kind regards,
Daniel Sahlberg

--

*SIDACT GmbH
Simulation Data Analysis and
Compression Technologies
*
*Felix Natter*
/Software Developer /

Auguststraße 29
53229 Bonn
Germany

Phone    :   +49 228 5348 0430
Direct   :   +49 228 4097 7118
Email    : felix.nat...@sidact.com
Web      : http://www.sidact.com/

Reply via email to