Dateisystemfehler

[tuep]

Das ging jetzt schneller als erwartet.

Folgenden Output habe ich bekommen:

e2fsck -nvf /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create? no

Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(515769832--515769837)
Fix? no

Free blocks count wrong for group #15740 (10271, counted=10265).
Fix? no

Free blocks count wrong (113539396, counted=113539390).
Fix? no


1.41.12-2668: ********** WARNING: Filesystem still has errors **********


       88076 inodes used (0.05%, out of 182845440)
        2157 non-contiguous files (2.4%)
          51 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 86338/1709
   617842364 blocks used (84.48%, out of 731381760)
           0 bad blocks
         192 large files

       75676 regular files
       12363 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
          28 symbolic links (20 fast symbolic links)
           0 sockets
------------
       88067 files

Das scheint erst mal so auszusehen, als gäbe es keine Bad Blocks. Ich kann aber leider nicht viel damit anfangen. Wenn ich es richtig sehe, dann hat er sich bei den freihen Blöcken verzählt.

Was meint ihr. Könnte man guten Gewissens das Backup neu anlegen?

 

[tuep]

Gibt es vlt. ein passenderes Unterforum, in dem mir bei diesem konkreten Problem weiter geholfen werden kann ?

 

[Fusion]

Das ist ja nur ein Trockenlauf gewesen, da sämtlichen Reparaturen abgelehnt werden durch den Parameter -n. Um Fehler automatisch zu reparieren wäre es -pvf

 

[tuep]

Ich wollte erst mal schauen, was das Problem ist. Ich weiss ja nicht, wie heikel das ganze ist.
32,8757
Edit:

Zusammengefasst stehe ich jetzt vor dieser Situation.
Nach einem Absturz der DS habe ich Dateisystemfehler, sowohl auf der root Partition, als auch auf dem Volume1.
Nicht ganz klar formulierte Meldungen vor dem Ausführen des Integritätscheck des datenbankbasierten Backups, lassen mich an dessen Sichterheit zweifeln.

Jetzt bleibt die Frage was tun?

1) Auf das Backup einfach vertrauen -> DS platt machen -> Backup zurück spielen.

2) Versuchen das Filesystem zu reparieren -> Dann neues klassisches Backup machen -> und vlt. zur Sicherheit ebenfalls DS platt machen -> Backup zurück spielen.

3) Neues klassisches Backup machen -> Filesystem reparieren -> Falls keine Fehler mehr auf Volume1 Backup erneut anlegen -> DS platt machen -> Backup zurück.

Ich würde ja fast zu 3) tendieren. Aber ich bin kein Experte und traue mich das gerade nicht wirklich zu entscheiden.

 

[tuep]

Ich verstehe ja, dass man bei derartigen Problemen, nicht mit hundertprozentiger Sicherheit vorhersehen kann, was passieren wird. Und natürlich ist man dann vielleicht gehemmt, eine Empfehlung auszusprechen. Aber mir würde es schon fast reichen, wenn ich ein wenig Feedback bekommen könnte, was erfahrenere Nutzer machen würden, wenn sie in der selben Situation wären.

Das Wochenende hat gerade angefangen und ich hätte gerade für die Langwierigen Backupmaßnahmen und Neuinstallationen Zeit.

 

[Fusion]

Bei einem versionierten Backup welches bis vor das Fehlerereignis zurück reicht, würde ich 1) nehmen

 

[tuep]

Auch trotz dieser Meldung mit dem Integritätstest? Das verunsichert mich doch sehr.
Und dann auf die Version vor dem Crash zurückfallen?
Kann man dann auch die Daten, die danach dazugekommen sind, einzeln herstellen?

Ich weiß halt nicht, ob die Meldung bei dem Integritätscheck sich auf den Crash bezieht oder auf ein Problem von Hyper Backup selbst.

 

[Fusion]

Stell mal bitte dein DSM auf Englisch um, damit man den Originaltext dieser Meldung zur Integrität bekommt, die Übersetzung hat wohl gelitten.

 

[tuep]

Hat einen Moment gedauert.
Leider wirkt das auch nicht wirklich klarer.

 

[Fusion]

Ja, das ist wohl schon die erste aus dem chinesischen schief gegangen.
Ich würde den Test mal mit beiden Häkchen laufen lassen. Es werden weder Daten im Backup noch an der Quelle verändert dadurch.

 

[tuep]

Das ist die Aussage, die ich seit Tagen suche.
Ich werde dass dann jetzt starten.
Das dauert allerdings geschätzt bis Irgendwann Sonntag Abend. Oder gegebenenfalls sogar noch viel länger.
Ich weiß nicht, ob beide Prozesse zusammen erledigt werden oder es zwei Statusanzeigen geben wird.

Ich hoffe, dass Hyper Backup ein vernünftiges Protokoll anfertigt zu dem Test.
Ich werde das Ergebnis dann hier posten.

Wenn Hyper Backup sagt, alles sei gut, dann kann ich vermutlich wirklich einfach das Raid platt machen und das Backup zurück spielen.

Nochmal zur Klarheit bezüglich Systemeinstellungen.
Das Backup umfasst dafür nur soetwas wie eine config Datei, in der die ganzen Häckchen und Strings drin stehen und nicht ein image des Systems, oder?
Werden die Benutzereinstellungen und Freigaben Regelungen auch gespeichert?

 

[Fusion]

Die Sicherung der Konfiguration sichert nur Einstellungen, kein Abbild, korrekt. Welche das sind steht z.B. hier
https://www.synology.com/de-de/knowledgebase/DSM/help/DSM/AdminCenter/system_configbackup

Es ist mit aktuellen Mittel nicht möglich eine Komplettsicherung (DSM, Daten, Pakete und Einstellungen) einer DS zu machen.
Einen Großteil der DSM Einstellungen landet in der Konfigurationssicherung als .dss Datei bzw auch wenn man in Hyper Backup Jobs anlegt (glaube, das läßt sich gar nicht abwählen, aber da bin ich mir grad nicht mehr sicher).
Anwendungen und deren Einstellungen und teilweise Daten können über Hyper Backup gesichert werden.
Info hier: https://www.synology.com/de-de/knowledgebase/DSM/help/HyperBackup/data_backup_source

 

[tuep]

Ah ok vielen Dank. Das ist mir ehrlich gesagt auch lieber. Sonst holt man sich bestimmte Probleme vlt. gleich wieder mit an Bord.

Vlt. eine Ergänzung zu dem Integritätscheck.

Ich hatte folgende Fragen an den Support geschickt:

...
1) Ich habe letztens mein Backup aktualisiert und Ihnen in der letzten Mail ein paar Fragen zu Hyper Backup und der Integrität des Backups gestellt. Um das richtig einschätzen zu können, wäre es wichtig diese Funktion richtig zu verstehen. Ich kopiere meine Frage noch mal ans Ende der Mail.
....
Hier noch die Fragen der letzten Email.

Ich habe noch eine weitere Frage, die sich auf das Programm Hyper-Backup bezieht.
Ich habe nach reiflicher Überlegung noch mal das Backup aktualisiert. Ich bin davon ausgegangen, dass nur die zuletzt erstellten oder geänderten Daten aktualisiert werden, basierend auf den Metadaten der Datei. Falls unveränderte Daten beschädigt sind, werden diese nicht als geändert erkannt und folglich geschieht kein Abgleich mit dem Backup. Das war anscheinend korrekt und nur die neuen Daten wurden auf dem Backup ergänzt.

Eine einfache Lösung für das Problem wäre für mich, nun einfach die DS neu zu installieren und das Backup zurück zu spielen. Jetzt gibt es in Hyper Backup die Funktion die Integrität des Backups zu prüfen. Wenn ich das jetzt durchführe gibt es im Prinzip drei Fälle. Der beste wäre, die Daten auf der DS sind nicht beschädigt und identisch zum Backup. Was passiert jedoch, wenn ein Problem festgestellt wird. Es gibt dann zwei mögliche Fehlerquellen. Entweder eine Datei auf dem Backup oder auf der DS ist nicht mehr korrekt. Erstens, wie wird das erkannt und zweitens erkennt Hyper Backup, ob der Fehler auf dem Backup oder der DS liegt? Wird dann sofort automatisch eine Änderung am Backup vorgenommen oder wird erst mal nur eine Diskrepanz festgestellt und man hat die Möglichkeit sich zu entscheiden, was man tut?

Daraufhin kam folgende sehr Knappe Antwort zurück.

Abgleich der Dateien mit Hilfe der Prüfsummen.
Welche Korrekt ist, weist das DSM nicht.
Es erzeugt einfache eine neue Version im Backup.

Ich habe allerdings die Vermutung, dass er damit das Backup an sich meint.
Leider hat der gute Mann etwas Probleme mit der Schriftsprache und drückt sich sehr knapp und unpräzise aus.

 

[tuep]

So, Check ist durchgelaufen.
Ganz großes Kino.

Im Log steht zwei mal direkt hintereinander ein Error (vermutlich wegen den beiden Checkboxes) mit der Nachricht:

[Local][Local Storage 1] Backup integrity check is finished. The backup target is found broken.

Im Hyper Backup steht bei der Backup Aufgabe jetzt ein roter Kreis mit Ausrufezeichen und der Meldung Crashed. Das Kontextmenü bietet nur noch die Option "Delete".

Jetzt bleibt mir vermutlich nur noch die Option 3) von meiner letzten Auswahl, oder?

Ich glaube das datenbankbasierte Backup ist für mich für die Zukunft gestorben. Das hätte ich ehrlich gesagt nicht im Traum erwartet.

 

[tuep]

Falls es für das Problem hilft:
Ich habe mich bereits halb dazu entschlossen meine DS in Zukunft durch eine DS216+II mit zwei neuen Festplatten zu ersetzen.
Eventuell erweitert das die Auswahl an sinnvollen Möglichkeiten.

Unabhängig davon ist es, denke ich, trotzdem gerade für mich unverzichtbar zu einem vernünftigen Backup zu kommen.

Und noch eine Anmerkung. Vom Speicherplatz ist meine externe so groß, dass auch zwei Backups hinpassen.

 

[Fusion]

War das eigentlich ein internes Backup innerhalb der DS?
Das wäre dann das Paradebeispiel (Stromausfall) der Daten und Backup schädigen kann.
Ich weiß, ist jetzt keine Hilfe.
Ich versuche immer mindestens 2 Backups außerhalb der DS zu haben mit verschiedenen Programmen oder mindestens unterschiedlichen Sicherungsmethoden.
Im Idealfall ist eines davon noch außerhalb der Wohnung und das zweite stromlos zur Lagerung.

Ja, würde alles worauf du zugreifen kannst nochmal anderweitig sichern und dann neu aufsetzen.

 

[tuep]

Nein natürlich nicht.
Ist eine externe Platte in ner IcyBox.

Wenn ich die aktuelle DS verkaufe, behalte ich auch eine der internen Platten als Freeze der aktuellen Daten, was ich vlt. in nem Jahr dann mal aktualisiere.

Also meinst du Lösung 3 von der vorherigen Seite? Lohnt es sich das noch mal mit dem Filesystem reparieren auszuprobieren?

An sich ist mir bis jetzt noch keine Datei aufgefallen, auf die ich nicht zugreifen kann. Im DSM wird mir auch angezeigt, dass alles gut sei, abgesehen von den Meldungen im Sicherheitscenter. Auch eine sehr komische Sache. Wenn ich die ergebnisse vom FS check richtig verstehe ist auf Volume 1 vor allem das Problem, dass eine Unsicherheit bezüglich der freien Blöcke besteht.

Soll ich die externe auch formatieren, oder lieber das Kaputte Backup daneben behalten?

Edit:
Ich habe vorhin auch hier gesehen http://www.synology-forum.de/showth...ntegritätscheck-Backup-target-is-found-broken das es scheinbar Probleme damit gibt. Leider kann man wohl nichts anderes machen, als es neu anzulegen.

Ich werde aber auf jeden Fall einen Bogen um diese Funktion machen und lieber Datenkopie Backups anlegen. Das hätte ich wirklich nicht erwartet und finde das ist echt fahrlässig sowas anzubieten, wenn da solche Bugs auftauchen und bekannt sind.

 

[Fusion]

Wenn die Verwaltungsinformationen für das externe Backup hinüber sind kannst du daraus auch nichts mehr wiederherstellen. Von daher kann man das auch löschen.

Eine neue Datenkopie würde ich jetzt auf jeden Fall anlegen.

Danach kannst du die Reparatur ja mal probieren, dürfte vom Zeitaufwand ja das geringere Übel sein.
Oder du läßt halt man den Support dran.

 

[tuep]

Ob das wirklich beschädigt ist, oder ob der Check einfach nicht funktioniert ist evtl. nicht ganz klar.
Siehe den Thread. Wenn ein gerade angelegte Backup nicht funktioniert, scheint da was im Argen zu sein.

 

[Fusion]

Welcher Check? Die Prüfung von Hyper Backup ob seine Index Dateien intakt sind und eine Wiederherstellung möglich ist?
Wieso sollte der nicht funktionieren?
Die externe Platte war auch vom Stromausfall betroffen (also angeschaltet)?

In dem anderen Thread geht es um Backups auf Amazon, ist also schon mal nicht identisch mit deinem Problem (andere Softwareteile), auch wenn in beiden Fällen Hyper Backup im Einsatz ist.