Beiträge von blub

JonnyRocket

Klar kann man die abermillionen Einzeldateien auf ein SMB share legen, gehen tut das. Wie sichert Ihr das SMB share denn? - das wäre dann ja auf HW Ebene eine Kopier/Sync-Aktion von zig-millionen Dateien die alle sehr klein sind, so grob bei uns wären das 70 Millionen die man auslagern würde - das zu sichern, sagen wir mal von primären SMB auf ein zweites NAS dauert doch Wochen bis Monate. Auchein Sync alle X Tage würde sehr lange dauern da alle Ordner dann ja rekursiv verglichen werden müssten.

Das letzte mal auf HW Ebene habe ich sowas vor 6-7 Jahren kopiert, das dauerte mit robocopy übers Netzwerk knapp 4 Wochen - wenn ich die Dateien in einem VHDX Container habe dauert das kopieren auf Hahrdwarebene keine 2 Tage, auch die täglichen backups incrementell sind nach 1 Stunde durch - ich sehe ein einer Speicherung von abermillionen Dateien auf einem SMB share keine Vorteile

Das Problem mit der 16TB Grenze ist sicherlich bei ext4 gegeben, bei ReFS, ZFS und BTRFS nicht, auch bei NTFS nicht - ein so großer Nachteil ist das also nicht. Die Alternative wäre eben das Archiv in mehrere VHDX zu trennen, zb jede max 14TB - habe ich aber damals versäumt. Wurde vom PACS anbieter aber auch nicht empfohlen.

Man kann nie alles in extenso testen, da ist klar.

In dem Fall ist es aber so dass dort physikalisch wenig Platz ist, das hätte wenig Test gebraucht sondern primär ein geschultes Auge "das ist knapp" - das es ein Problem ist weiss Qnap, sonst gäbe es die Folien nicht - ärgerlich ist nur dass ich jetzt auf 1 oder ggf 2 HDDs sitze weil Qnap sagt "ist nicht unser Problem" obwohl es eindeutig ein Problem des NAS ist: der Tray ist zu knapp bemessen oder Fertigungstoleranz zu hoch oder man hat die Folie schlicht vergessen

Zitat von tiermutter

Tja... teste mal "Kompatibilität".

Das stimmt, aber ich glaube in dem Fall hätte Mathe /ausmessen gereicht

Zitat von tiermutter

Dann wäre es schon eine NAS-Disk Kombination, die erforderlich ist um das Problem zu bekommen.

Das stimmt, bei den 6TB oder so war die Platine ja meist 3-5mm tief in der HDD drin - die Disk waren alle 8TB+ , die neuesten waren 18TB

Um solche Fälle abzudecken gibt es aber die HDD Kompatibilitästliste, da könnte man ohne weiteres alle entsprechenden Modell mit einem Vermerk versehen "kontaktieren Sie uns für die notwendigen Mylar Folien" - ist aber leider nicht der Fall

Zitat von dr_mike

Die allermeisten NAS haben heut Kunststofftrays, da kann das nicht passieren.

Kann gut sein, bei den Qnap 8 bay war es aber zumindest bis Ende 2022 Metall und auch bei Supermicro Server ist es nach wie vor Metall - ist aber wahrscheinlich sehr verschieden.

Zitat von Crazyhorse

Dazu kommt die Rack Kisten laufen meist mit Fullservice, geht das drauf kommt es halt neu.

Die paar Ausfälle die wir sonst so hatten haben wir auch immer direkt getauscht, das war mit Arbeitszeit und RMA billiger einfach neu zu machen - aber als dann 3 nagelneu HDDs das zeitliche segneten und dann gleich nochmal 2, das war dann doch zu viel - in der rate würde das auf 5 Jahre über 20 neue HDDs geben, da wirds dann schon teuer

Zitat von tiermutter

Die Trays mag ich auch lieber

Definitiv, da kann man die HDDs einfach rein-klicken, das spart viiieel Zeit

Zitat von tiermutter

Ich gebe zu, dass ich zunächst auch an Fakepropaganda gedacht habe, letztlich ist das aber alles schlüssig für mich.

Danke.

Ich glaube dass es schlicht eine Fertigungstoleranz der Trays ist, da ist es so eng da reicht eine kleine Materialunebenheit schon aus und man ist so nah dran dass bei Betriebstemperatur dann Kontakt zur Platine besteht. Alternativ wurde eben an der Folie gespart nach dem Motto "das passt schon"...

Es ist wahrscheinlich auch richtig dass die Mehrheit hier diese NAS nicht verwendet sondern eher 4 oder 6 Bay Modelle im Einsatz hat - und da fällt mir auch ein dass unser 3. NAS auch nur 4 Bay ist und die Trays aus Plastik sind.

Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Es ist immer einfach irgendwas als BS abzutun, ich bin durchaus lernfähig und akzeptiere auch eine andere Erklärung.

Wenn das BS ist, dann erkläre mir bitte warum - bitte erkläre mir auch warum diese Mylar Aufkleber das Problem gelöst haben und seither keine einzige Disk aus dem Verbund gefallen ist und auch nicht gestorben ist.
Mylar ist so hauchdünn das hat 0 "NULL" vibrationsdämpfende Wirkung, wie können Vibrationen eine HDD so zerstören dass diese gar nicht mehr erkannt wird, also elektrisch tot ist - das geht eigentlich nur per ESD/Kurzschluss.

Bitte erkläre mir bitte auch warum Qnap sofort weiss worum es geht und sagt das meine Disks sich laut dem log "connecten und diconnecten" obwohl gar kein Log vorlag.

Nochmal: in NAS 2 sind in wenigen Monaten von insgesamt 14 eingesetzten Disks 5 gestorben komplett Tod, das waren 2 verschiedene Festplatten Hersteller

Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

das ist oft der Fall wenn das Problem gelöst ist, die Leute melde sich nicht mehr - NAS Modelle oben eingefügt

Ich lade nachher noch Fotos hoch, da kann man erkennen das da kein mm Platz ist zwischen Tray und HDD - muss die aber erstmal suchen und auf NB laden

Bilder hochgeladen

Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Klar, ich hab nix bessere zu tun, deswegen ist auch der Link für das Installationsvideo mit auf dem Screenshot weil ich nix besseres zu tun habe im Leben - was habe ich davon?

Die Vermutung gab es auch mal im englischen Forum:
https://forum.qnap.com/viewtopic.php?t=167045

Hallo

Hier eine Information und auch Warnung für Personen die mit Qnap NAS ungewöhnlich oft HDDs haben die aus dem RAID fallen (dropped disk) und/oder im NAS einen hohe Ausfallrate der HDDs haben (also defekte HDDs).

Qnap NAS können HDDs killen!

Betroffen sind HDD Cages die keine Folie auf der Innenseite zur elektrischen Isolierungen haben.

Folge ist dass die HDDs mit der Platine zu nah am HDD-Tray sind und es dann unter bestimmten Umständen wie Wärme und elektrische Bedingungen zu einem Kurzschluss kommt.

In wie weit auch die verwendeten HDDs oder eine bestimmte Revision der HDD-Trays eine Rolle spielen kann ich nur bedingt sagen, aber bei uns trat das Problem bei Toshiba und WD auf.

Wir hatten bei einem NAS (1) ständig disk-drops (dazu hatte ich auch hier gepostet) und dachten zuerst das Backplane wäre defekt.

An einem anderen NAS (2) hatten wir von 6 nagelneuen WD Reds 3 Ausfälle in 6 Monaten, hier dachten wir zuerst an einen Transportschaden/schlechten HDD Batch.

Für NAS 2 hatte wir dann kurzerhand neue, aber auch größere HDDs gekauft, aber kaum waren die installiert vielen nach 1 und nach 3 Wochen schon wieder 2 nagelneue HDDs die komplett "elektrisch tot waren" - das war dann der Punkt wo mir klar war dass hier was nicht stimmen kann.

Der Qnap Support antwortetet relativ schnell, direkt mit (sinngemäß) "anhand der von Ihnen zur Verfügung gestellten Logs handelt es sich um Vibrationen .... dies kann durch Maylar Aufkleber behoben werden".

So wer ein wenig Ahnung hat dem Fällt auf, dass Mylar zum elektrischen isolieren und nicht Dämpfen von Vibrationen gedacht ist und zum anderen hatte ich keine Logs hochgeladen und auf das Problem dass ich 5 defekte, also physikalisch kaputte HDDs ein einem NAS hatte wurde erst gar nicht eingegangen! (Anhang: Antwort des Supports als Screenshot)
Die Aussage des Supports war also kompletter BS, er wusste sofort was los war aber die Ursache wird verschleiert.

Darauf angesprochen verstummte der Support relativ schnell und sagte nur dass dieses Problem mit Vibrationen nur einen gewisses Produktionsdatum betrifft. Auf die Bitte die HDD zu ersetzen ging der Support nicht ein, auch nicht nachdem ich sagte das mein Hänler nach der letzten Reklamation der HDD keine weiter mehr annimmt - der Händler geht inzwischen davon aus dass ich/wir total doof sind und keine NAS zusammenbauen können (Retourenrate über 40%).

Lösung:

Die Mylar Sticker brauchten per Post relativ lange von Qnap, daher hatte ich mir zuerst mit ausgeschnittenem Papier (leitet ja auch nicht) beholfen - seither keine Defekte oder aus dem Verbund gefallen HDD - das Problem war damit ganz einfach gelöst.

Fazit:

Es ist schon bitter das Qnap von einem solchen Problem weiss, keine Meldung/Rückruf macht um das Problem zu beheben/Hilfe anzubieten und die Kunden dann auf defekten HDDs sitzen lässt - und ja alle HDDs waren aus der Kompatibilitätsliste

Edit:

Der Link von Qnap zur Installation der Folien:

10.46 MB file on MEGA

mega.nz

NAS 1: 863U RP - Kaufdatum Jan 2019

NAS 2: 873AU - Kaufdatum 03/2022

Zitat von Anthracite

Wäre es da nicht besser, man nimmt nur eine kleine VHDX, in der das Betriebssystem der VM liegt, nicht aber die Bilder des PACS-Systems? Die Bilder legt man stattdessen direkt auf SMB- oder NFS-Freigaben des NAS ab, welche von der VM gemounted werden.

Man kann das machen - das hat aber den eklatanten Nachteil das man auf BareMetal Ebene knapp 200 Millionen Dateien in größen zwischen 4kb-15mb dort rumliegen hat.

Diese dann zu sichern/klonen oder nach X Jahren auf ein neue SAN zu kopieren ist ein absoluter Alptraum - schonmal 200M Dateien kopiert? - das Dauert Monate! Der Umzug vom alten Server damals dauerte ohne verifizierung schon 6 Wochen, bei meinem alten Arbeitgeber der ein größeres Archiv hatte dauerte der Umzug vom alten auf das neu SAN über 12 Monate (das war so zeitintensiv, auch in der Kontrolle, das es an ein externes Unternehmen ausgelagert wurde).

Selbst ein inkrementelles Backup, also einmal kopieren und dann nur neue Dateien sichern ist ein Alptraum - da wird ja jedes Mal/abends die gesamte Ordnerstruktur nach neuen Dateien durchkämmt, alleine das dauert bei dieser Anzahl auf unseren SSD etwa 4-6 Stunden (wenn wir mal sehen wollen wieviele Dateien wir haben) - und dann stell die das mal auf drehendem Rost und mit Netzwerklatenz vor, da schaffts Du nicht mal 1 Backup pro Woche.... - und die ganze Zeit wenn das Läuft ist der Pool/San beschäftigt und die Latenz für die User geht den Bach runter

Demgegenüber steht aktuell eine Kopiezeit von 10 Stunden für alles bei "nur" 10Gbs

Zitat von Crazyhorse

32TB bei PACS, das ja nix, die üblichen Archive Kisten lieben aktuell bei 96-128TB, doch selbst das reicht nicht für die komplette Vorhaltezeit bei dem aktuellen Zuwachsraten.

Die 32TB sind aktuell ca 10 Jahre, wir könnten also 20 Jahre locker abbilden ohne was auszulagern da wir nicht so "groß sind" - wenn ich an meinen alten Arbeitgeber denke der alles nach 3 Jahren ausgelagert hat und dann diese Altadten nicht mehr oder erst nach 3-5 Tagen wieder reinkamen wenn man sie "angefragt" hat ist dieses Auslagern ein Alptraum, das halte ich eher für Fluch als Segen - ich meine bei tiered storage, was sind schon 120TB?

Man kann kleinere LUNs machen, klar, zumindest seitens der PACS Anbieter hiess es dass es sich nicht lohnt es klein zu machen wobei man die 64TB Grenze nicht ganz ausreizen sollte - Fakt ist dass wenn der HyperV crasht und man vom Backup wiederherstellen muss so oder so alles kopiert werden muss, ob das dann 10 x 4TB vhdx sind oder 1x 40TB ist da hinfällig - da man ja "boot from Backup hat" ist die Zeit für die wiederherstellung nicht so relevant

Zitat von Crazyhorse

Aber vor allem stelle ich es mir schwer vor, eine 32TB Datei regelmäßig übers WAN weg zu schieben um eine Offsite Sicherung zu haben, bei GBit sind das um die 3 Tage.

Jetzt komme mit nicht mit so einer Init7 Leitung, bei der ist aktuell vermutlich eher das LAN die Bremse.

Wenn ich 10 x 4TB vhdx habe muss initial so oder so alles kopiert werden, bei einem VM Backup wie wir es mit Veeam/Altaro es machen ist alles inkrementell, da wird auch nur am Anfang alles 1 Mal kopiert, da ist es doch vollkommen egal ob das 1 x 40TB oder 10 x 4 TB sind.... - dafür reicht aktuell unsere Glas 400/400 aus

Fun Fact:

Sowohl Veeam als auch Altaro benötigen für ein volles Backup 9-11 Tage mit einem 10GB Netzwerk - limitierend ist die Kompression und vor allem die Deduplication von Veeam/Altaro, die sind nicht so schnell...

Zitat von Becker2020

Aber evtl. ist das unbekannte NAS doch eine Nummer zu klein für die große Aufgabe.

Das unbekannte NAS ist ein 873AU - das macht aber nix anderes als jede Nacht ein paar 100GB für unsere 8 VMs inkrementell entgegenzunehmen - für diese Aufgabe ist eigentlich kein NAS zu klein, wo siehst Du hier das Problem?

Das einzige Problem war dass QTS mit ext4 die große VM nicht auf ein SMB share annehmen kann, das geht dann leider nur per iSCSI. Letzteres macht das Setup für VM Backups ein wenig komplexer da auch im Falle einer Widerherstellung das iSCSI extra eingebunden werden muss inkl. Zugriffrechte am NAS per IP usw - da ist es per SMB schon "schöner" und daher wollte ich auf QuTS HERO wechseln da es diese Limitation hier nicht gibt

Zitat von mad99

Aus reiner Neugier, wie kommt man an eine 32TB große Datei?

Zitat von Crazyhorse

Ist das ein Bqckup Container, der die Größe erreicht?

Ist ine VHDX einer VM, mit viiiiel Speicherbedarf, in unserem Fall der Betrieb eines PACS System wo Bilder gespeichert werden, altuell ca 180-200 Millionen.

Wenn ich mich für eine VM um 32 einzelnde VHDx Dateien kümmern muss und bei 1TB pro Jahr 3 dazukämen würde es verdammt unübersichtlcih werden......

Zitat von FSC830

Jo, selbst QTS hat keine Beschränkung auf 16TB

Das ist nicht korrekt, bzw muss differenziert werden, QTS verwendet ext4:

Partition über 16TB - JA

Einzelne Datei über 16TB: NEIN

https://www.qnap.com/en/how-to…e-i-can-save-onto-the-qts (der Link wurde erstellt nach meiner Supportanfrage 2021 )

What are the file and file system size limitations for Red Hat Enterprise Linux? - Red Hat Customer Portal

What are the file and file system size limitations for Red Hat Enterprise Linux? Are GFS2 file systems over 25 TB supported? Is it possible to use Ext3 for…

access.redhat.com

Zitat von Becker2020

Zum Bearbeiten einer 32TB Datei braucht der Rechner auch den entsprechenden Arbeitsspeicher. Dies dürfte nicht bezahlbar sein, bzw. technisch nicht möglich.

Ähh was?

Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Ja korrekt, ist geändert

Guten Morgen zusammen

Ich habe ein NAS das ich mal auf QTS-Hero umgestellt habe um hoffentlich das 16TB Dateilimit von ext4 bei Qnap zu umgehen - in letzterem darf eine Datei im SMB share 16TB nicht überschreiten und da habe ich halt eine mit 32TB.

Jetzt will QTS immer beim erstellen eines share die Blcksize wissen und da ist mir nciht ganz klar was ich nehmen sollte.

Share 1: Backup einer Datenbank (260GB) und ca 1M kleinere Dateien zwischen 10kb und 6mb - die kleinen mit kleiner 1MB überwiegen - hier dachte ich eher 32kb als Blocksize!?

Share 2: VM Backup (Altaro), das sind ja große Dateien - der default ist ja 128kb, aber wenn ich mich recht erinnere wird ja bei Veeam 64 oder 32kb empfohlen

Danke

Zitat von Mavalok2

Wie oft wurden die Festplatten aus- und wieder eingebaut? SATA-Anschlüssen stehen nur eine geringe Anzahl von ein- und ausbauen zur Verfügung. Hersteller reden da gerne von 50 bis 100 Zyklen. Wenn so ein Anschluss als Wechselfestplatte verwendet wurde...

Ach jede im Schnitt vielleicht 4-7 mal, das kann es nicht sein.

Ich habe zum einen von der Komp-Liste WD Reds und Pro's als auch Toshibas, passiert mit beiden. Auch die ein oder ander WD Gold habe ich dabei, ist bei denen auch. Selbst der Slot im NAS variiert, mal ist es 1, dann 5 dann 8 - da ist kein System drin, es wird ganz sicher nicht an der HDD liegen, no way.

1 Standort ist ein klimatisierter Serverraum, der andere ist ein "normaler" Keller mit Rack, etwas wäremer mit 25/26 grad aber voll "in der Spezifikation", keine goßen Strassen für Vibration etc - es wird mit 99,99999999% am NAS liegen.

Unabhängig davon ärger mich das am 863RP die QTS 5 im RAID 5 nur 40-80mb/s schafft, in QTS 4 sind 250-360mb/s - alles zusammen ist auf Dauer eine Zumutung, dann Wechsel ich eben mal den Hersteller

Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Damit wollte ich nur sagen: Was bringt es mir ewig mit dem Support rum zu machen wenn das was der mir sagt ich schon selbst probiert habe - in Bezug auf Deine Frage voher: "schon mal den Support gefragt?"

Fakt ist das zumindest ich mit Qnap in den letzten 6 Jahren ausnahmslos Probleme gehabt habe und das es allem anschein nach auch 2022/23 noch immer Probleme mit den Backplanes gibt - der Threadersteller hat ein ähnliches Problem. Ich mag Qnap und hatte immer gute Erfahrungen, aber auf das Lotteriespiel lasse ich mich nciht nochmal ein...

Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Alles Neuinstallation ohne irgendeine Migration, 3 verschiedene Standorte, an der Stromversorgung kann es also auch nicht liegen - woran kann es sonst liegen ausser an der inzwischen miserablen Qualität von Qnap?

Zitat von dolbyman

Und Herr/Frau blub hat auch Tickets bei QNAP zu den Problemen aufgemacht ?

Das aus 2016 ging als RMA zurück, das Austauschgerät lief dann - was kaputt war wurde mir nie gesagt

Zu den beiden anderen:

Was bitte soll mir der Qnap Support sagen ausser: ist die HDD von Kompatibilitätsliste? -und dann:

1. "ja". Zurücksetzen auf fact. defaults (habe ich eh schon 2x gemacht) - danach kommt dann: Gerät einschicken

2. "nein" dann bauen Sie bitte HDDs aus der Kompatibilitätsliste ein, danach lande ich wieder bei 1.

Bevor ich Stundenlang mit dem Support meine Zeit verplemper tausche ich die Dinger einfach aus und sende die dann ein

meine 2c:

Modell aus 2016, weiss nciht mehr welches - HDDs flogen stnändig raus - war ein Backplane Problem

863U (ca 2018) + 14TB Toshiba - alle 8-12 Wochen fliegt eine HDD raus

873AU (2021/22) + WD Red 12 TB von der Kompatibilitätsliste - jede Woche fliegt eine raus

Ergo: nach mehr als 15 Jahren veranschiede ich mich von Qnap, so hält man keine Kunden