DSM 6.x und darunter Checksum mismatch on file in @sharesnap

[K_T_]

Hallo,
wir haben zwei RS2416RP+ als high-availability-cluster. DSM 6.2.2-24922 Update 4.
Mit SSD-Cache und vier Seagate Ironwolf SATA HDD als Raid 5 mit btrfs.
Ich bekomme sporadische Meldungen das die Checksumme von Dateien im Ordner @sharesnap nicht stimmt. zB. /volume1/@sharesnap/Statik/GMT+01-2020.01.13-20.00.13/StatikMB/RowaSoft Datenbank/DAT/winorte.dat.
Es gibt zwar den Ordner /@sharesnap/Statik er enthält aber nicht die angegebenen Ordner.

Es gibt keine Snapshots oder Replications, es sind auch keine geplant.

Weiß jemand warum diese Meldungen kommen?

Gruß
Klaus

 

[funzel1607]

Hallo,
ich habe das gleiche Problem auf einer 918+. Allerdings nur 4x 4TB WD Red verbaut.
Der Fehler taucht immer dann auf, wenn HyperBackup auf externe USB HDD oder via Netzwerk auf eine DS213+ schreibt.

 

[K_T_]

Hi,
richtig, taucht immer nach einer Sicherung mit Hyperbackup auf externe USB HDD auf. Der monatliche Health Test ist normal.
Es werden Checksummenfehler angezeigt für Dateien die nicht existieren sollten.

WD Red 4 TB hatte ich auch 14 Monate lang. Die haben sich aber ständig, in 2-6 Wochen Intervallen, aus dem Raid Verbund verabschiedet. Auf dem aktiven und dem passiven Server. Manche mehrfach hintereinander, manche nur einmal aber ohne Ausnahme. Nachdem ich auf Ironwolf gewechselt habe ist Ruhe.

Vieleicht bringt ja noch jemand was in Erfahrung, danke.

 

[roben]

Hi,
richtig, taucht immer nach einer Sicherung mit Hyperbackup auf externe USB HDD auf. Der monatliche Health Test ist normal.
Es werden Checksummenfehler angezeigt für Dateien die nicht existieren sollten.

WD Red 4 TB hatte ich auch 14 Monate lang. Die haben sich aber ständig, in 2-6 Wochen Intervallen, aus dem Raid Verbund verabschiedet. Auf dem aktiven und dem passiven Server. Manche mehrfach hintereinander, manche nur einmal aber ohne Ausnahme. Nachdem ich auf Ironwolf gewechselt habe ist Ruhe.

Vieleicht bringt ja noch jemand was in Erfahrung, danke.

Ich habe das gleiche Problem (Die Meldungen tauchen bei mir erst seit dem Wechsel von DSM 6.2.4 nach DSM 7.01 auf) und wollte das Thema nochmal beleben. Hat jemand eine Ursache/Lösung dafür gefunden? Kennt Synolgoy das Verhalten?

 

[funzel1607]

Synology rät die Daten wegzukopieren, das Volume zu löschen und mit ext4 neu aufzusetzen. Dann wieder alle Daten zurück... Seitdem habe ich keine Probleme mehr.

 

[roben]

Synology rät die Daten wegzukopieren, das Volume zu löschen und mit ext4 neu aufzusetzen. Dann wieder alle Daten zurück... Seitdem habe ich keine Probleme mehr.

D.h. das Hyper Backup nur mit ext4 volumes richtig zusammenarbeitet? Das find ich bisschen heftig. korrumpiert das Hybid-raid (shr) daten? Dann müsste ich mit USB copy alles sichern, das volume löschen, neu anlegen und alle freigegebenen ordner wieder neu einrichten, mit berichtigungen und allem drum und dran?

 

[funzel1607]

Mir wurde seitens des Synology Supports allgemein von Btrfs abgeraten... Traurig aber wahr. Scheint kein explizites Hype Backup Problem zu sein.

 

[roben]

Ok. Ich hab das jetzt auf ext4 umgestellt, ich meld mich mal nach dem ersten Hyper Backup inklusive Ingegritätsprüfung...

 

[roben]

Seit der Umstellung auf Ext4 keine Probleme mehr. Backups laufen durch. Integritätsprüfung auch. Das ist für mich ein Armutszeugnis für das BTRFS filesystem….

 

[Apropo]

Ich habe auch das Problem. Aber auf Ext4 zu gehen kann ja nicht die angestrebte Lösung sein. Ich benutze VM´s und dafür wird BTRFS benötigt. Gibts da inzwischen was neues zu?