Gorosch

Gibt es aktuell wirklich noch jemanden, der über einen neuen Heimserver nachdenkt oder über ein Disk-/Hardware-Upgrade? In meinem System gibt noch ein Xenon E3-1230 v6 den Takt an zusammen mit 64 GB DDR4 ECC auf einem Supermicro X11SSM-F - gekauft und gebaut 2018 oder 2019. In manchen Momenten dachte ich schon mal, dass jetzt noch etwas mehr RAM (geht nur max 64 GB auf dem Board/CPU), ein paar Cores mehr oder der eine oder andere weitere PCI-E Slot doch noch von Vorteil wären. Im großen Ganzen macht das Setup aber nach acht Jahren eigentlich immer noch das, was es soll: ein paar Cloud und Mediendienste sowie ab und zu mal den einen oder anderen Gameserver. Und das gut und Zuverlässig - von ein paar einzelnen selbstverschuldeten Misskonfigurationen mal abgesehen. Ich kann es daher nicht oft genug sagen: Danke an diese Forum und die Community. Da acht Jahre für Serverhardware jetzt noch kein wirliches Alter ist, wird die Kiste hoffentlich noch ein paar Sonnenumrundungen seinen Dienst verrichten. Q2 2025 habe ich meine alten 4TB und 8 TB WD Red HDDs im Array gegen gegen 16 TB IronWolf Pro aufgerüstet bzw. erweitert. Also alle 4 TB HDD raus und gegen 16 TB getauscht. Da lagen die in dem Moment bei knapp 300 Euro. Macht aktuell 68 TB auf dem Array, wobei davon knapp 60% belegt sind. Wenn ich den aktuellen Film und Musikmarkt bezogen auf BluRay und CDs beachte, wird das wohl (leider) noch eine Weile reichen. Da somit die neueren, größeren Platten noch die nächsten 4 Jahre Garantie haben, werde ich diesbezüglich hoffentlich keine böseren Überaschungen erleben und hoffe einfach, dass sich der Markt bis dahin wieder halbwegs normalisieren wird. Was ich demnächchst auf Grund des Alters evtl. mal tauschen werde, ist das Netzteil. Dafür zahlt man aber im Moment noch keine Niere. Habt ihr gar schon mal überlegt Disks/RAM eures vorhanden Server zu verkaufen und erst in 2 Jahren (oder so ^^) wieder neu einzusteigen? Ich habe vor ein paar Tagen erst 32 GB RAM Set von G.Skill in meiner "Sammelkiste" gefunden, welche noch vom Upgrade auf 64 GB vor zwei Jahren meines AM4 Gaming PCs übrig geblieben ist. Gekauft damals für ca. 150 Euro, geht nun beu EBay für um die 300 Euro weg. Habe tatsächlich überlegt, die zu Geld zu machen. Aber Murphy sagt, wenn ich die jetzt verkaufe, gehen bestimmt meine jetztigen Riegel über den Jordan und habe dann keinen Ersatz. Somit bleiben die erst Mal auf Vorrat. Den Rest verkaufen? Niemals. So Geldgeil bin ich nicht, als dass ich mein Hobby zuhause verkaufen würde - auch wenn ich jeden Tag beruflich mit Servern und Netzwerken zu tun habe. Mit Kauf warten bis ... 2027? 2028? Die Playstation 6 soll ja doch 2027 kommen, vielleicht ein positives Signal? Keine Ahnung, ob das ein positives Signal ist. Vielleicht bin ich da zu pessimistisch. Andererseits sind Pessimisten ja Optimisten mit Erfahrung. ;) Sony hat nicht wirklich Einfluss auf die Preise von RAM. Wer weiß, ob ne PS6 nacher nicht schon die 1.000,- Euro Marke sprengt. Da es keine wirkliche Konkurenz mehr für Sony im Konsolenmarkt gibt (Steam Machine mal bewusst außen vor gelassen), können die da mittlerweile tun und machen, wie sie wollen. Ebenso könnte Sony auf die Idee kommen, die Kiste mit gerade soviel RAM auszurüsten, dass das eigene OS läuft und den Rest Modular zu machen - ähnlich wie das N64 früher mit dem Expansion Pack für mehr RAM. Also eben auch "Bring your own RAM" like - nur eben teuerer, weil vorgefertigte Module, die direkt in die Konsole geschoben werden können. Bei der PS5 Pro ist das optische Laufwerk mittlerweile ja auch nur noch optional. Meine Urpsprünglichen Pläne, meinen AM4 Gaming PC (5700X3D, 64 GB RAM, RTX 3080ti) dieses Jahr mal auf AM5 zu bringen, sind jedenfalls erst Mal auf Eis gelegt. Da ich aber auch nur in 2K spiele, ist das erst Mal nicht ganz so tragisch.

Alles richtig. Nichts anderes sag ich ja (5 MB/s mal hin oder her). ;) Wollte nur zum ausdruck bringen, dass die 80 MB/s beim schreiben nach einer Weile direkt aufs Array normal sind, wenn kein Cache oder RW genutzt werden. Deswegen auch der Verdacht, dass entweder der Cache und/oder der Share falsch konfiguriert sind. Zudem wurden wohl die Default Werte von Unraid bzgl. "vm.dirty" verändert. Denn zumindest am Anfang müsste er fast das ganze 1Gbit Limit erreichen (die von dir oben genannten Overheads usw. mal ausgenommen), da normalerweiße erst Mal in den RAM geschrieben wird, bevor es auf die Datenträger weiter geht und der Speed sich dann bei +/- 80 MB/s einpendelt (ohne RW/Cache). Wenn ich es richtig lese, startet der Transfer jedoch direkt bei 80 MB/s und fällt dann auf 15 MB/s ab. Daher der Verdacht mit SMR Array und evtl. SATA Port Multipliers. Das alles natürlich vorrausgesetzt, dass mit dem 1Gbit Netzwerk wirklich alles passt, nicht mit MTU rumgespielt wurde, usw.

Liest sich im Ganzen für mich so, als ob beim Upload auf Unraid die Daten nicht über den Cache laufen sondern direkt aufs Array gehen. Fehlerhafte Share Config usw. Da sind 80 MB/s für den Anfang je nach HDD "OK", aber immer noch weit weg von der 1Gbit auslastung (sollten um die 130 MB/s sein). Daher Tippe ich mal auf eine SMR HDD im Array - im dümmsten Falls als Parity. Oder aber irgendwelche billigen SATA Controller Karten, welche mit Port Multipliers arbeiten. Oder beides zusammen. Würde dann zumindest den Einbruch auf 15 MB/s erklären.

Sorry, konnte ich mir nicht verkeifen. Wer kennts noch? Um doch halbwegs was produktives bei zu tragen: Folgende Punkte schon gegen geprüft? https://docs.unraid.net/unraid-os/troubleshooting/common-issues/unclean-shutdowns/

Vorsicht, Scrutiny ist zwar toll, hat aber ab und zu eine komsiche Logik beim interpretieren der Werte (Seagate und Command Timeout 4295032833). Dennoch: bei Reallocated Sectors Count bei Samsung beobachten, ob die Werte steigen. Bisschen Schwund ist immer, sollte aber bei einer neuen SSD nicht der Fall sein. Ich hatte auch eine 1TB Samsung PM893 im Unraid Pool (single, xfs, Transcoding / Ripping Cache für MakeMKV. Emby und Tdarr), welche nach ein paar Wochen 20 Reallocated Sectors gemeldet hat, mit gerade mal 0,8 TBW. Dieser Wert stieg innerhalb eines Monats nach und und nach an. Am Ende hatte die SSD gerade mal 1.7 TBW und ist dann irgendwann mit über 190 Reallocated Sectors ausgestiegen. Abends noch gelaufen, am nächsten Tag kein Filesystem mehr gehabt (nur noch 1 GB). Da keine wichtigen Daten drauf lagen, habe ich es erst Mal gewähren lassen. Dennoch direkt am Anfang RMA beantragt mit bitte um Vorabtausch. Händler wollte natürlich erst die SSD haben, nur um dann zu erfahren, dass eine Reparatur nicht möglich ist und ich das Geld zurück bekomme. War im August/September diesen Jahres. Also evtl. eine Faule Charge oderm so, keine Ahnung. So oder so: Wenn der Wert steigt, wichtige Daten von der Platte runter und auf jeden Fall RMA beantragen. Unraid meldet dies übrigens auch - auch ohne Scrutiny.

Was nutzt du als Firewall?

Das ist etwas heftig. Was sind das für Platten und wo sind die angeschlossen? Das sollte nach nem nem knappen Tag erledigt sein. 68 TB dauern bei mir ca. 1 1/2 Tage mit normalen SATA HDDs.

Deswegen ja der Punkt mit den "gewissen Diensten und Daten". Alles, was auf dem Cache ist, ist natürlich weg, wenn keine Redundanz vorhanden ist. Sowohl Appdata, Docker und Daten, welche noch nicht im Array liegen oder bewusst nur um Cache liegen. Zu deinen Fragen und wie es bei mir ist: habt ihr keinen Schreibcache auf den Shares für "wichtige" Daten konfiguriert? Ich habe zwei Cache Pools: 2x 256 GB SSDs für Docker und Appdata, 2x 4TB SSDs als Cache für das Array (alles SATA SSD mit jeweils RAID1 pro Pool Alle Shares führen immer zuerst auf den großen Cache. Manche Shares liegen auch nur auf dem Cache, wie z.B. meine Musik Sammlung für den Roon Server. Ziel ist es, so wenig wie möglich die Plattten hoch drehen zu lassen. wenn doch, wie oft läuft euer Mover oder ein anderes Backup solcher Daten? ich Nutze das Mover Tuning Plugin. Sobald der Cache auf 85% Vollläuft, werden die älteren Daten auf dem Cache in Array geschoben, bis der Cache wieder auf unter 60% fällt. Dies wird jeden Tag geprüft. Alle drei Monate wird jedoch alles immer zum 28. des Monats auf das Array verschoben, was da hin soll. Somit blieben neue Daten länger im Cache liegen, womit sie schneller abrufbar sind und ebenfalls wieder Spinups vermeidet. verschiebt ihr keine Daten auf den Server, sondern kopiert erstmal nur und löscht später auf der Quelle, wenn die Daten sicher(er) auf dem Array oder im Backup liegen? Ich verschiebe immer. Sowohl Linux als auch Windows kopiert ja im Hintergund dennoch erst mal nur und löscht die Quelle erst dann, wenn der "kopier" Vorgang erfolgreich war. Spart einem das manuelle löschen. oder ist unraid bei euch eh nur Backup für Daten, die noch woanders liegen? (DANN wäre mir die Schreibcache Redundanz auch egal, aber dann hätte ich auch keine parity) Unraid läuft bei als Datengrab für Mediensammlung, Bilder und Dokumente und auch als Medienserver. Somit sind für mich alle Daten wichtig, wen manche auch wichtiger, als andere. Gehen mal ein paar Filme verloren, kommt die BluRay aus dem Keller und wird neu gerippt. Bilder und Dokumente sind daher für mich wichtiger, da diese nicht einfach "neu" gemacht werden können. oder habt ihr keine für euch "wichtigen" Dateien? Wie oben schon erwähnt, ist für mich alles wichtig. Daher fahre ich diverse Backups, welche sich an die 3-2-1 Regel orentieren: 1 Backup auf einen extra NAS bei mir Zuhause - komplettes Array - jeden tag 1 Backup auf eine NAS bei meinen Eltern - Nur Dokumente, Bilder und Musiksammlung - jeden Tag 1 Backup verschlüsselt auf B2 Backblaze - Wöchentlich 1 Backup auf eine 5 TB USB HDD, ebenfalls jeden Tag. Wenn es im Notfall schnell gehen muss, wird die eben abgezogen und mitgenommen. Leicht Paranoid, wird hoffentlich nie solch einen Notfall geben. :)

Also auf die Begründung bin ich jetzt aber gespannt, warum die zweite Platte bei einem RAID 1 "Grütze" schreiben sollte, wenn es es die erste tut. Vorab: Ein RAID (außer RAID0) dient immer nur der Redundanz und ist kein Backup! Ein RAID Verbund immer von einem Controller gesteuert. Ob Hardware- oder Softwarebasis ist dabei erst Mal egal. Der Controller verteilt die Daten auf die Platten gemäß RAID Config (RAID1 = spieglen, RAID5 usw. = Striping. Wenn jetzt eine Platte aus welchen Gründen auch immer nur noch "Grütze" schreibt, erkennt dass der RAID Controller und schmeißt diese Platte aus dem RAID, womit dieser "degraded" ist. Die Daten sind jedoch immer noch durch die anderen Platten verfügbar. Nach deiner Logik (sofern ich dies richtig verstanden habe) werden die Daten erst auf eine Platte geschrieben und dann von dort auf die zweite Platte kopiert. Dies ist nicht der Fall. Macht ein RAID Pool für den Cache Sinn? Wenn es einem Wichtig ist, dass Docker, VMs und Daten verfügbar bleiben, wenn ein Cache Drive ausfällt, dann definitiv ja (dennoch nie die Backups vergessen!). Wenn es einem egal ist, dass für die Zeit bis zum Austausch der defekten Cache Disk und dem zurückspielen des Backups gewisse Dienste und Daten solange nicht verfügbar sind, dann brauch man definitiv keinen RAID. Bei einem RAID ist zudem noch eine USV zu empfehlen. BTRFS und RAID reagieren gerne empfindlich bei plötzlichem Stromverlust.

Also Energiesparen in allen Ehren, aber manche Sparen sich ihre Server zu Tode. Ich weiß nicht, wie Sinnvoll es ist, ein Grundlegendes Monitoring einer Serverkomponente abzuschalten, um 2,63 Euro im Jahr Strom zu sparen...ich weiß nicht. Prüfe lieber mal deine HDD Settings in Unraid.

Nutze seit Jahren B2 Backblaze mit Duplicacy als eine meiner Lösungen. Läuft seit Jahren ohne Probleme und regelmäßige Test Restores liefen auch immer sauber durch.

Unter "Apps -> Previous Apps -> Docker" kannst du bereits Installierte Docker wieder herstellen: Es wird dann jeweils das Docker Image der einzelnen Container geladen. Da die eigentlichen Konfigs unter appdata liegen und die Parameter der jeweiligen Conatiner in xml Dateien auf dem Stick liegen, bleiben die Einstellungen erhalten. Dennoch sei zu empfehlen, dass du prüfst, warum dir ein einzelner Docker alle anderen Docker Images zerschießen kann.

Servus, grundsätzlich ist die Parity kein Ersatz für ein Backup. Da du jedoch ein Backup hast, hast du dir Grundlegend schon mal die richtigen Gedanken dazu gemacht. Betrachte die Parity in deinem Falls als zusätzlichen Luxus. Die Gründe wurden schon genannt, daher nur zusammenfassend: Auch bei Ausfalls einer durch die Parity abgedeckten Festplatte bleiben alle Daten verfügbar. Du hast also keine längere Downtime durch den Austausch der Festplatte und dem zurück sichern Unraid weiß, welche Daten auf welcher Festplatte liegen. Also für dich ein "run and forget" System. Fällt eine Platte aus und wird ersetzt, stellt Unraid aus der Parity die fehlenden Daten der defekten Festplatte ohne dein zu tun wieder her. Du muss also nicht selber prüfen, welche Daten wo liegen und welche nun wieder aus einem Backup wiederhergestellt werden müssen. Genauso wenig muss du dir dadurch komplexe Backup Strategien überlegen, damit du selbst den Durchblick nicht verlierst. Selbst wenn ein Restore aus einem Backup schneller sein sollte als ein Rebuild aus der Parity, würde für mich immer der Rebuild der klare Gewinner sein, da ich mich um nichts weiter kümmern muss und auch während des Rebuilds auf alle Daten zugreifen kann. Work smart, not hard. Dein System kann die Daten effektiv selbst verwalten. Lass deine Kiste für dich arbeiten und nicht anders herum. Wenn man Backups hat (welche man immer haben sollte!), braucht es nicht zwingend eine Parity zu haben. Wenn man auf die obigen Vorteile verzichten kann und dafür entweder eine weitere Festplatte einsparen kann oder mehr Speicher haben kann, braucht es keine Parity. Aber das musst du für dich abwägen. Noch ein paar zusätzliche Tipps: 36 Stunden für einen Parity Check oder Rebuild sind definitiv zu lang. Wenn Parity weiter genutzt werden soll, dann bei den Parity Disks darauf achten, dass diese CMR Platten sind und keine SMR. Datendisk können alternativ SMR sein, wenn man etwas Geld sparen möchte. Wird SATA 3 6 Gb/s genutzt? Evtl. SATA Karten mit Multiplizierer verbaut? Für deine Appdata solltest du wirklich eine SSD im XFS Pool nehmen. SATA SSD reicht dicke, muss also keine NVME sein. Willst du Redundanz, nimm zwei SSDs im btrfs oder ZFS Pool (RAID1). Dadurch werden deine Docker deutlich performanter und deine Festplatten im Array können sich abschalten. Liegt Appdata im Array, hast du nämlich ständig Disk Aktivitäten und auch eine bescheidene Performance. Auch hier gilt dennoch: Backup fahren (CA Appdata Backup) Zusatztipp: Solltest du für dich entscheiden, auf die Parity verzichten zu können und auch keine SSD im System einbauen wollen, kannst du auch auf das Array komplett verzichten. Stattdessen könntest du alle Festplatten in einen Pool packen. Ob btrfs oder ZFS obliegt deiner jeweiligen Konfession. Entweder als RAID5 (Ausfallschutz/Redundanz) oder RAID0 (max. Speicher/Performance, jedoch kompletter Datenverlust bei Ausfall einer Platte). In beidem Varianten werden die Daten jedoch RAID typisch gestrippt, was zu einer besseren Performance führt als bei einzelnen Disks im Array, gerade wenn dein Appdata nicht auf eine SSD ausgelagert werden kann. Dennoch nochmal zum Abschluss, auch wenn du Backups hast: RAID/Parity =/= Backup (!!!)

SSD im Array macht keinen Sinn. Beim Schreiben kann deine SSD nämlich nur so schnell arbeiten, wie deine Parrity Disk. Du bremst also dein ganzes System ungemein aus. Pack die SSD in einen Pool. Wenn dir Redundanz wichtig ist, nimm zwei SSDs in einen Pool. Mit USV Support als BTRFS, ohne USV ZFS (overlay2 in den Docker Settings setzen). Wenn Redundanz nicht wichtig ist, reicht eine SSD. So oder so mit CA_Appdata_Backup Backups fahren. Denn: RAID im Pool =/= Backup! Dein Share, welches den SSD Cache nutzen soll, sollte so eingestellt werden: Primary Storage: deine SSD, wie auch immer der Pool heißen mag. Secondary Storage: dein Array. Restliche Werte obliegen deiner jeweiligen Religion und Glauben. Mover Action: Von der SSD zum Array. Dein appdata, system und domain Share sollte final so aussehen: Copy-on-Write (COW) für den Anfang auf default "auto" lassen (nur bei btrfs/zfs). Wichtig: Der Mover kann nicht direkt von einem Pool in einen anderen Pool verschieben. Hier entweder mit dem File Manger, Unbalance, Krusader, usw. arbeiten. Wenn du appdata, system und domains vom Mover (oder manuell) verschieben lassen willst, davor den Docker Dienst als auch den VM Dienst deaktivieren. Wenn du Zeit beim verschieben sparen willst, kannst du das Docker Image oder Directory vor dem verschieben löschen, was nur geht, wenn der Docker Dienst deaktiviert ist. Du kannst die Docker danach aus dem "App Store" mit deinen aktuellen Einstellungen erneut installieren. Daten gehen dadurch nicht verloren, da die wichtigen per Default in Appdata liegen.

Ohne Logs wird es schwer, das was zu sagen.