Ordnerinhalte verschwinden

[erix]

Hallo Gemeinde,

ich betreibe seit geraumer Zeit recht zufrieden eine DS1010+ (DSM 4.0)mit vier 2TB Platten. In erster Linie benutze ich sie zum Backup meiner Fotos und als Datenspeicher für meine Audiodateien (Flac) auf die ich wiederum mit einer Squeezebox zugreife. Ab und an lasse ich den Logitech Media Server nach neuen und veränderten Mediafiles suchen, um die Neuzugänge verfügbar zu machen. Soweit das Procedere seit Jahren.
Vor gut einer Woche hing sich der Logitech Media Server beim Scan auf, daraufhin habe ich beschlossen, einen kompletten Rescan der Medienbibliothek zu machen. Das war keine gute Idee, denn diese kam nie zu einem Ende und damit ist meine Musik nicht mehr für die Squeezebox verfügbar. Bei genauerem Hinsehen stellte sich heraus, dass der Scan immer an der gleichen Stelle abbricht (Ordner "xy"). Daraufhin habe ich die Platte gemountet und siehe da, der Ordner "xy" hat keinen Inhalt (hatte er aber früher). Nachdem ich den (leeren Ordner) aus dem zu scannenden Verzeichnis verschoben hatte, geht der Scan auch eine Weile weiter - bis zum nächsten leeren Ordner. Mittlerweile habe ich auf diese Art schon eine halbes Dutzend verschwundener Alben lokalisiert und frage mich, woran das liegen könnte? Wohin und auf welche Art verschwinden die Files?
Ich habe heute einen doppelten Reset gemacht und die Firmware 4.1 aufgespielt. Schon wieder leere Ordner gefunden, sonst läuft alles bestens. Gibt es ein Tool im System, mit dem ich die Integrität der Daten prüfen kann? Langsam mache ich mir Sorgen über den schleichenden Verlust (verschwundene Fotos sind mir noch nicht aufgefallen - aber wer weiss, ist halt das Backup, ich arbeite nicht mit ihnen.

Herzlichen Dank für Eure Ideen, erix

 

[Zentris]

Hallo...
du hast aber schon verstanden, dass deine NAS Station kein Backup darstellt?(!!)

Die DS (hast du deine Platten als Raid laufen?) ist ein schneller und relativ sicherer Ablageplatz der Daten.
Von diesem Ablageplatz solltest du, wenn dir an den Daten was liegt, ab und zu ein mindestens 1 (richtiges) Backup auf ein externes System/externe Platte machen und diese räumlich von der DS entfernt lagern.

U.U. hat ein Plattenfehler deine Daten gerade gefressen...

die Zentris

 

[erix]

Ich weiss was Du meinst und man kann es gar nicht oft genug sagen, ein frühes Backup erspart später das Geheule (ich habe jetzt natürlich kein aktuelles zur Hand, gelobe aber Besserung) - doch darum geht es mir ja im Moment gar nicht. Ich finde es nur ärgerlich, dass der Datenverlust (und um einen solchen wird es sich wohl handeln) so getarnt vor sich geht. Keine Meldung des Servers, kein Hinweis auf eine Fehlfunktion. "Ihre Diskstation funktioniert einwandfrei" Na super! Die Situation hat sich jetzt etwas verschärft, ich kann den leeren Ordner (Unterordner bleiben übrigens auch immer erthalten, nur die eigentlichen Dateien verschwinden), an dem der Medienscan hängt, nicht mehr bewegen bzw. löschen. Nicht per Filestation, nicht per drag and drop der gemounteten Partition. Es gibt auch keine Fehlermeldung beim Kopierversuch, es tut sich bloss nichts. Neustart hilft auch nicht. Ich habe jetzt erst einmal alle Scanvorgänge abgebrochen, um nicht noch weitere Fehler zu provozieren. (Werde mich mal um Platten für ein Backup kümmern, allerdings kann mir das System den Speicherbedarf aktuell nicht ansagen "NaN GB. undefined Datei(en), undefined Ordner enthalten" - vermutlich ist es dafür jetzt zu spät ;-))

 

[itari]

Du schreibst, dass du ein Backup auf die DS machst? Wie denn? Kann es sein, dass dir deine Backup-Software die Verzeichnisse löscht?

Itari

 

[erix]

Nein, ich kopiere die Dateien per Hand (meine Bildverwaltungssoftware (lightroom) legt nach dem Import der Fotos nach Datum geordnete Verzeichnisse auf meinem Rechner an, die ich dann von Zeit zu Zeit auf die Discstation rüberschiebe - und zwar ins Verzeichnis "photos", während die Flacs im Verzeichnis "music" wohnen. Übrigens die Verzeichnisse, die von der DS selbst angelegt wurden.
Ich habe gerade neue Platten für meine alte CubeStation CS407 geordert, um ein Backup zu fahren. Ich fürchte bloss, mit dem zerschossenen Filesystem wird das nix …

 

[Zentris]

Ich habe meine Fotos und die Musikfiles in gesonderten Verzeichnissen auf der DS (nicht "photo" und nicht "music").

Was ich dann per DNLA bereitstellen will, kopiere ich explicit in die "photo" bzw. "music" Verzeichnisse.
Ja, ich weiss: Damit "verschwende" ich Plattenplatz, weil die Daten dann doppelt vorhanden sind.

Hintergrund:
Ich glaube mich zu erinnern, dass ich hier im Forum schon mehrfach von dem Phänomen gelesen habe, dass der Medienindexierungsdienst der DS manchmal Files "frißt"...
Aus diesem Grund leiste ich mir eine strikte Trennung zwischen "Ablage" und "DNLA Freigabe".

Scheinbar hat der Dienst wieder "zugeschlagen"

die Zentris

 

[erix]

Ich habe mal gesucht aber solche Postings auf die Schnelle nicht im Forum finden können. Das klingt jedenfalls recht mysteriös und ist definitiv beunruhigend. Das perfide ist doch, dass mich vor solch einem Verhalten auch ein Backup nicht schützt. Da werden dann einfach die leeren Ordner "gesichert" und die ehemals vollen im vorhergehenden Backup überschrieben. Und ich als Nutzer merke davon gar nichts, weil keinerlei Fehlermeldung erfolgt (logisch - fürs Backup gab es ja auch keinen Fehler- fürs Filesystem schon, aber das übergeht großzügig diesen Punkt). Hätte ich nicht einen kompletten Rescan via Logitech Media Server angeschoben, wäre mir bis heute ja auch gar nichts aufgefallen. Da meine Musiksammlung etwas größer ist, kann ich unmöglich jedes einzelne File im Auge behalten (geschweige denn regelmäßig hören) - beängstigend, wenn sich das System in dieser Form verselbstständigt - das hieße ja in der Konsequenz, all die tollen Features von Synology besser deaktivieren und auf Lösungen von Drittanbietern setzen (die merken wenigstens, wenn eine Inkonsistent der Daten auftritt). Ich mag gar nicht an meine Bilder auf der Diskstation denken, …

Verwirrt, erix

 

[Zentris]

... auch ein Backup nicht schützt. Da werden dann einfach die leeren Ordner "gesichert" und die ehemals vollen im vorhergehenden Backup überschrieben. Und ich als Nutzer merke davon gar nichts, weil keinerlei Fehlermeldung erfolgt (logisch - fürs Backup gab es ja auch keinen Fehler- fürs Filesystem schon, aber das übergeht großzügig diesen Punkt)

Wie immer: Kommt drauf an... (auf deine Backup-Strategie)

Üblich:

1. Vollbackup, dann incrementelle Backups.
Dabei bleibt alles erhalten, die leeren Ordner würden zwar als leere Ordner gespeichert, aber das ist egal...

Wenn jetzt ein Restore erfolgen muß, passiert folgendes:
Vollbackup legt alle Files an, die bis dahin da waren,
Einspielen der incrementellen Backups ergänzt die seit dem Vollbackup hinzugekommenen Files
Gelösch wird nix !
​

Jetzt hängt es von deiner weiteren Strategie ab:

• Wieviel incrementelle Backups machst du vor dem erneuten Vollbackup (Das nächste Vollbackup würde die inzwischen gelöschen Files _natürlich_ nicht mehr enthalten!!)
• Hebst du die Vollbackups + incrementelle Backups auf, wenn ja, wieviel Generationen?

... Ich mag gar nicht an meine Bilder auf der Diskstation denken, …

*Mut zusprech* : Hast du die vielleicht doch noch irgendwo rumliegen? Auf 'ner USB Platte... da hinten !!!

die Zentris

 

[itari]

Ich glaube mich zu erinnern, dass ich hier im Forum schon mehrfach von dem Phänomen gelesen habe, dass der Medienindexierungsdienst der DS manchmal Files "frißt"

hab ich bislang nicht gelesen bzw. keine validen Fehlerfunde zu dem Thema gesehen. Wenn das jemand gehabt hätte, dann hätte er/sie es dem Synology-Support sicherlich gemeldet und hier im Forum eine größere Diskussion ausgelöst. Dass Daten verschwinden wäre höchst mysteriös ... außer es liegen Platten- oder Hardwarefehler vor ... oder halt durch menschliche Fehlleistungen ... ansonsten: eine NAS, die ihre Daten irgendwie verliert, dürfte man nicht ernsthaft betreiben (wollen)

Itari

 

[Zentris]

... auf die Schnelle mal gesucht, ist nicht nur der eine Beitrag...
Naja, hier ist z.B. so etwas in der Art erwähnt worden (Bilder waren beschädigt, wobei letztlich nicht schlüssig geklärt wurde, woher die Beschädigung stammt..., nur Vermutungen... )

http://www.synology-forum.de/showth...er-Zeit-defekt&p=240999&viewfull=1#post240999

Ich gehe mal grundsätzlich davon aus, dass keine Software fehlerfrei ist (wenn es so scheint, hat man nur nicht richtig gesucht)...

Insofern sollte man die Datenablage von wirklich wichtigen Daten (die Wichtigkeit liegt natürlich immer im Ermessen des Anwenders) auf einem NAS (Hersteller unerheblich) immer kritisch sehen: Wo immer aktive Prozesse auf die Platten zugreifen, die die Daten beinhalten, können Fehler auftreten die das Dateisystem korrumpieren.

Da die DS beim Indexierungsprozess (zwar lesend) auf den Medienpfad /photo zugreift und die Thumbnails zurückschreibt, ist hier potentiell die Gefahr, dass da was schiefgeht größer als bei reinem Lesebetrieb.

... wollt ich ja nur mal gesagt haben

die Zentris

 

[erix]

nun ja, die Diskussion gleitet etwas ins Theoretische ab, während ich den Eindruck habe, hier meiner DS beim Sterben zuzusehen. Neueste Entwicklung ist, das ich nicht mehr auf die DS zugreifen kann. Weder per http noch anderweitig. Allerdings gibt es keine Meldung, dass der Server nicht mehr erreichbar ist, sondern der Verbindungsversuch dauert einfach ewig. Festplattenaktivität ist keine mehr zu registrieren, das Lämpchen Status leuchtet grün, Lan1 blinkt aller 60 sec einmal müde. Das ist nicht gut …

 

[itari]

Das mit der Beschädigung von Fotodateien verfolge ich auch sehr aufmerksam; bislang sind allerdings dabei keine Dateien oder Ordner verloren gegangen (wenn ich das richtig verfolgt habe). Natürlich ist die Aussage richtig, dass Software nicht unbedingt immer fehlerfrei ist ... allerdings kann man trefflich streiten, was ein Fehler ist oder ob ein System nur herumzickt ... aber zurück zum eigentlichen Thema: eine NAS dient dem Speichern von Informationen und wenn das nicht gewährleistet ist, dann wäre dies eine ernsthafte Krise der Herstellers und die vermag ich nicht zu sehen.

Und natürlich kann auch eine DS bzw. ihre Hardware, ihr Dateisystem oder ihre Platten sterben, deswegen geben wir uns alle ja die Mühe, Backups ohne Ende zu machen, damit die Folgen gering bleiben. Um genauer festzustellen, was auf der DiskStation los ist, wäre eine Analyse der SMART-Werte der Platten und des Systemprotokolls (more /var/log/messages) sinnvoll; alternativ kann sich auch der Synology-Support die DS anschauen (Link in meiner Signatur).

Itari

 

[erix]

So, ich konnte es nicht lassen und habe versucht, die eingefrorene DS runterzufahren. Ging erst nach (gefühlten) minutenlangen Drücken der Powertaste. Immerhin musste ich nicht den Netzstecker ziehen. Starten ging soweit problemlos bis auf "System booted up from an inproper shutdown". Ich habe alle für mich erreichbaren Dienste gestoppt, trotzdem sägen die Platten was das Zeug hält. SMART Status ist OK, das Systemprotokoll übersteigt mein Laienwissen. Das was nicht stimmt, ist aber offensichtlich. Ich häng es mal an (und hoffe, dass dies nicht den Forumregeln widerspricht). Irgendwelche Tipps?

Danke, Erik

DiskStation login: admin
Password: 
login: can't chdir to home directory '/var/services/homes/admin'


BusyBox v1.16.1 (2012-07-09 20:14:50 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

DiskStation> more /var/log/messages
Jul 13 23:32:45 kernel: [ 1124.501552] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:32:50 kernel: [ 1129.816146] __ext4_check_dir_entry: 2355 callbacks suppressed
Jul 13 23:32:50 kernel: [ 1129.823563] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:32:50 kernel: [ 1129.914116] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:32:50 kernel: [ 1129.942757] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: comm perl: path (unknown): bad entry in directory: rec_len is smaller than minimal - offset=512(512), inode=0, rec_len=0, name_len
Jul 13 23:32:51 kernel: [ 1130.007970] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:32:51 kernel: [ 1130.125563] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: comm perl: path (unknown): bad entry in directory: rec_len is smaller than minimal - offset=512(512), inode=0, rec_len=0, name_len
Jul 13 23:32:51 kernel: [ 1130.246286] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:32:51 kernel: [ 1130.293485] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:32:51 kernel: [ 1130.339409] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:32:51 kernel: [ 1130.428293] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:32:51 kernel: [ 1130.450191] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:32:57 kernel: [ 1136.513483] __ext4_check_dir_entry: 1790 callbacks suppressed
Jul 13 23:32:57 kernel: [ 1136.584064] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:32:57 kernel: [ 1136.606106] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:32:57 kernel: [ 1136.903185] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:32:57 kernel: [ 1136.926304] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:32:57 kernel: [ 1136.948249] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:32:58 kernel: [ 1137.018809] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:32:58 kernel: [ 1137.040780] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:32:58 kernel: [ 1137.105706] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:32:58 kernel: [ 1137.127846] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:32:58 kernel: [ 1137.149554] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:02 kernel: [ 1141.747895] __ext4_check_dir_entry: 2590 callbacks suppressed
Jul 13 23:33:02 kernel: [ 1141.812842] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:02 kernel: [ 1141.841231] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:33:03 kernel: [ 1141.981967] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:03 kernel: [ 1142.003520] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:03 kernel: [ 1142.092697] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:03 kernel: [ 1142.114296] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:33:03 kernel: [ 1142.220156] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:03 kernel: [ 1142.321988] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:33:03 kernel: [ 1142.354577] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:03 kernel: [ 1142.426574] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:07 kernel: [ 1146.888880] __ext4_check_dir_entry: 2390 callbacks suppressed
Jul 13 23:33:07 kernel: [ 1146.941227] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:08 kernel: [ 1146.997421] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:08 kernel: [ 1147.018989] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:08 kernel: [ 1147.089922] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:08 kernel: [ 1147.119646] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:33:08 kernel: [ 1147.141178] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:08 kernel: [ 1147.162639] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:08 kernel: [ 1147.184288] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:08 kernel: [ 1147.205985] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:08 kernel: [ 1147.230748] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:13 kernel: [ 1152.024161] __ext4_check_dir_entry: 2390 callbacks suppressed
Jul 13 23:33:13 kernel: [ 1152.115282] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:13 kernel: [ 1152.152739] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:13 kernel: [ 1152.177726] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:33:13 kernel: [ 1152.204600] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:13 kernel: [ 1152.226220] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:13 kernel: [ 1152.283067] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:13 kernel: [ 1152.304782] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:13 kernel: [ 1152.326289] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:13 kernel: [ 1152.392709] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:13 kernel: [ 1152.417335] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:18 kernel: [ 1157.137174] __ext4_check_dir_entry: 2477 callbacks suppressed
Jul 13 23:33:18 kernel: [ 1157.177243] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:33:18 kernel: [ 1157.198841] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:18 kernel: [ 1157.294840] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:33:18 kernel: [ 1157.316454] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:18 kernel: [ 1157.387634] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:18 kernel: [ 1157.409117] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:18 kernel: [ 1157.472799] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:18 kernel: [ 1157.494897] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:33:18 kernel: [ 1157.516639] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:18 kernel: [ 1157.572348] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:23 kernel: [ 1162.253264] __ext4_check_dir_entry: 1703 callbacks suppressed
Jul 13 23:33:23 kernel: [ 1162.260264] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:23 kernel: [ 1162.307838] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:23 kernel: [ 1162.426766] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:23 kernel: [ 1162.449068] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: 
Jul 13 23:33:23 kernel: [ 1162.496723] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597: block 452457956: 
Jul 13 23:33:23 kernel: [ 1162.554866] EXT4-fs error (device dm-0): ext4_readdir:226: inode #113022597:

<<und Seitenlang so weiter>>

 

[Zentris]

Mal gefragt (hätten wir schon eher fragen sollen):

• Läuft dein System als Raid-5 ?
• Hattest du einen Stromausfall bzw. ist die DS mal einfach abgeschaltet worden, während da was drauf lief?
• Welchen Plattentyp hast du da drin? Vermutlich eine normale Desktop-Platte (wie die meisten von uns). Diese Platten versuchen schon mal etwas länger, eine defekten Sector zu lesen und doch noch was rauszubekommen.
• Mit welchem Filesystem hast du das Volume formatiert? (hoffendlich ext4 ?)

Lt. dem Log scheint die INODE Table gestört zu sein. Aber ein ext4 System sollte mehrere inode tables an verschiedenen Stellen haben, außerdem ist ext4 ein journaling FS...

Als ob da der besagte Block 452457956 nicht gelesen werden kann: Entweder gibt es ihn wirklich nicht (falscher Inhalt des inode table - meine primäre Vermutung) oder die Platte ist dort kaputt oder die Platten-Hardware braucht zu lange mit der Fehlerkorrektur des Sectors.

Bei Raid-5 sollte aber der Raid-Mechanismus greifen (Fehlerkorrektur), tu er aber offensichtlich nicht... (oder doppelfehler, eher unwahrscheinlich)

Was sagt die SMART-INFO? Ist aber nicht wirklich wichtig, weil die ja den Fehlerzustand nicht erkennt.

die Zentris

PS: Wenn du ein Raid-1 hast, könnte man versuchen, eine der Platten an ein "normales" Linux im R/O Mode zu mounten und weitersehen (komplett auslesen usw.). Bei Raid-5 wird es kompliziert... das trau ich mir dann echt nicht zu...

 

[erix]

Ich habe zwei Western Digital Caviar Green mit 2 TByte (WD20EARS-00MVWB0) und zwei Western Digital Caviar Green mit 3 TByte (WD30EZRX-00MMWB0)verbaut. Sie sind zu einem Volumen - Synology Hybrid RAID (SHR) (mit Datenschutz der Fehlertoleranz von 1 Festplatte) zusammengefasst. Das Dateisystem ist ext4 und der Status angeblich "Normal", SMART-Info gibt für alle vier Platten in allen Positionen ein OK, der SMART-Test läuft bei allen Platten allerdings nur bis 90%. Seit ich die Kiste gestern neu gestartet habe sägt und nadelt es im innern zu Gott erbarmen, vielleicht sollte ich sie lieber ausschalten, bis die Backup-Platten geliefert sind. Andererseits, vielleicht kann das System die defekten Sektoren isolieren und alles wird gut? Schon mal Danke für Eure Hilfe und ein schönes Wochenende,

Erix

 

[itari]

schön wären die SMART-Informationen gewesen ... kommst da nicht dran?

Itari

 

[erix]

Doch, ich denke schon. Allerdings sind die Infos der Datenträger 3 & 4 nicht aktuell, da hängt der SMART-Test seit heute früh um 9 Uhr bei 90 %. Allerdings zeigten das auch die Datenträger 1 & 2 bis heute Mittag, dann waren sie (wider Erwarten) mit dem Test plötzlich fertig. Mir sagen die Ergebnisse leider gar nichts.

 

[itari]

an den Platten scheint es nicht zu liegen. Wende dich doch einmal an den Synology Support (Link in meiner Signatur) mit der Liste aus Beitrag #13 und lass die dein Dateisystem mal prüfen

Itari

 

[erix]

Hallo zusammen,

ich habe den Synology-Support vor zwei Tagen kontaktiert, allerdings hatten die Jungs auch Wochenende und mehr als eine automatisch generierte Antwort war noch nicht drin. Hier ist die Situation unverändert, zwei der vier Platten sind immer noch mit dem SMART-Schnelltest beschäftigt (seit 48h bei 90%). Immerhin liegen in der Packstation zwei neue HD's, Kapazitäten für ein Backup hätte ich jetzt also. Ob ich die Datensicherung auf der DS einfach mal anschiebe (selbst auf die Gefahr hin, dass sie wie der SMART-Test hängen bleibt) oder lieber doch beginne, die Files per Hand zu kopieren. Dann merke ich wenigstens gleich, wo Daten-Inkonsistenzen auftreten, allerdings dauert das ja ewig …

einen schönen Start in die Woche, erix

 

[erix]

Hurra, der Synology-Support hat mir geantwortet.

thank you for the inquiry.

From the attached document, there seems to be file system errors within the data volume. File system errors could occur if there had been improper shutdowns/power loss, defective disks and when third party OPTware/application is installed on the system.

To resolve this issue, please backup all data from the volume, then remove and recreate the volume with healthy disks.

Nun gut, dies sind keine bahnbrechend neue Erkenntnisse. Die CS407 hat heute den ganzen Tag die neuen Festplatten zu einem Volumen geklöppelt, die DS 1010+ hat den SMART-Test trotzdem nicht zu Ende gebracht. Ich habe den Vorgang abgebrochen und widme mich nun der Datensicherung. Schon stehe ich als Laie vor dem nächsten Problem. Solange die CS407 und die DS 1010+ über den Router laufen, habe ich Zugriff auf sie. Leider hat der Router bloss ein 100er Ethernet. Also wollte ich die beiden Maschinen direkt verbinden, aber Pustekuchen,obwohl ich die IP-Adressen manuell vergeben habe, einen Ordner zur Netzwerksicherung freigegeben habe, verliere ich die Verbindung zu beiden Kisten. Bei der CS407 ist es ja klar aber die DS 1010+ hat doch ein zweites Netzwerkinterface an dem ich gar nichts ändere. Es ist zum verzweifeln, ich komme kein Stück weiter und sitze schon seit einer Woche vor dieser ver...ten Kiste. Was für ein (Netzwerk)problem ist denn jetzt schon wieder aufgetreten, Ideen?