Beiträge von sawachika

Dann ist es Zeit, ein Ticket bei Qnap aufzumachen, die Kiste rubterzufahren und zu warten, bis da eine Antwort kommt.

Zitat von Akinos

wieviel Red‘s sind den hier in der letzten Zeit als def. Gemeldet worden?

Ist das statistisch aussagekräftigt? Ich habe meine kaputten HGST's auch nicht gemeldet

Ich persönlich mische ohnehin frei im Rahmen der Kompatibilitätsliste. So vermeide ich das "gleiche Chargen"-Problem.

Nach der Liste müsste man Toshiba kaufen. 0% Ausfallrate.

Fakt ist, dass diese Listen immer eine Aufzeichnung der Vergangenheit sind und diese Werte variieren, wenn das nchste Plattenmodell oder die nächste Charge des gleichen Modells produziert wurde.

Auch ist das Lastverhalten im Rechenzentrum in der Regel ein "kleines" bisschen anders, als im Heim-NAS - damit kommen manche Platten besser oder schlechter klar - und auch hier ist wieder das Problem mit der Sicht in die Zukunft.

Nein, die Festplatten müssen formatiert werden, um im NAS genutzt zu werden.

GGf. findet sich im Bekanntenkreis jemand, bei dem Du die Daten zwischenparken kannst - aber die investition in zusätzlichen Speicherplatz benötigst Du sowieso für dein backup.

Deine Qnap hat das init_lvm.sh noch nicht.

Ich meine, bei den älteren Kisten musste man stattdesssen

config_util 1

storage_boot_init 1

verwenden. Hier verlassen wir aber den Bereich, in dem ich mich auskenne.

Was zeigt denn lvscan bzw. lvs an?

sieht ok aus. kaputt machen kann man an der Stelle, solange man das --force weglässt, eh nichts.

Ein paar Notzien zu dem Thema Datenextraktion kann ich Dir hier anbieten:

Wiederherstellung von Daten aus einem RAID im Recovery Mode (Notizzettel)

Du wirst die dort genutztn befehle vermutlich ein bisschen an deinen konkreten Fall anpassen müssen.

Es sieht eigentlich nicht so aus, als wäre das Datenraid inkonsistent.

Vermutlich hat sich die Firmware-Konfiguration verabschiedet. ganz frisch war die ja auch nicht mehr.

Manchmal funktioniert es, wenn man nur mit einer Platte bootet und nach dem start die anderen Platten dazusteckt.

Ich würde dazu tenderien, die Kiste neu aufzusetzen und die Daten vom Backup zu ziehen, alternativ ginge auch eine Kontaktaufnahme bei Qnap, wenn man ausreichend Zeit hat, darauf zu warten.

Sollte das Backup zu alt sein, kann man vorher noch versuchen, den Raid-Verbund von Hand zu mounten und die Daten auf eine externe Platte zu ziehen- die Raid-Größe ist ja relativ überschaubar.

Die Zuverlässigkeit unter den Herstellern gibt sich nicht viel. Nur in der Kompatibilitätsliste sollten sie stehen:

https://www.qnap.com/en/compatibility/?model=212&category=1

Du kansnt eine größere kaufen, die kapazität kannst Du jedoch erst nutzen, wenn alle Platten im Raid-Verbund die gleiche Größe haben

Bitte vorher nochmal rebooten...

Bei einem Einzellaufwerk? keinen. lediglich Snapshots gehen dort nicht.

Wenn ich /etc/init.d/init_lvm.shschreibe - wieso tippst Du dann

/etc/init.d/services.sh stop ? Q_Q

Volume und Storage Pool von der SSD löschen, dann direkt auf "Neues Volume anlegen", dort dann statisches Volume auswählen.

Das 871U-RP ist deutlich älter. Wenn Du über eine Neuanschaffung sprichst, würde ich die 871U-RP schlichtweg ignorieren. Nicht unwahrscheinlich, dass Du einfach nicht an den Zeitverlauf adaptierte Preise zu sehen bekommen hast.

Hab es auch mal mit einer SSD getestet - bei der Verwendung von StoragePools wird der Platz für interne Zwecke benötigt. Das ist auch bei normalen Festplatten der Fall, da fällt das aber nicht so ins Gewicht.

Man kann das umgehen, in dem die SSD als Static Volume eingebunden wird. Dann verliert man nur den Platz, den das QTS zum Replizieren des Betriebssystems nutzt - Die Funktionen, die nur mit StoragePools möglich sind, gehen dabei natürlich verloren.

Tjo, Stromausfall und NAS sind nicht die besten Freunde - und während eines Raid-Rebuild ist das einer der Dinge, die man da am allerwenigsten brauchen kann.

ggf. wäre für dich eine USV überlegenswert.

Mach doch nochmal einen Reboot von der Kiste, dann setze folgenden Befehl ab:

/etc/init.d/init_lvm.sh

Danach rein informativ nochmal

cat /proc/mdstat

Wenn sich die Kiste dann nicht erholt (Raid Rebuild sollte dann anlaufen) würde ich es hier mal mit einem Support-Ticket probieren - Dein Raid sieht eigentlich ganz ok aus und würde es daher vermeiden wollen, hier durch einen Firmware-Reset gehen zu müssen. Qnap kennt da vieleicht noch eine Stellschraube, um den Verbund im QTS wieder anzulernen.

Schonmal ins Webinterface geschaut, ob es aktive Hintergrundaktivitaeten gibt? Sind die Platten ggf. anderweitig beschaeftigt?

Ist eine direkte Kabelverbindung (mit manueller IP-Adressvergabe) zwischen NAS und PC gleich langsam?

Die Anzahl der TB hat ja nicht viel damit zu tun, ob man davon ein Backup hat oder nicht, sondern eher, ob die Daten wichtig sind oder nicht

Zumindest die Datne, die einem wirklich lieb und tueer sind, sollte man nochmal irgendwo anders haben.

Bei allem was Du jetzt machst (egal ob alleine oder mit dem Qnap-Support), besteht ganz grundsätzlich die Gefahr, dass sich dein Raid verabschiedet. Darauf sei der Form halber nnochmal hingewiesen.

Eigentlich sollte der Speicherpool nicht als aktiv angeziegt werden, wenn eine Platte ausgefallen ist.

Geh' doch mal zwecks Informationssammlung per SSH auf die Qnap und poste die Ausgabe von:

cat /proc/mdstat

df -h

qcli_storage -d

mdadm --examine /dev/sd[abcdefghi]3

Gerade der letzte Befehl erzeugt vermutlich viel Ausgabe, die sich sehr ähnlelt - bitte dennoch alles posten.

Left symmetric hat eigentlich nur etwas damit zu tun, wie die Paritätsinformation errechnet wird, nicht zwingend muss das mit der Anordnung oder
der Buchstabierung der Platten zu tun haben.

Wäre aber ganz gut, wenn man die --examine Informationen aller Platten bekommen könnte, denn sie sind sich zwar ähnlich, aber nicht gleich