Hey,
danke für die Erklärung.
Dachte mir schon sowas, dass da die Linux-Geschichte was damit zu tun hat und der Anzeigename mit dem Namen, der auf Dateisystemebene verwendet wird im Spiel sind.
Ist ja aber auch nix negatives. man muss es eben nur wissen.
S.
Hey,
sowas hatte ich auch mal.
Siehe: TS-453 Pro - Nach Neustart kein Netzwerk.. Ping läuft ins Leere
Da ab so Beitrag 6 lesen: Wenn du das Bündel via LACP aufbaust kann es durchaus sein, dass WOL nicht weitergeleitet wird.
S.
Übrigens:
Erst gestern gemerkt bei 2 RTRR Jobs:
Ich musste auf dem ZielNAS den Speicherpool und auch die Freigaben neu anlegen.
Die beiden RTRR Jobs die da Daten ablegen schlugen fehl.
Ich musste einmal in jeden Job rein und das Verzeichnis nochmal angeben und ab da hat es funktioniert.
Scheint also nicht nur über den Verzeichnisnamen zu laufen sondern noch andere Metainfos verwendet zu werden.
S.
Wenn Du das App-Center auf dem NAS aufruftst, zeigt er doch an welche Version er installieren will.
Okay. hast recht, ist mir offen gesagt noch nie aufgefallen. Danke für den Tipp
Naja....wie gesagt: in den Changelogs wird darüber die Beta 3 angezeigt.
Wie kann ich sicher sein, dass er eben NICHT die Beta einspielt ?
S.
Hi zusammen,
vielleicht habe ich es überlesen, aber wie kann ich verhindern, dass mir die public beta installiert wird?
Ich hab momentan die 3.6.49 drauf. Es gäbe die 3.6.52, allerdings wird in den Changelogs drüber eben die public Berta 4.irgewndwas angegegen.
Kann ich jetzt irgendwie erreichen, dass mir 3.6.52 installiert wird?
Die Beta scheint ja diverse Probleme zu haben....und ich möchte ungern 6 VMs neu aufsetzen müssen incl. der WIN Aktivierung....
Da häng ich mich mal mit dran.
Ich hab da in den vergangenen knapp 12 Jahren leider keine Ambitionen von QNAP gesehen an irgendeiner Stelle Konfigurationen speichern zu können.
Sei es HBS noch im OS selbst. Da kann man zwar was exportieren udn importieren. Aber das betrifft nur das gesamte....
QWNAP scheint das Thema "konfihurationen sichern/übertragen" sehr stiefmütterlich zu behandeln.
WD Red Plus kann ich auch als Platten empfehlen.
Bei mi laufen ca. 30 Platten sehr zufriedenstellend.
Eine ist jetzt 7 Jahre nach Erwerb und mit knapp 59.000 Betriebsstunden gestorben (24/7 Betrieb).
Ich finde das durchaus i.O.
S.
Ja das mit den fehlenden Backups sieht man hier ja immer wieder, aber ich hab vor knapp 30 Jahren mal fast Daten verloren (2 Tage vor Abgabe der Diplomarbeit Festtplatte tot....war ne 128MB Platte....riesig damals *fg*)
Seitdem bin ich Backup-Paranoiker. Ich hab permanent 3 Sicherungen auch an 2 verschiedenen Orten.
Das erkläre ich mir so, mit den HDs. Die erste HD kann ja bei einem Raid 5 sterben, dann bleibt es ja noch aktiv, doch dann muss jede HD im Verbund bleiben, sonst ist es inaktiv und daher wird die HD 1 bei dir bis zum Erbrechen festgehalten, da sonst gleich alles weg ist.
Okay sowas hab ich schon fast vermutet.
Das mit der Virtualization Station ist wohl eine Verzweiflungstat, das Volume ist weg und dann versucht QTS das was automatisch laufen soll wieder zu starten, doch die QVS ist mit dem Volume und dem ISOs verschwunden, das wird daher nix. Aber netter Versuch.
Joa im Prinzip denkbar, aber die VM ISOs liegen auf dem SSD RAID1 (Systemlaufwerk).....und das war ja nicht betroffen.
Ich trenne strikt System und Daten....sorry. kam im ersten Post nicht rüber, dass die VM auf dem anderen Pool liegt.
Ja Monitoring habe ich tatsächlich vernachlässigt....ist aber schon nachgeholt 
Hy,
schön dass Duauch wieder da bist Hatten ja schon des öfteren hier miteinander zu tun.
Ja ich bin gerade tatsächlich dabei, die Daten aus den Backups zu rekonstruieren.
Dass Platten in einem RAID sterben können ist ja völlig okay, und für mich Null Stress.
Mich wundern eben nur paar Kleinigekeiten:
- Warum wurde die HDD2 schon nach einem Lesefehler aus dem RAID genommen
- Warum wird beim rausnehmen der Platten das als INFO verschickt...ich finde das ist schon mindestens eine Warnung
- Warum startet die Virtualization Station neu ?!?
Hmm ich seh gerade, dass ich im Erstpost von "rausnehmen" geschrieben habe....Das ist so zu verstehen, dass das das NAS selbstständig gemacjt hat, die HDD2 und dann die HDD1 aus dem RAID zu entfernen.
Es ist nicht so zu verstehen, dass ich da aktiv Platten aus dem System gezogen habe.
S.
Ob nun alle Daten noch vorhanden sind, ist nicht so einfach zu sagen. Es können Datenbereiche in Dateien defekt sein, da es viele "pendig Sektoren" gibt. [..]
Deshalb schrieb ich die Daten scheinen okay zu sein .
Ich würde ein Raid Sync mit HD2, die anscheinend keine Lesefehler hat und einer neuen leeren HD1 versuchen.
Die HDD2 wurde aber vor 6 Tagen (!) aus dem RAID genommen.
Wie soll ein Rebuild mit so veralteten Daten denn funktionieren?
Das ist doch eher aussichtslos oder?
in der Zwischenzeit wurden ja neue Daten geschrieben und davon ist definitiv nix auf der Platte die 28.12. aus dem RAID genommen wurde.
Der ursprünglichen HD1 würde ich nicht mehr vertrauen.
Vielleicht kam es im ersten Post nicht ganz klar raus:
Ich habe hier 6 neue Platten und ich werde ALLE ersetzen, da sie in etwa gleich alt sind.
Wie bereits geschrieben: HDD2 wurde als erstes (bereits vor Tagen) aus dem RAID genommen.
Von daher war es für mich das naheliegendste, nach dem Löschen der beiden Fehlerzeilen die HDD2 erst mal gezogen zu lassen und habe - als dann das RAID wieder hochkam - die HDD2 durch eine neue ersetzt.
Wenn das RAID nicht mehr rekonstruiert werden kann - was ich durchaus verstehen kann - warum
- wird mir das dann nirgends angezeigt
- kann ich auf alle Daten auf dem RAID zugreifen und die Daten scheinen auch i.O. zu sein.
S.
Hallo zusammen,
System ist folgendes:
- TS-673A
- QuTS hero 5.1.2.2534
- 2 SSDs als Systemlaufwerk im RAID1
- 6 WD Red Plus im RAID5
Als ich nun nach den Feiertagen mal wieder auf die NAS geschaut habe (war paar Tage weg....), der große Schock: Freigaben weg,
Analyse hat nun folgendes gezeigt:
a) am 28.12. hat die HDD2 im Anbstand von 30 Minuten Ledefehler gehabt und wurde dann aus dem RAID genommen 
Warning 2023-12-28 03:37:20 --- --- localhost --- Hardware Status I/O Ports [Hardware Status] "Host: 3.5" SATA HDD 2": Medium error. Run a bad block scan on the drive. Replace the drive if the error persists.
Warning 2023-12-28 03:37:19 --- --- localhost --- Hardware Status I/O Ports [Hardware Status] "Host: 3.5" SATA HDD 2": Read I/O error, "UNRECOVERED READ ERROR ", sense_key=0x3, asc=0x11, ascq=0x4, CDB=88 00 00 00 00 00 05 9b 4b 10 00 00 01 30 00 00 ..
Warning 2023-12-28 03:07:15 --- --- localhost --- Hardware Status I/O Ports [Hardware Status] "Host: 3.5" SATA HDD 2": Medium error. Run a bad block scan on the drive. Replace the drive if the error persists.
Warning 2023-12-28 03:07:15 --- --- localhost --- Hardware Status I/O Ports [Hardware Status] "Host: 3.5" SATA HDD 2": Read I/O error, "UNRECOVERED READ ERROR ", sense_key=0x3, asc=0x11, ascq=0x4, CDB=88 00 00 00 00 00 05 99 d2 08 00 00 00 10 00 00 ..
Information 2023-12-28 03:57:35 --- --- localhost --- Storage & Snapshots RAID Group [Storage & Snapshots] Hot-removed disk "Host: 3.5" SATA HDD 2" from RAID group 2. Storage pool: 2.
Warning 2023-12-28 03:57:37 --- --- localhost --- Storage & Snapshots RAID Group [Storage & Snapshots] RAID group "2" is degraded. Storage pool: 2.b) am 29.12 dann auf HDD1 das erste mal Lesefehler, ohne dass die Platte rausgenommen wurde.
Warning 2023-12-29 01:45:33 --- --- localhost --- Hardware Status I/O Ports [Hardware Status] "Host: 3.5" SATA HDD 1": Read I/O error, "UNRECOVERED READ ERROR ", sense_key=0x3, asc=0x11, ascq=0x4, CDB=88 00 00 00 00 00 06 68 a9 a0 00 00 00 68 00 00 ..
Warning 2023-12-29 01:45:33 --- --- localhost --- Hardware Status I/O Ports [Hardware Status] "Host: 3.5" SATA HDD 1": Medium error. Run a bad block scan on the drive. Replace the drive if the error persists.
Warning 2023-12-29 02:15:51 --- --- localhost --- Hardware Status I/O Ports [Hardware Status] "Host: 3.5" SATA HDD 1": Read I/O error, "UNRECOVERED READ ERROR ", sense_key=0x3, asc=0x11, ascq=0x4, CDB=88 00 00 00 00 00 06 69 15 e8 00 00 00 68 00 00 ..
Warning 2023-12-29 02:15:51 --- --- localhost --- Hardware Status I/O Ports [Hardware Status] "Host: 3.5" SATA HDD 1": Medium error. Run a bad block scan on the drive. Replace the drive if the error persists.c) am 30. dann auf HDD1 (HDD2 meldet im täglichen SMART "fatal Error", weil nicht da) nach dem SMART:
Warning 2023-12-30 00:02:25 --- --- localhost --- --- --- [Disk S.M.A.R.T.] Host: 3.5" SATA HDD 1 still has warning/error condition. Please check summary page.Das wiederholt sich dann die nächsten tage so weiter, ohne Lesefehler.
d) Beginnend am 03,01 um etwa drei Uhr nachts (da läuft eine RTRR Replikation mit der NAS als Ziel) im Abstand von ca. 30 Minuten Lesefehler auf HDD1, Lesefehler werden dann den Tag über weniger, aber in der Nacht vom 04.01, kommen sie wieder massiv.
e) am 04.01. morgens kurz vor halbsieben dann folgendes:
Warning 2024-01-04 06:22:48 --- --- localhost --- Hardware Status I/O Ports [Hardware Status] "Host: 3.5" SATA HDD 1": Read I/O error, "UNRECOVERED READ ERROR ", sense_key=0x3, asc=0x11, ascq=0x4, CDB=88 00 00 00 00 00 04 b3 ec 70 00 00 00 68 00 00 ..
Warning 2024-01-04 06:22:48 --- --- localhost --- Hardware Status I/O Ports [Hardware Status] "Host: 3.5" SATA HDD 1": Medium error. Run a bad block scan on the drive. Replace the drive if the error persists.
Information 2024-01-04 06:49:32 --- --- localhost --- Storage & Snapshots RAID Group [Storage & Snapshots] Hot-removed disk "Host: 3.5" SATA HDD 1" from RAID group 2. Storage pool: 2.
Error 2024-01-04 06:49:33 --- --- localhost --- Storage & Snapshots RAID Group [Storage & Snapshots] RAID group "2" is inactive. Storage pool: 2.
Information 2024-01-04 06:51:07 --- --- localhost --- Virtualization Station Application [Virtualization Station] Started VM "SRV-Homebackup" automatically.
Gegen 9 hab ich das Ganuze bemerkt und hab dann gesehen, dass HDD1 und HDD2 mit Fehler markiert waren.
Rausziehen und reinstecken hat nix gebracht.
Durch einen Tipp habe ich dann in einer .conf Datei bei den beiden betreffenden Platten eine pd_err_*** Zeile entdeckt und geöscht.
Danach Systemneustart und das RAID war wieder da.
Nächste Erkenntnis :
f) im SMART hat die HDD1 eine extremn hohe RAW_Error_Rate (ID1) und unter knapp 200 Current_Pending_Sector (ID197) , HDD2 hat unter der ID1 den Wert 1, under der ID197 den Wert 0
Da HDD2 schon mehrere Tage aus dem RAID draußen war hab ich die dann gezogen und durch eine neue ersetzt.
Beobachtung:
g) Rebuld startet,, danach ist der Pool aber in Degraded.
e) ich hab dann auf das "degraded" geklickt und dann kommt ja dieser Dialog mit "Cancel/Rebuild) und da hab ich dann auf Rebuild geklickt. Der startete dann auch (wieder auf der HDD2, warum, die wurde dch eben schon wiederhergestellt) und als der Rebuld feritg war startete der Sekunden später erneut....
Während des Rebuilds (auch schon beim Ersten) gibt es eine Phase bei der die Rebuildrate massiv ainbricht (von knapp 100MB/s auf wenige hunder kB/s) und die Latenz auf der HDD1 geht massiv hoch; auf mehrere Sekunden 
Einträge mit Lesefehlern sind die Folge, die beiden Zähler im SMART gehen hoch.
So....danke schonmal bis hierher fürs Lesen.
Nun kommen meine Annahmen und Fragezeichen:
I) Lesefehler können vorkommen, okay, aber warum wird bereits nach einem Lesefehler HDD2 aus dem RAID genommen und noch dazu mit einer INFO ?!?!? (Punkt a) )
III) bei b) und c) scheint man dann wohl gut zu sehen, dass HDD1 langsam stirbt, also erstmal i.O.
Warum wird die aber trotz zig Lesefehlern nicht aus dem RAID genommen? Versucht das OS hier das RAID so lange wie möglich am Leben zu halten?
IV) Dass HDD1 dann irgendwann nimmer kann ist erstmalö okay, hat ja lange genug um Hilfe gerufen.
V) Warum startet das Rebuild (immer auf der neu gesteckten HDD2?
Hatte das Phönomen schonmal jemand.
Gibt es eine andere Alternative, als den Pool zu killen und neu aufzusetzen (dann natürlich mit neuen Platten...)?
Backup ist vorhanden.
Danke für jede Hilfe
S.
Bei mir wird da ne tmp datei runtergeladen....
Hmm okay.
Hab jetzt folgendes gemacht:
- über die GUI (Helpdesk) gestartet
- abgemeldet
- nach 45 Minuten wieder angemeldet und in den Helpdesk rein
- Test lief noch, also beendet.
TMP File ist leer....
Scheinbar mache ich da was falsch...
S.
HI zusammen,
ich versuche bei meiner TS473 rauszubekommen, warum die HDDs nicht in den Standby gehen.
Im Helpdesk habe ich den HDD Standby Test gestartet und da wird nun seit ner Stunde angezeigt, dass der Test läuft.
Hab ich da was falsch gemacht?
Wie lange läuft der Test denn?
Oder andersrum gefragt: Ist das der richtige Weg oder gibt es einen besseren ?
Danke
S.
Anthracite ja mag sein dass man da Skripte schreiben kann. Nur nicht jeder ist der Mega Linux Crack dem das leicht fällt. Ich bin da nicht so firm drin und deshalb sind mir die csv wichtig.
Ich hab nun tatsächlich mal den Versuch gemacht, bei 2 lokalen Synchronisationen (von einem NAS auf ein zweites via LAN) das Ganze via RTRR zu machen.
Das ganze als Pull-Job.
Protokoll wird nun erstellt, allerdings muss ich da nochmal tiefer reinschauen (generell, nicht in das Protokoll) denn
- die Benachrichtigung kommt nur vom Source-NAS (dort ist das ein incoming Job). Das Ziel NAS (das den Job startet) schweigt sich noch etwas aus, kann aber eine Einstellung im NotificationCenter sein,
- wenn ich die Komprimierung einschalte bricht die Transferrate drastisch (!!) ein. von im Schnitt knapp 90MB/s auf 20MB/s. Ich müsste es mal über eine künstlich bandbreitenbegrenzte Verbindung testen, ob es sich da lohnen würde. bei GBit LAN scheinbar nicht. Die CPUs langweilen sich aber bei so 20% Last...also die scheinen nicht der limitierende Faktor zu sein.
Falls die Frage aufkommt "warum Pull?": weil es das Power Management leider nicht schnallt, dass nicht runtergefahren werden darf, wenn ein Job läuft, der nicht selbst gestartet wurde.
Mod: Unnötiges Volltext-/Direktzitat entfernt! 
Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
denkbar aber nicht für statistiken geeignet....
csv dateien finde ichda schon angenehmer
Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Hmm ich hab eben mal wieder in den FAQs bei QNAP gestöbert und eventuell könnte es da ne Erklärung geben...
Scheinbar muss man die Option bei RTRR abschalten.....unlogisch, aber ich werde es mal versuchen....
S.
Okay danke für die Bestätigung.
Ist halt seltsam, dass ich bei einem RSYNC Job da etwas konfigurieren kann, das dann keinerlei Auswirkungen hat,
Aber das ist bei QNAP ja nicht neu
Dann passt ja alles.
Wäre halt mal spannend gewesen, auch bei einem RSYNC Job diese Daten zu bekommen um zu sehen, welche Daten am häufigsten verändert werden und so...
Und nein, auf einen RTRR kann ich leider nicht umsteigen, da dort die Dateien immer komplett und nicht nur die inkrementellen Änderungen übertragen werden.
Das ist über einen VPN Tunnel sehr unangenehm wegen der Bandbreite
S.