HBS3 Integrität Fehler MD5 Mismatch

  • Hi zusammen,


    ich hab Backup-Pläne, die auf externe Festplatten sichern.

    Insgesamt 4, von denen 2 jeweils Duplikate sind.

    Sprich Backup A1, A2 und B1 und B2.

    Dabei ist auch die Inhaltsprüfung aktiviert und bisher habe ich da auch nie eine negative Meldung erhalten.

    Nun ist aber bei einem Backup gemeldet worden, dass beschädigte Dateien am Ziel gefunden wurden mit der Begründung "MD5 Mismatch".


    Hatte in den Infos von QNAP geschaut und da steht nur, dass das NAS versucht die Dateien automatisch zu reparieren.
    Aber da sehe ich keine Meldung dazu ob das überhaupt passiert ist und falls doch, was davon das Ergebnis ist.

    Sprich Backup B1 meldet Dateiintegritätsfehler, aber B2 nicht obwohl da die selben Daten drin sind.
    Jetzt weiß ich nicht wie ich da weiter vorgehen soll/kann. Es gibt ja keinen Button, mit dem ich eine Reparatur manuell anstoßen kann.

    Welche Möglichkeiten habe ich, um die beschädigten Dateien im Backup zu reparieren?


    Danke schon mal :)


    EDIT:
    Der Bericht in CSV sieht so aus

    usw.

  • Welche Möglichkeiten habe ich, um die beschädigten Dateien im Backup zu reparieren?

    Hallo,

    vermutlich gibt es da keine Reparaturmöglichkeit.

    Du nutzt ja eine Versionierung, somit kann HBS3 nur die aktuelle Version reparieren. Die älteren Dateiversionen gibt es ja auf dem NAS nicht mehr.

    Datenintegritätsprüfung in HBS 3 | QNAP

    Anmerkung:

    Da nur ein Backupmedium betroffen ist, dürfte die Sicherungs-HDD ein Problem haben.

    Entweder die HDD mal neu formatieren oder gleich eine neue anschaffen.

  • Okay, dann werde ich die HDD mal prüfen, Backup nochmal komplett neu anlegen lassen und nochmal prüfen was beim Inhaltscheck rauskommt

    Wenn da was auffällig wird werde ich eine neue HDD anschaffen

    Danke für Antwort :)

  • Nein das ist einfach kacke programmiert.

    Habe ich zum Backup NAS auch, wenn ein Job mal nicht vollständig durch gelaufen ist, weil z.B. VPN unterbrochen wurde und in der Zeit dann was geändert wurde.

    Meist ist löschen das Problem, werden die dann als missing geführt, was aber nicht stimmt.

  • Ich hatte diese Meldung auch des öfteren. Das passierte hauptsächlich bei großen Dateien.

    Ich habe diese Dateien auch mit dem 2 BAckup verglichen, es gab nie einen Fehler in der Datei. Meine Lösung war, die Inhaltsprüfung abzuschalten. Wahrscheinlich hat Crazyhorse recht. :(

  • Hast du mal von Hand den MD5-Wert der Dateien ermittelt und verglichen?

    Gibt es da Unterschiede zwischen Ursprung & Backup?


    Mit MD5 kann man nix repararieren, nur feststellen, wenn irgendwo ein Bit (oder mehr;) sich verändert hat.

  • Ich werde die Tage mal schauen und den Vergleich der MD5 händisch machen.
    Muss mich dazu mal einlesen, hab ich noch nie gemacht.


    EDIT:

    eben für eine Datei geprüft

    MD5 Hash ist identisch

  • Wenn die MD5-Werte gleich sind, sind die Dateien identisch und die Platte ist i.O.

    Wenn HBS3 dennoch Unterschiede meldet, ist das ein Fall für's debugging / Fehlersuche / Support.

    Vielleicht weichen Dateiattribute (Zeit, Rechte o.ä.) ab und HBS3 gibt eine falsche Meldung aus?


    Im Zielverzeichnisbaum gibt es ein .md5-verzeichnis, dort sind die MD5-werte aller Dateien gespeichert. Den kann man evtl. mit den eigenen vergleichen. Kann grad den genauen Pfad nicht nachsehen; ich meine auf der Ebene von '.latest'.


    Wer etwas Ahnung von Linux & Python hat und Stacktraces lesen kann, kann in den ausführlichen HBS3-logs auf Suche gehen. Ob man fündig wird, ist vorher unklar.