Beiträge von Variag

    Hallo die Runde,


    plötzlich war mein Mac nicht mehr am Internet. OK, nach kurzer Prüfung ist kein Ethernet verbunden -> beim Switch geschaut und die Power Leuchte sowie alle Link-LEDS blinken gleichmässig rhythmisch. Strom aus / an hilft leider nicht. Netzteil oder Switch sind kaputt. :cursing:

    Ist euch sowas schon mal passiert?

    Der Switch ist knapp 3 Jahr alt und war nie so super heiß. Zum Zeitpunkt des Ausfalls war gar keine Last.

    Habe jetzt den Nachfolger R2 bestellt.

    Strange, nach dem Downgrade musste ich erst den Mac rebooten bevor ich die Shares wieder mounten konnte. Ich werde noch mal die 5.2.5 ausprobieren.


    OK, false Alert. Nachdem ich meinen Mac neu gebootet hatte gibt es keine Probleme mehr mit dem mounten von Freigaben, Wieder mal was neues.

    Heute morgen habe ich meine Backup NAS auf QTS 5.2.5 aktualisiert. Nach dem Reboot ist es nicht mehr möglich, Shares via SMB auf meinem Mac zu mounten!


    TS-664

    MacOS Sequoia 15.5


    Bereits das Anklicken der Turbostation führt zu keiner Reaktion, d.h. keine Anzeige der verfügbaren Shares.

    Mounten via QFinder läuft auf endlosem "Bitte warten".


    Spielen mit den SMB Settings (i.e. Multi Channel, ...) führt zu keiner Änderung.


    Mounten via Windows oder anderer NAS kein Problem.


    Werde jetzt erst mal ein Ticket machen und dann zurück auf 5.2.4 gehen.

    Antwort von ChatGPT:


    Also möglicherweise keine FARM-Werte bei Ironwolf (ohne Pro)?

    OK, man kann mit etwas Mühe auch die FARM-Werte von Seagate HDDs direkt im eingebauten Zustand in der QNAP prüfen. Und zwar wie folgt:


    1. MyQNAP-Repo einbinden -> https://www.myqnap.org/install-the-repo/

    2. OpenSeachest (CLI) via App Center installieren -> https://www.myqnap.org/product/openseachest-cli/

    3. Shell via SSH auf der NAS öffnen

    4. Device-Namen der HDDs auslesen:

    5. FARM logs speichern:

    Code
    openSeaChest_Logs -d /dev/sg1 --farm --logmode pipe

    6. Die erzeugte Datei SERIALNO_FARM_DATUM.bin auf einen Windows Rechner kopieren

    7. OpenSeaChestParser herunter laden und auf Windows Rechner entpacken: https://github.com/Seagate/ope…leases/tag/Release_24.5.1

    8. Log parsen:

    Code
    X:\>SeaChest_LogParser_FARM_x64.exe --inputLog XXXXXXXX_FARM_20250203T144540.bin --printType text

    9. Finally, in der nun erzeugten Datei öffnen und die Werte prüfen:

    Code
    03.02.2025  14:56            13.951 XXXXXXXX2_FARM_20250203T144540.txt
    
        },
        "Drive Information From Farm Log copy 0" : {
            "Model Number" : "ST22000NT001-3LS101",
            "Power on Hour" : 1293,
            "Spindle Power on hours" : 1293,
            "Head Flight Hours - Actuator 0" : 1293,
             "Year of Assembled" : "23",
            "Week of Assembled" : "33",

    Sind davon auch IronWolf HDD betroffen? Leider scheint smartctl für die Ironwolf bei QNAP nicht zu tun:


    So, ich bin jetzt wie folgt vorgegangen:

    1. TS-664 herunter gefahren
    2. Alte Platten aus- und die Platten aus der alten TS-653D eingebaut
    3. Neu gestartet. Das SSD-Raid1 bleibt das Systemlaufwerk
    4. Aber: die neuen Platten wurden als LEER identifiziert, also:
    5. Speicher&Snapshots > Datenträger > Wiederherstellen > Speicherpool verbinden und wiederherstellen
    6. Das Raid wurde jetzt korrekt identifiziert und eingebunden
    7. Nach Tests und Reboots bleibt alles stabil

    Fazit: Es stellt kein Problem dar, wenn sich mehrere System-Volume im System befinden. Das erste existierende Volume bleibt das System Volume. Mounts & Filesysteme usw. sind alle wie erwartet, es existieren keine Doppelstrukturen. Lediglich einige Ordner sind auf dem ehemaligen System-Volume zu löschen: .qpgk, homes, Web usw.

    Ich habe eine TS-664 NAS mit 2 x 1 TB SSD Raid 1 als System Volume und 6 x 8 TB HDD als Raid5. Als Backup NAS verwende ich eine TS-653D mit 4 x 20 TB HDD.

    Ich möchte nun die TS-664 mit den 4 x 20 TB HDD in Zukunft als Backup NAS verwenden und die TS-653D mit den 6 x 8 TB HDD dann verkaufen.

    Die SSDs als System Volume sollen bleiben. Kann ich einfach die 4 HDD von der TS-653D in die TS-664 umstecken? Laut NAS Migration auf der QNAP Web Seite geht es.

    Aber kann es zu Problemen kommen, weil die SSDs in der neuen NAS ja als System Volume bleiben und das Raid auf den HHDs sich ja auch für ein System Volume hält??? :handbuch:

    Wie ist eure Erfahrung.


    P.S.: Backups sind vorhanden :cup:

    Laut dem verlinkten Test sollten die EXOS X20 im Idle schon sehr leise und unter Last im noch im besseren Drittel. Auf jedenfall deutlich leiser als meine 8TB WD80EFAX. Leider ist eine X16 nicht dabei, aber die Zwischengeneration X18 wäre lauter als die X20.


    Nach den Herstellerangaben sollten die ganzen EXOS X-Serien aber eigentlich gleich laut sein. Die leiseste moderne Platte wäre demnach die Ironwolf Pro 20 TB, die aber preislicht 30% teurer ist als die EXOS X20 20TB.


    Der Originalartikel ist mittlerweile von QNAP gelöscht worden.


    Hier die alte Version der Seite in der Wayback Machine:


    Is it possible to get the data back from an external USB drive (NTFS filesystem, used as backup) with AES 256 bit encryption in case of a NAS failure? How?
    The easiest way to access files on a USB device that was encrypted in a QNAP NAS is to simply use another QNAP NAS to do so. We understand many of our…
    web.archive.org