Beiträge von sawachika

Die Qnap wird auf der Platte ihr Betriebssystem installieren. Dabei wird die Platte zwangsläufig formatiert.

Zitat von DasGrml

[...], dass die Platte mit einem Schloss statt grünem Haken versehen ist...

Eigentlich steht das Schloss für ein verschlüsseltes Volume. Da es geöffnet ist, hast Du entweder das Passwort eingegeben oder irgendwann auf dem NAS gespeichert, sodass das Volume automatisch entsperrt wird.

Wenn Du alle vier Platten rausnimmst und zu einem späteren Zeitpunkt wieder einlegst (vorher jeweils NAS heruntergefahren), funktioniert das.
Wichtig ist eben, dass alle Platten rausgenommen werden und beim einlegen wieder in der gleichen Reihenfolge eingelegt werden.

Um die Prozedur auszuführen, benötigst du allerdings mindestens eine andere Festplatte, auf der Du dann die 453A rudimentär neu in Betrieb nimmst.
Deine zwei Datenplatten aus dem defekten NAS dürfen sich erst in der 453A befinden, wenn du dies erledigt hast.

Ich weiß es ist unhöflich, aber dennoch eine Gegenfrage: Warum ist denn die Platte in Schacht 2, die du in ein RAID 1 unter Zuhilfenahme der Platte in Schacht 1 migirieren willst, im Status "Fehler" ?

Ich hab das mal durchgespielt.
Leider habe ich meinen SATA-USB Dongle offenbar verliehen oder verlegt, daher habe ich es doch über die Qnap gemacht.
Es sind zwei Qnaps im Spiel, beides TS-431+, Q und D.
Vieleicht hilft es Dir bei deinem Problem ein bisschen weiter - 1 zu 1 lassen sich die Kommandos sehr wahrscheinlich nicht auf dein Problem übertragen.

Auf Qnap 431+ [Q] über QTS ein RAID 1 eingerichtet und Testdaten ablegen:

Slot 1 + 2 belegt, 3+4 frei
StoragePool 1 - 1,81TB, RAID 1
ThinVolume: LostVol, 150GB
SharedFolder: LostShare
TestFile: Lost_2GB_File
TestText: LostText.txt

Referenzinfo aus dem Quell-NAS zum Raid:

[admin@MisakaNET-Q ~]# mdadm --detail /dev/md1/dev/md1:        Version : 1.0  Creation Time : Fri Jan 12 09:51:47 2018     Raid Level : raid1     Array Size : 1943559616 (1853.52 GiB 1990.21 GB)  Used Dev Size : 1943559616 (1853.52 GiB 1990.21 GB)   Raid Devices : 2  Total Devices : 2    Persistence : Superblock is persistent    Update Time : Fri Jan 12 09:54:05 2018          State : clean  Active Devices : 2Working Devices : 2 Failed Devices : 0  Spare Devices : 0           Name : 1           UUID : 89c437fa:3d743dc9:e1cb54d3:3b0c97d2         Events : 3    Number   Major   Minor   RaidDevice State       0       8        3        0      active sync   /dev/sda3       1       8       19        1      active sync   /dev/sdb3

Test mit zweiter Qnap 431+ [D]:
Vorraussetzungen
- Slot 1+2 mit formatierten Festplatten bestückt.
- NAS gestartet und initialisiert.
- Sicherstellen, dass auf dem neuen NAS kein Volume/StoragePool existiert.
- Slot 3 mit Festplatte aus Slot 2 von [Q] bestückt.
- QTS erkennt die Platte als leer / nicht initialisiert.

-SSH-Kommandos-

Informationen sammeln:

[admin@MisakaNET-D ~]# cat /proc/partitions | grep sdc   8       32 1953514584 sdc   8       33     530125 sdc1   8       34     530142 sdc2   8       35 1943559763 sdc3 << Partion für Daten-RAID   8       36     530144 sdc4   8       37    8353796 sdc5

Das Raid-Device wird mit der einzelnen Platte im "degraded" Modus gestartet.
Wenn beide Platten vorhanden und funktionsfähig sind,
wird --run nicht benötigt, dafür muss dann die zweite Festplatte des RAID 1 Verbundes eingesteckt und angegeben werden.

[admin@MisakaNET-D ~]# mdadm --assemble --run /dev/md44 /dev/sdc3 mdadm: failed to get exclusive lock on mapfile - continue anyway...mdadm: /dev/md4711 has been started with 1 drive (out of 2).

Infos zum Raid-Blockdevice anschauen.

[admin@MisakaNET-D ~]# mdadm --detail /dev/md44/dev/md4711:        Version : 1.0  Creation Time : Fri Jan 12 21:51:47 2018     Raid Level : raid1     Array Size : 1943559616 (1853.52 GiB 1990.21 GB)  Used Dev Size : 1943559616 (1853.52 GiB 1990.21 GB)   Raid Devices : 2  Total Devices : 1    Persistence : Superblock is persistent    Update Time : Fri Jan 12 22:14:02 2018          State : clean, degraded  Active Devices : 1Working Devices : 1 Failed Devices : 0  Spare Devices : 0           Name : 1           UUID : 89c437fa:3d743dc9:e1cb54d3:3b0c97d2         Events : 3    Number   Major   Minor   RaidDevice State       0       0        0        0      removed       1       8       35        1      active sync   /dev/sdc3

Die LVM-Informationen müssen eingelesen werden.

Sofern über QTS eine Volume-Gruppe angelegt werden soll, auf die dann die Daten kopiert werden,
so muss die Volume-Gruppe vg1 umbenannt werden, da QTS andernfalls ebenfalls versucht, eine vg1 anzulegen.

[admin@MisakaNET-D lvm]# pvscan --cache[admin@MisakaNET-D lvm]# pvscan   PV /dev/md44   VG vg1             lvm2 [1.81 TiB / 18.54 GiB free] << gestartet md44 Raid  Total: 1 [1.81 TiB] / in use: 1 [1.81 TiB] / in no VG: 0 [0   ][admin@MisakaNET-D ~]# vgscan  Reading all physical volumes.  This may take a while...  Found volume group "vg1" using metadata type lvm2[admin@MisakaNET-D lvm]# lvscan   inactive          '/dev/vg1/tp1' [1.73 TiB] inherit << StoragePool von LostVol  inactive          '/dev/vg1/lv1' [150.00 GiB] inherit << LostVol

Sofern über QTS eine Volume-Gruppe angelegt werden soll, auf die dann die Daten kopiert werden,
so muss die Volume-Gruppe vg1 umbenannt werden, da QTS andernfalls ebenfalls versucht, eine vg1 anzulegen.

[admin@MisakaNET-D ~]# vgrename vg1 vg44  Volume group "vg1" successfully renamed to "vg44"[admin@MisakaNET-D ~]# lvscan  inactive          '/dev/vg44/tp1' [1.73 TiB] inherit  inactive          '/dev/vg44/lv1' [150.00 GiB] inheritVolume-Gruppe aktivieren:[admin@MisakaNET-D ~]# vgchange -a y vg44  2 logical volume(s) in volume group "vg44" now active[admin@MisakaNET-D ~]# lvscan   ACTIVE            '/dev/vg4/tp1' [1.73 TiB] inherit  ACTIVE            '/dev/vg4/lv1' [150.00 GiB] inherit

Ein Verzeichnis anlegen, in das die Volumegruppe eingehängt werden soll und die Volumegruppe einhängen.

[admin@MisakaNET-D ~]# mkdir /share/ttt
[admin@MisakaNET-D ~]# mount -t ext4 /dev/mapper/vg44-lv1 /share/ttt
[admin@MisakaNET-D ~]# ls -alh /share/ttt/LostShare/   
drwxrwxrwx    4 admin    administ      4.0k Jan 12  2018 ./
drwxrwxrwx   23 admin    administ      4.0k Jan 12  2018 ../
drwxr-xr-x    2 admin    administ      4.0k Jan 12  2018 @Recently-Snapshot/
-rw-r--r--    1 admin    administ        29 Jan 12  2018 LostText.txt
-rw-rw-rw-    1 admin    administ      2.0G Jan 12  2018 Lost_2GB_File

Die Daten können nun entweder auf eine an die Qnap angeschlossene USB-Platte oder ein auf den anderen Platten angelegte Volume-Gruppe kopiert werden.
Die Empfehlung wäre die USB-Platte - und anschließend die Qnap-Box nochmal komplett ganz frisch aufsetzen.

Was weißt Du noch über den Aufbau deines Speichersystems? Waren das Thick oder Thin Volumes oder ein Single Volume? Wie groß waren die einzelnen Volumes?
Hattest Du Snapshots genutzt?
Ich würd' mir das mal auf meiner 431+ versuchen nachzubauen.

Theoretisch ginge das zwar tatsächlich mittels Partitionierung (auf einem ähnlichen Weg realisiert Synology die erhöhte Effizienz seines Hybrid Raid bei den Systemen mit 3 und mehr Platten) - allerdings bietet das QTS das meines Wissens nicht an. Und über die Konsole was zu basteln würde ich dringendst von abraten, da nicht absehbar ist, was beim nächsten Firmware Update das Qnap-System damit macht.

Nein, das geht leider nicht - das "Überhang"-TB kann ja nirgends redundant gesichert werden, um RAID 1 zu ermöglichen.

Ja kann sein, dass die zu neu ist - die 4.3.4 hat ja schon einiges an Features mitgebracht.

Allerdings hat es ja einen Grund, warum das Vorgänger-NAS kaputt gegangen ist, wer weiß was da für ein Konfigurations-Stand auf den Betriebssystem-Partitionen der alten Platten liegt - gerade nach den mehrfachen Versuchen, die Migration durchzuführen.
Denke nicht, das da weitere Versuche über die QTS-Oberfläche noch zu Erfolg führen können - die Qnap-Kisten machen bei brauchbarer Ausgangskonfiguration sonst einen guten Job bei der Migration von Platten.

Ich würde da wahrscheinlich wirklich probieren, das über die gängigen Tools für mdraid und lvm an einem Linux-PC zu analysieren. Man kann da allerdings auch schnell alles kaputt machen. Wenn Du da nicht Sattelfest bist, würde ich es mal mit dem Ticket bei Qnap probieren - die meisten Tools sind ja auch auf der 453A über SSH vorhanden.

Hmm ich weiß nicht, ob ich dem Thread ganz folgen konnte:

Du hattest das 453A ausgeschaltet und die beiden Platten von dem 251er NAS eingebaut und dann gestartet. Das hat dann nicht funktioniert, die Daten zu übernehmen, auch bei mehreren Versuchen nicht?
Es kann Probleme machen, wenn die Firmware-Version auf dem alten NAS zu stark von der abweicht, die man im neuen NAS hat.

Sofern die Daten auf den Platten nicht durch ein anderweitiges Backup beziehbar und irgendwie wichtig sind, würde ich vermutlich die Platten an 'nen Linux-Rechner (Zur Not geht auch eine Live-CD) anschließen und mit mdadm den RAID-Verbund (ggf. forciert) zusammenbauen. Anschließend kann man den Kram normalerweise unter Zuhilfename von LVM ins Dateisystem einhängen.
Je nach CPU im NAS muss man allerdings mit debugfs die Daten auslesen - mounten geht dann nicht.

Das Betriebssystem wird intern auf einem RAID 1 verteilt, ganz egal welches RAID-Level der Daten-Pool bekommt.
D.h. solange mindestens eine Platte überlebt, kommt auch das Betriebssystem wieder hoch - ein Backup der Konfiguration ist dennoch regelmäßig zu empfehlen - in erster Linie allerdings eher für den Fall, dass man selbst etwas verbockt oder QNAP mit einem Firmwareupdate was zerschießt

Ich hatte die 231 und 431 eine Zeit lang im Test mit 7200er Platten. Mit Verschlüsselung kam ich nie über 15MB/s.
Hatte alles mögliche probiert, Cache, NFS statt SMB, alle Zusatzdienste abgestellt, Jumbo Frames, ThickVolumes, Single Volume, etc...
War ein RAID 1 bzw in der 431 ein RAID 5.
Mit RAID 0 kamen die Kisten immerhin auf 25MB/s.

Das RAID ist eben Software-baisiert - d.h. auch das muss die CPU managen und in Kombination mit dem knappen Speicher und Verschlüsselung wird es schon sehr schwierig, die zu schreibenden Blöcke derart vorzusortieren, dass die Platten hier eine gute Performance bieten können.
Zum Glück kam in der Test-Phase die TS-431+ raus, die schafft mit den gleichen Platten und Verschlüsselung im RAID 5 immerhin 40MB/s.
Selbst mit SSDs kam da nicht mehr durch.

Mich würde echt interessieren, wie QNAP die Benchmarks erzeugt - an die beworbenen Labor-Werte komme ich selbst mit stupide sequentiell schreibenden Benchmarks nicht wirklich nah ran.

Ganz frisch eingetroffen ist übrigens nun die 431P2 - hier komme ich mit Verschlüsselung erstmals mit über 80MB/s auch ungefähr die Hälfte vom QNAP-Wert, selbst mit Link Aggregation.

Hi,
danke für eure Gedanken zu dem Thema.
@christian : Die QNAP ist hardwaremäßig nicht modifiziert - außer die Platten, die drin sind natürlich. (Hat die TS-431+ überhaupt tauschbare RAM-Module?)

@warpcam : Es scheint so zu sein, dass für das Verhalten eine IP-Adresse ausreicht. Wenn die Kiste eine feste IP-Adresse hat, dann kann es auch alleine am Switch hängen, damit das Problem auftritt. Bekommt sie keine DHCP Adresse, weil der Router ja nicht mehr am Switch hängt, so scheint das Problem nicht aufzutreten. Zumindest nicht bei den 3 Bootvorgängen eben. Sehr merkwürdig.

Hallo liebe Qnap'ler ,

meine zwei TS-431+ Stationen haben seit dem Update auf 4.3.3.0188 (von einem der letzten 4.2 Builds, vermutlich, aber nicht sicher war es das vom 20170313) eine komische Angewohnheit:

Wenn das Gerät am LAN angeschlossen ist, verfällt die Kiste in eine Rebootschleife. Irgendwann, nach mindestens zwei, gerne aber auch mal 5 - 10 Reboot-Läufen, ist die Kiste dann erreichbar.

Im Systemlog erscheint lediglich die Meldung, dass der letzte Reboot nicht sauber war.

Auch wird nach jedem Reboot die Installation des QNapSSLCloud Certificates und dem ResourceMonitor.bin gestartet.

Wenn die Kiste mit abgezogenem LAN-Kabel startet, ist der Startvorgang beim ersten Versuch erfolgreich. Danach kann ich auch problemlos das Kabel einstecken.

Es ist dabei ganz egal, an welchem LAN Interface das Kabel steckt und ob ich statische IPs oder DHCP nutze.

Zur Konfiguration:
Die Kiste hat keine Möglichkeit ins Internet zu gehen. In der statischen Konfiguration gibt es kein Gateway, per DHCP gibt es ein Gateway zugeteilt, da kommt die Qnap allerdings nicht raus.
Es sind keinerlei Apps zusätzlich installiert und auch bei den Netzwerkdiensten ist ausser dem Webinterface, SSH und CIFS/SMB 3 alles abgestellt.

Das Datenvolume ist verschlüsselt.
Dieses Verhalten habe ich auf beiden TS-431+, seit dem Update. Auch Updates auf die derzeit aktuelle Version 4.3.3.0262 build 20170727 haben das Problem leider nicht verbessert.

Mit dem QNAP-Support hatten wir diverse Dinge ausprobiert, im Wesentlichen lief es neben problemfreiem Filesystem-Check und RAID-Scrubbing, dem erfogreichen Boot ohne Festplatten mit LAN auf einen Reset aller Einstellungen hinaus. Das hat das Problem allerdings nur für den allerersten Reboot nach dem Reset behoben.

Jetzt die Preisfragen :
Was macht die Kiste anders, wenn Sie LAN-Link hat. Und: Gibt es eine Möglichkeit, der Kiste zu entlocken, was sie macht, während sie in der Bootschleife hängt? Ich komme in der Zeit maximal für ein paar Sekunden per Webinterface oder SSH drauf - die Zeit reicht aber meist nicht mal, um da das Passwort einzugeben.

Wäre echt klasse, wenn jemand 'ne Idee hätte. Ist echt super nervig, da meine beiden Qnaps nur alle paar Tage mal eingeschaltet werden und ich dann jedes Mal unter den Tisch kriechen muss, um das LAN-Kabel zu ziehen

Da wäre dann vielleicht dieser Faden interessant für dich:

http://superuser.com/questions…crypted-lvm-under-windows

Klingt aber für mich nicht wirklich einfacher, als es gleich unter Linux zu machen, zumal die Tools wohl auch nicht mehr weiterentwickelt werden.
lvm, LUKS und ext-Dateisystem kommen nun mal aus der Linux Welt, da würde ich, wenn mir meine Daten wichtig sind, auch auf Nummer sicher gehen und eine Umgebung nutzen, die alle nötigen Technologien nativ unterstützt.
(Ich würde z.B. auch keine Windows-Domäne mit einem Linux-Server statt einem Windows-Server betreiben. Es geht zwar, aber man hinkt da auch immer den Entwicklungen auf MS-Seite hinterher)

ich habe verstanden, dass diese ganzen Sync-Sachen nichts anderes sind als eine WebGUI für rsync.
rsync vergleicht ja grundsätzlich Zeitstempel und Dateigröße - gibt es da einen Unterschied, dann wird neu übertragen.
Der Zeitstempel bezieht sich auf das letzte Änderungsdatum der Datei und natürlich ist das dann sekundengenau.

rsync kann alternativ noch Checksummen vergleichen - das ist aber ziemlich langsam, da hierzu natürlich sowohl auf der Quelle als auch am Ziel die Dateien komplett eingelesen werden müssen.

Ich synce zwar inzwischen mit meinem Rechner per Skript direkt zwischen meinen zwei NAS-Geräten - aber auch da hatte ich immer mal wieder Probleme, dass einige Dateien immer neu übertragen wurden.
Da hatte ich dann per ssh Login festgestellt, dass auf dem Quell-NAS diese Dateien einen Zeitstempel hatten, den ich als nicht gültig ansehe - 1970 oder sogar 1901.
Diesen Dateien habe ich auf dem Quell-NAS dann per SSH und dem Befehl touch einen neuen Zeitstempel verpasst, daraufhin hat rsync die Dateien nur noch ein einziges Mal neu übertragen.

Das Problem tritt gelegentlich immer mal wieder auf, aber die konkrete Ursache habe ich bisher nicht gefunden.

Hallo,

ich habe, nach langer Zeit des "manuellen RAIDs" per USB-Festplatten und diversen, unkoordinierten Datenhalden mit entsprechenden Dublettenansammlungen, nun mal meine Speicherstruktur mit einem Konzept versehen und dieses nun auch nahezu umgesetzt.

Die Konstellation besteht aus zwei NAS-Systemen und einem PC:

A: QNAP TS-431+, Volume-Verschlüsselung aktiviert, RAID 5
B: QNAP TS-431+, Volume-Verschlüsselung aktiviert, RAID 5

PC: Intel i3 6100U @ 2.3Ghz, 16GB RAM, Samsung NVME SSD, Ubuntu 15.10

Alle Geräte sind über einen 5-Port Gigagbit Switch von Cisco verbunden.
Mein Konzept inkludiert ein rsync-script, welches zwischen A,B und C nach bestimmten Regeln, einzelne Shares hin oder her synchronisiert.
Die NAS-Shares werden an dem PC vor Start des Scriptes lokal gemounted, rsync läuft daher im lokalen Modus ausschließlich auf dem PC.

Nun ist mir da ein Phänomen aufgefallen, welches ich mir nicht erklären kann, aber sich wie folgt nachstellen lässt:

Synce ich eine 20Gigabyte Datei (erstellt mittels fallocate) vom PC auf A oder B, so erhalte ich eine Übertragungsrate von etwa 52-55 MByte/s, in die andere Richtung, also vom NAS zum PC, kommen etwa 70MByte/s über die Leitung.
Das ist zwar unter den QNAP Werksangaben, aber ich sehe das mal so, wie das auch mit den Werksangaben beim Benzinverbrauch von Autos ist 8-)

Nun wäre meine Erwartungshaltung, dass ein Sync zwischen A und B, etwa 50 MByte/s bringt, denn A kann die Daten dem PC mit mit 70MByte/s anliefern und B kann diese Daten dann mit 55MByte/s wegschreiben. Selbst wenn Vollduplex im Netzwerk nicht funktionieren würde, müsste sich das ganze doch auf etwa 50MByte/s einpendeln.

Die CPU-Last auf den QNAPs ist eher moderat - 30% in der Spitze. Auch sonst müssen die QNAPs nichts tun - ausser CIFS sind sämtliche Dienste deaktivert. Auch Apps sind keine installiert.

Ich habe mit verschiedensten Einstellungen rumgespielt - Caching, SMB 3/2, verzögertes Schreiben und Jumbo-Frames (MTU bis 9000) - das alles bringt keinerlei Veränderung.

Die CPU des PCs ist mit rsync zu 10% beschäftigt. Auch von den 16GB RAM ist noch reichlich frei.

Hat irgendjemand vielleicht eine Idee, was ich übersehe oder zumindest eine Erklärung, warum sich dieses Verhalten so einstellt?

Viele Grüße,

sawa