Integritätsprüfung / Datensynchronisation hängt bei 33%

[queermeet]

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
ja

Server-Betriebssystem + Version
Debian 12.13

Eingesetzte Server-Virtualisierung-Technologie
KVM


KeyHelp-Version + Build-Nummer
26.0 - Build 3618


Problembeschreibung / Fehlermeldungen

Integritätsprüfung / Datensynchronisation hängt seit 20 Minuten bei 33%

Ich habe 2 repositories und nur eines der beiden hat dieses Problem.

Ich habe den Server auch schon neu gestartet und dann wird mir angezeigt, dass bei einem Nutzer eine anstehende Backup Operation ist und die mit dem Neustart abgebrochen wird, aber auch nach dem Neustart ist die Datensynchronisierung weiterhin vorhanden und bei 33 %


Auch die Problembehandlung hilft nicht


Erwartetes Ergebnis

sollte schnell durchlaufen so wie bisher auch




backup log ist auch nicht hilfreich, da ist der letzte Eintrag von heute 9 Uhr

[2026-04-24 09:00:02] INFO | Prepare backup...
[2026-04-24 09:00:02] ERROR | Failed to prepare database "clipboard": mysqldump: Got error: 1049: "Unknown database 'clipboard'" when selecting the database
[2026-04-24 09:00:03] ERROR | Failed to prepare database "wordpress_internes_wiki": mysqldump: Got error: 1049: "Unknown database 'wordpress_internes_wiki'" when selecting the database
[2026-04-24 09:00:08] INFO | Backup created
[2026-04-24 09:00:08] INFO | Cleanup
[2026-04-24 09:00:08] INFO | Operation found: check
[2026-04-24 09:00:08] INFO | Integrity check
[2026-04-24 09:00:51] INFO | Update snapshot data / stats
[2026-04-24 09:00:56] INFO | Update repository stats
[2026-04-24 09:01:00] INFO | Size 'raw': 730.90 MiB
[2026-04-24 09:01:00] INFO | Size 'restore': 7.60 GiB
[2026-04-24 09:01:01] INFO | All finished, releasing lock.

[Florian]

Was heißt schnell? Hast du geschaut ob die restic Prozesse noch laufen? Wenn da viele Snapshots drin sind kann es dauern.

[queermeet]

Was heißt schnell? Hast du geschaut ob die restic Prozesse noch laufen? Wenn da viele Snapshots drin sind kann es dauern.

Ich habe gerade mal durchgeschaut, die Datenbank macht einmal in der Stunde ein Backup, also hab ich gute Referenzdaten

Um beispielsweise 10:00:01 startet das Backup, um 10:00:08 ist es fertig und die Synchronisierung startet, paar Sekunden später ist auch die fertig.

734,13 MiB ist die Größe des Repositories bei 905 Snapshots, aber bis heute um 13:00 Uhr war noch alles schnell

Ich habe gerade mal als Admin geschaut und ich habe in den aktuellen Prozessen restic nicht gefunden, aber auch wenn ich versuche, eine neue Synchronisierung anzustoßen, passiert nichts

[queermeet]

Das System hat jetzt die Operation abgebrochen und schon wieder geplante Backups ausgeführt

[Tobi]

Bei 905 Snapshots dauert die Integritätsprüfung länger als die eigentliche Sicherung.
Interessant wäre auch die „entpackte Größe“ deines Repositorys.

Warum überhaupt so viele Snapshots?

[queermeet]

Bei 905 Snapshots dauert die Integritätsprüfung länger als die eigentliche Sicherung.
Interessant wäre auch die „entpackte Größe“ deines Repositorys.

Warum überhaupt so viele Snapshots?

Kann ich die entpackte Größe irgendwo sehen? Auf der Oberfläche steht 774,17 MiB.

Ich hab tatsächlich bisher noch keine Begrenzung für die Snapshots gesetzt, weil ich am Anfang noch nicht wusste, was dann passiert.

Seitdem hab ich nicht mehr drüber nachgedacht, um ehrlich zu sein.

Und ehrlich gesagt hab ich auf meinem Backup Speicher aktuell so viel Speicherplatz frei, dass es mich nicht mal interessieren würde, wenn die Datenbanken 500 GB in Anspruch nehmen würden.