S3 sleep ist der Standby Modus, in dem das NAS nicht mehr auf Anfragen reagiert, da es ja nahezu keinen Strom mehr verbraucht.
Es ist wie der Fernseher, der auch nur noch auf den Knopfdruck von der Fernbedienung warten kann.
Der Datenträgerbereitschaftsmodus (was ein Wort) übersetzt sich in HDD Standby.
Snapshots sind keine Backups. Ein Backup auf die zweite Platte im gleichen NAS ist kein Backup, egal in welcher Form oder mit welcher Technologie sie erstellt werden.
20 Stunden für 5 TB wären etwa 72 MByite/s, das würde ich jetzt mal als relativ gut bezeichnen.
Du wechselst zudem auch in den EInheiten zwischen MB und mbit, das macht es nicht unbedingt leichter, dein Problem nachzuvollziehen.
Und warum schaltest Du eine Geschwindigkeitsbremse ein, wenn Du doch mehr Geschwindigkeit haben möchtest?
Bitte nenne auch Snapshots nicht Backup. Snapshots sind eine Möglichkeit, Änderungen auf der Platte zurückzurollen. Diese kann man zeitlich automatisch erstellen und dann ggf. auf den älteren Datenstand zurückgreifen. Snapshots funktionieren mit Thick Volumes, dabei ist es technisch egal, ob darunter ein RAID ist oder nicht.
Nein, die Qnap zerstört die Daten auf der anderen Platte natürlich nicht. Aber nach meiner Erfahrung sind Probleme, in denen ein RAID 1 mit Snapshots nicht hilft, größerer Natur - d.h. das NAS-Gerät versagt oder wird durch Überspannung o.ä. inklusive der verbauten Festplatten zerstört. Backup heißt immer: physikalisch vom Hauptgerät getrennter Lagerort.
Ein Backup der Daten auf eine Platte im NAS-Gehäuse ist kein Backup, sondern ein RAID 1 im Handbetrieb. Fällt die Qnap aus, ist das "Backup" auch hin
Das Thema Spiegelung mit RAID 1 ist zum großen Teil jedoch auch Geschmackssache, manche bevorzugen Handbetrieb für eine Versionierung, der Daten. Dazu muss man jedoch auch diszipliniert genug sein, diese Kopie durchzuplanen bzw. einzuplanen und zu kontrollieren. Das lässt sich mit Snapshots und RAID 1 meiner meinung nach einfacher realisieren.
Ganz grundsätzlich bin ich ein FAN von RAID 1 bzw. in den größeren NAS RAID 5/6, denn auch mit Backup ist ein Plattenausfall nervig, wenn man den ganzen Kram wieder von Hand zurückschaufeln muss.
Wenn Du Snapshots nutzten möchtest, fällt das Static Volume aus deinen Auswahlmöglichkeiten weg.
Von Thin Volumes würde ich in deinem Szenario ganz grundsätzlich abraten.
Hm. In der Textdatei geht es auch nur bis sdg3.... ich denke, du wirst den mdadm - Teil nochmal durchführen müssen.
Gibt es bei euch im QTS-Kontrollzentrum nicht den menüpunkt NAS initialisieren, bei dem der Inhalt sämtlicher Platten gelöscht wird und das NAS quasi wie neu dasteht? Q_Q
Das QTS installiert sich potentiell auf jeder Platte, die im System eingebunden wird in einer gesonderten Partition in einem Raid 1 Verbund.
Wenn später eine Platte hinzukommt, wird diese QTS Partition auch dort angelegt.
Wer ganz sicher gehen wll: Im Kontrollzentrum aus initialisieren gehen, NAS nach Abschluss herunterfahren lassen. Alle platten raus und diskpart - clean. Letzteres halte ich aber für unnötig, habe es aber selbst nicht getestet mit m.2 Platten.
Das ließe sich aber verifizieren: nach dem Initialiseren das NAS hochfahren und bevor man im Setup irgendwas macht per ssh auf die Qnap schalten.
Dort dann schauen, was
cat /proc/partitions
anzeigt.
Was ist denn deine Alternative zum Ready-NAS?
Wirf' doch mal einen Blick hier drauf, vieleicht kannst Du damit etwas anfangen.:
Wiederherstellung von Daten aus einem RAID im Recovery Mode (Notizzettel)
Es fehlt in den Notizen der Punkt mit der Verschlüsselung, mit LUKS scheinst Du jedoch vertraut zu sein, daher vermute ich, dass Du das hinkriegen kannst 
Bei der Ausgabe der mdadm --examine Kommandos hat das Forum offenbar ab /dev/sdg3 die nachfolgenden Zeilen verschluckt. Könntest Du die noch nachliefern?
sdb3 meldet Fehlersektoren, deswegen ist diese Platte aus dem Raid rausgeflogen.
df -h signalisiert allerdings, dass deine Datenpartition im System eingebunden ist, möglicherweise ist dies aber nur ein toter Mountpunkt, bevor dein Raid offline gegangen ist.
Selbst wenn dein Raid nochmal an den Start kommt - du solltest den Inhalt deines Verbundes auf ein anderes Speichermedum sichern können - wenn Du auf dein backup weiterhin verzichten möchtest, dann zumindest temporär - und dann das RAID neu aufsetzen.
Warum versuchst Du nicht, deine Qnap ohne Platten zu starten, dann die Platten einzulegen (Finger weg vom Web-Assistent) und deine Rettungsaktion von dort aus durchzuführen?
Hat den Charme, das Du alle nötigen Tools dort verfügbar hat...
Die ~8 Jahre alte TS-419P kann eher noch keine Snapshots.
Mal die Gegenfrage: War es denn jemals schneller? Das Booten von aktuellen ARM-Qnaps kann durchaus mal 8 oder 10 Minuten dauern.
Erfahrungsgemäß werden die Geräte mit aktuelleren FIrmware-Versionen auch langsamer statt schneller...
Das Problem war doch mehrschichtig - nicht nur die Datenübetragungsrate ist schwach, sondern eben auch die Frage nach dem Befüllen der NAS an sich.
Und hier ist robocopy in mehrfacher Weise ein gutes Tool.
a) Weil Datentransfers mit Übernahme von Zeitstempeln möglich sind
b) Weil Konsolentools Probleme in der Kopierperformance des Windows-Explorers nicht selten umschiffen können
c) Weil robocopy auch mit mehrfachen Threads laufen kann - das ist gerade bei kleinen Dateien ein Plus.
Wenn auch mit robocopy die Performance deutlich unter den von mir in dem Testbericht ermittelten Datenraten liegt, macht es Sinn in der Umgebung genauer hinzuschauen. In einfachen Windows-Umgebungen ist es z.B. oft der WIndows-Defender, der in jede Datei äußert ausgiebig reinschaut während des Kopiervorgangs...
Was ist an robocopy denn veraltet? 0.o
Nur weil es schon seit langer Zeit funktioniert und nicht mit Uusatz-Features aufgeblasen wird? Dann sollte man rsync, ssh und aehnliche veralteten Programme auch nicht verwenden...
warum nimmt man nicht das hauseigene robocopy ?
Man muss nichts basteln ist relativ ... nach nem dms oder firmware update muss das ja auch noch funktionieren.
Ein skript miss man ggf. neu einplanen, aber an sich ist da nie wieder etwas anzupassen.
Ich hatte den Thread-Ersteller so verstanden, dass aufgrund des Ehrenamtes ja keiner irgendwas damit zu tun haben will und moeglichst alles ohne Pflegeaufwand funktionieren soll...
Ich empfinde das als wenig realisitisch, aber ein Skript kommt dem meiner Meinung nach noch vergleichweise nah.
Ein DMS muss auch wieder jemand pflegen und verstehen.
Und das bürdet ja den einzelnen Usern doch wieder viel Last auf.
Man koennte das scripten, aber auch das muesste eben jemand machen.
Geschenkt gibt es die Funktion meines Wissens nicht.
Mehr versauen geht damit nicht. Aber ob es hilft, kann auch keiner versprechen, also wirst du es probieren muessen.
Probiere es doch aus?
Dringend benötigte Daten bedeutet doch, dass Du ein backup davon hast.
Dann würde ich doch darauf zurückgreifen?
