Frostregen

Hi Thomas, first of all thanks a lot for your quick replies and suggestions! ### borg always sequentially goes over the full archive Thank you for confirming! Yes this was...

SIGUSR1 did not seem to print anything, but SIGUSR2 dumped this: ``` Received SIGUSR2 at 2024-02-07 08:59:29, dumping trace... Current thread 0x00007f481c115000 (most recent call first): File "/usr/lib/python3/dist-packages/borg/archiver.py", line 5049...

I already cancelled the slow `borg extract /sub/folder` now. Currently I moved the clientside `.config/borg` to the server and run the `borg check --verify-data --repair --progress ` locally. Let's see...

### Update The full repair seems to have done something this time: ``` This is a potentially dangerous function. check --repair might lead to data loss (for kinds of corruption...

Luckily this specific file we can restore from another source, so this is fine. The critical point / file in borg extract has been passed, so I'm positive the rest...

As reported the specific corrupted file has been passed (around 21% of full extract). My current issue is, it is getting extremely slow again. Meaning it sits at 33% for...

I checked the RAM usage (and the journalctl logs, for any OOM-Killer invocation), but it seems completely fine. As you can see from the previous image, RAM usage is somewhere...

Just as an update: It is currently at 77%. The finish line gets into sight :crossed_fingers: I still do not have a good explanation for that behavior. Inspecting the kernel...

For the record: - It got stuck again at 78.1% for more than 3 weeks (and never finished, as another approach finished first) During that time I followed the kernel...

I tested 2 times with kernel 5.15, and also multiple times with 6.5 with the same behavior, so I'm pretty positive it is related to this. According to the second...