mgutt

Oder das SilverStone RM400. Da passen alle Boards rein und das ist sogar nur 469mm tief. Dann muss es vorne nicht soweit rausstehen. Außerdem sieht das SilverStone qualitativ 3x besser aus. EDIT: In der Beschreibung steht, dass es Teleskopschienen dafür gibt: Dann würde ich das einfach mit den Schienen festmachen. Dann braucht man es auch nicht auf einen Fachboden legen. EDIT: Ach verdammt. Die Schienen sind 570mm lang ^^ Naja, vielleicht nach kürzeren suchen

Na super. Dh du hast nicht mal 50cm in der Tiefe. Damit lösen sich deine Optionen in Luft auf ^^ https://geizhals.de/?cat=geh19&xf=900_6~903_40 Interessant sind die Bewertungen vom RealPower RPS19-G3380. Bei Mindfactory ist jemand total glücklich und bei Amazon bezeichnet jemand das Gehäuse als absoluten Pfusch 🤪 Vom Prinzip kannst du ja nur noch ein normales PC Case reinstellen. Oder du setzt Martins Lösung um, nur eben so, dass das Case vorne übersteht. Oder du nimmst das SilverStone RM400 und stellst es auf einen Fachboden. Oder evtl mit 3cm Abstandsklötzen und langen Schrauben befestigen.

Wieso kein 12er? Das ist doch ein 12er? https://www.fantec.de/produkte/serverprodukte/19-server-storagegehaeuse/produkt/details/artikel/2161_fantec_src_2012x07/ Man kann da auch bestimmt noch 3.5 Zoll Käfige reinbasteln (wenn man ein SFX Netzteil nimmt): Und wenn es unbedingt Bays sein müssen, spricht meiner Ansicht nach nichts gegen zwei Gehäuse. Dass es kein Gehäuse mit 16 Bays und kleiner Bautiefe gibt, liegt denke ich daran, dass die redundanten Servernetzteile in dieser Größenordnung zu lang sind und die meisten Enterprise-Kunden sehr große Mainboards verbauen wollen: Es gibt weltweit meine ich nur einen Hersteller, der es anders macht, aber der verkauft die das Storinator AV14 nicht einzeln, sondern nur als System: Und bevor ich 3000 € für sowas ausgebe, kaufe ich mir lieber zwei Gehäuse und baue zwei vollwertige Server. Mit DAC oder SFP+ sind die dann untereinander auch schnell genug verbunden.

Wenn der Widerstand hinten geringer ist als der Luftdruck, dann wird die Luft hinten rausgehen. Ansonsten rechne es doch einfach aus: Ein 2HE Gehäuse hat eine Frontfläche von 9x45cm = 405 cm² 3cm Abstand hinter dem Gehäuse ergeben 2x 3x45cm (oben/unten) + 2x 3x9cm (links/rechts) = 324 cm² Die Luft kann also aus Spalten entweichen, die 80% der Frontfläche ausmacht. Gut, man hat natürlich Reibungsverluste, aber ich denke das passt, da du noch lange nicht so viele Löcher in Front oder Heck hast.

Hmmm. Ich kann keine Apps herunterladen: Der Container selbst kommt aber ins Internet: EDIT: Ok, liegt an der Telekom. Ich kann von Amazon S3 nur sehr langsam herunterladen und Nextcloud läuft dann ins Timeout. Aber trotzdem die Frage. Hattest du Apps installiert?

Ich habe jetzt mal den von "knex666" installiert. Der nutzt ja das Original Repository. Allerdings habe ich, damit es auf jeden Fall 1:1 ist, den "apache" tag gesetzt. Außerdem habe ich den Container auf Bridge gesetzt und den Port weitergeleitet. Damit sollten wir beide also die selbe Situation haben. Bei der Installation habe ich dann folgende Angaben getätigt: Was mir in jedem Fall aufgefallen ist, dass der bei der Installation der Apps Probleme hatte: # Allerdings ist Nextcloud bei mir super schnell: Was auch komisch ist, dass ich Nextcloud nicht über https erreichen kann: EDIT: Oh ok. Steht ja auch in der Beschreibung. Der Nextcloud-Container kann gar kein https: Hatten sich bei dir denn die Apps installiert? Vielleicht liegt es ja an irgendeiner App.

Ok, I think I found the problem. I don't know why, but it seems I used in the past as container path a sub-folder inside of my plex docker container. Luckily it did not delete anything ^^ After deleting "UpdateTool" in Apps > Previous Apps, the entry disappeared. What do you think about using the -v flag and put the results into the system logs?

I'm not able to delete this path: It reloads the page as it was successful, but the entry stays. As nothing is in the logs, which command is used, so I could test it through the Terminal?

Hast du denn auch diese begrenzte Einbautiefe wie @Saeros ? Dann würde ich ja sagen, denn viel Auswahl gibt es ja nicht: 8 externe HDDs: https://geizhals.de/?cat=geh19&xf=902_8~903_55 8 interne HDDs: https://geizhals.de/?cat=geh19&xf=900_8~903_55 Was ich zB auf keinen Fall kaufen würde, wäre sowas, da 50% der Front verschlossen ist und die Platten sind eng an eng und nicht mal alle sind im direkten Luftstrom: https://geizhals.de/raidsonic-rackmax-rm-1941-19401-a1819089.html?hloc=de Die von Intertech haben alle falsche Angaben, da gar kein mATX/ATX passt, außer das hier, was aber eine Fehlkonstruktion ist, da die Lüfter eher die Luft durchs Gitter ziehen als von den Platten weg: https://geizhals.de/inter-tech-ipc-4u-4408-88887191-a1480037.html?hloc=de Also bleibt nur das SilverStone RM400 und Fantech SRC-2080X07. Ich würde aber auch das Fantec SRC-2012X07 in Betracht ziehen, weil man da die SSDs gleich auch in Bays packen könnte.

Ich persönlich betrachte Paritätslaufwerke nur als Komfort, da sie mich davor bewahren bei jedem Laufwerksdefekt den Server bzw dessen Dienste für viele Stunden abzuschalten und erstmal das Backup wiederherstellen zu müssen. Zwei gleichzeitige Laufwerksausfälle sind natürlich auch möglich, aber den seltenen Fall nehme ich selbst bei meinem Array aus 10 HDDs in Kauf, da ich bei Unraid dann nur die zwei defekten Platten wiederherstellen muss und niemals das komplette Array, wie es bei einen klassischen NAS und seinem RAID5 der Fall wäre, da bei Unraid die Dateien immer vollständig auf den jeweiligen Platten liegen, während sie bei einem RAID auf alle Platten verteilt werden. Daher wäre die Motivation bei einem RAID höher ein RAID6 zu nutzen (also zwei Paritätslaufwerke). Hier kommt es darauf an, ob du mit einem Datenverlust bei SSD Ausfall leben kannst und wie oft du eine Datensicherung von der SSD machst. Die Frage ist auch, ob du bei 2 HDDs überhaupt eine SSD benötigst. Die Stromersparnis ist ziemlich gering. Oder möchtest du Container / VMs nutzen, die von der niedrigen Latenz einer SSD profitieren sollen?

Warum sieht der so komisch aus? Passt da kein normaler Käfig rein? EDIT: Sorry, jetzt habe ich erst verstanden, dass du den kompletten 5.25 Zoll Käfig ausbauen willst. Ja das ginge auch. Dann liegst du bei 170 + 30, also 200 €. Der 12er Fantec kostet allerdings genauso viel und hat dafür externe Bays und eine Backplane. Und die Lüfterposition finde ich da auch gut (eben dahinter). Der Vorteil beim Silverstone wäre sonst noch, dass man keine SFF Adapterkabel benötigt. Hier noch mal das Innere im Vergleich: Silverstone Fantech Fürs selbe Geld würde ich vermutlich eher zu externen Einschüben tendieren.

Läuft das jetzt über den Docker Container aus den Apps? Das wäre dann die Bestätigung, dass ich es richtig gemacht habe ^^

Welches jetzt? Fantec? Das Gehäuse ist ganz gut bei Amazon bewertet: https://www.amazon.de/FANTEC-SRC-2080X07-Storagegehäuse-intern-schwarz/dp/B00HFGJRR4/ Damit das Netzteil nicht so laut wird, könnte man übrigens mit der Adapterplatte ein SFX Netzteil verbauen: https://www.silverstonetek.com/product.php?area=de&pid=631 Für die Verbindung der Backplane braucht man wohl ein Reverse Kabel wie eines davon: https://www.amazon.de/-/en/gp/product/B013G4EQOM/ https://www.amazon.de/InLine-27620-Anschlusskabel-Mini-SFF8087/dp/B001BIN3N6 Neben den 2 SSDs müsste man eigentlich mit der Adapterplatte, sofern man diese nachkaufen kann, auch noch zwei montieren können (nur die Löcher fehlen noch, aber sonst eben Klett ) : Du könntest stattdessen da auch 2x HDD montieren und irgendwo hinten beim Mainboard die SSDs hinpacken. zB mit so einem Halter, wenn es nicht rumfliegen soll: https://www.amazon.de/AKasa-AK-HDA-10BK-2-5-Festplatten-Einbaurahmen/dp/B00NOBG1DW/ Dann wäre die Grenze bei 10x HDD plus haufenweise SSDs.

Nein das passiert automatisch. Nur VMs muss man evtl von Hand herunterfahren. Wenn du im BIOS Hotswap aktiviert hast, müsstest du den Server nicht mal herunterfahren.

Poste mal bitte deine diagnostics (unter Tools). Außerdem aktiviere über Settings -> Syslog Server den Mirror to Flash. Dadurch werden deine System-Logs auf den USB Stick gespiegelt und bleiben auch nach einem Absturz erhalten. Freezed er wirklich? Also hast du mal die Ausgabe vom Server geprüft ob du da über die Konsole noch Eingaben tätigen kannst oder ist vielleicht "nur" der SMB Dienst abgeschmiert etc? SMB kann bei Unraid Shares schon einiges an Leistung ziehen. Beim Durchlaufen eines Verzeichnisses mit vielen Dateien um die Gesamtgröße zu ermitteln, werden sehr viele Einzelkommmandos auf den Server abgesetzt. Wenn dieser nun keine ausreichende Leistung besitzt, kann das durchaus lange dauern. Aber dass der Server dann sogar abschmiert ist nicht normal. Nutzt du Undervolting oder Overclocking? Hast du mal den Arbeitsspeicher geprüft?

I liked to test ChunkSync to create incremental backups of huge image files, but sadly there was no slackware package for Unraid available. Finally I tried to convert the deb package with deb2tgz, but altough it installed without errors it returned only the following (because its a 32 bit version I think): chunksync -h -bash: /usr/bin/chunksync: No such file or directory So I tried to create my very first slackware package by using a source 😱 I found a manual and after several errors I found out that I first needed to install all unraid dev tools. I skipped the first step as the package did not contain a configure shell script. Then I had to create manually some folders, moved all files from /tmp/build/usr/local to /tmp/build/usr (so chunksync will be installed in /usr/bin) and finally build the package with this command: makepkg -l y -c y ../chunksync-0.4-x86_64.tgz And hey, it seems to work ^^ Maybe someone else needs it, so I attached it to this post. Using chunksync is simple, first shutdown a VM and then execute it as follows (change path of course): chunksync 104857600 "/mnt/user/domains/W10 Vanilla/vdisk1.img" "/mnt/user/Backup/domains/W10 Vanilla/vdisk1.img" By that it will created the chunks in a really deep dir structure like this: /mnt/disk9/Backup/domains/W10 Vanilla/vdisk1.img/00/00/00/00/00/00/01/0d (100 MiB) Screenhot: The incremental backup needs an additional flag with the path to the last backup: chunksync -l "/mnt/user/Backup/domains/W10 Vanilla/vdisk1.img" 104857600 "/mnt/user/domains/W10 Vanilla/vdisk1.img" "/mnt/user/Backup/domains/W10 Vanilla/2/vdisk1.img" Rebuilding could be done through unchunkfs or cat. My plan is to include chunksync in my incremental rsync script for huge files. chunksync-0.4-x86_64.tgz

Warum willst du eigentlich auf BTRFS wechseln? Falls du dir davon ein erhöhte Datensicherheit versprichst, muss ich dich leider enttäuschen. Zwar hat BTRFS Checksummen, aber die helfen dir nicht, da im Unraid Array, jede Platte für sich alleine steht. Dh du erfährst zwar von einem Bitrot, aber du kannst ihn nicht reparieren. Das geht nur bei BTRFS im RAID1. Da BTRFS wie jedes CoW Dateisystem einen hohen Overhead besitzt, empfehle ich stattdessen alle paar Wochen das Dynamix File Integrity Plugin ausführen zu lassen und evtl Dateien mit Bitrot aus einem Backup wiederherzustellen.

Ich tippe darauf, dass es viele falsch machen. Bei Virtualbox gibt es nämlich eine wichtige Funktion, die man bei einem Dateisystem wie ZFS oder BTRS nicht hat, nämlich, dass das generierte Snapshot auch den RAM Inhalt enthält. Man muss also bei BTRFS zwangsläufig erstmal die VM herunterfahren, bevor man das Image sichern kann. Jede andere Methode führt zwangsläufig dazu, dass man ein korruptes Image hat bzw irgendwann bekommt, da es nichts anderes ist, als wenn man bei einem laufenden Rechner den Strom zieht. Alles was dann noch im RAM war, ist dann eben weg. Ich habe das folgende Script mal überflogen und es ist gut aufgebaut, da es den Status der VM (suspend, shutdown) prüft, bevor es per rsync eine Sicherung davon macht: https://forums.unraid.net/topic/46281-unraid-autovmbackup-automate-backup-of-virtual-machines-in-unraid-v04/ Allerdings möchtest du ein platzsparendes Backup, also eine inkrementelle Sicherung der Daten. Da wären wir dann beim nächsten Problem. Ja, man kann in BTRFS platzsparende Snapshots erstellen, aber diese Snapshots sind dann ja auf dem selben Datenträger wo sie vorher waren. Du kannst zB kein Snapshot auf einem externen Datenträger erstellen. Du kannst nur lokal ein Snapshot erstellen und es dann mit btrbk auf einen externen Datenträger kopieren. Oder man synchronsiert die Snapshots mit snap-sync. Alternativen dazu: A) Man startet des Backup über die VM selbst und sichert inkrementell die Dateien. Das resultiert aber kein laufendes Image. B) Man weist der VM eine (kleine) SSD als Datenträger zu und sichert die Dateien dieses Datenträgers inkrementell, wenn die VM heruntergefahren wurde. Auch das resultiert kein laufendes Image. C) Nachdem die VM heruntergefahren wurde, erstellt man von der kompletten SSD ein Image. Als Snapshot wäre es inkrementell möglich (aber mit oben genannten Einschränkungen), mit rsync nicht. D) Man nutzt ChunkSync zur Sicherung von Images. Leider gibt es aber noch kein Paket für Slackware (Unraid OS). Müsste man sich erst kompilieren. Setzt man diese Chunks mit cat wieder in eine Datei zusammen, hat man ein laufendes Image. Letzteres plane ich in Zukunft in meinem inkrementellem rsync Script zu implementieren. Dazu würde ich mit dem --max-size Parameter alle Dateien, die größer sind als x GB von rsync ignorieren lassen und genau die dann von ChunkSyze sichern lassen.

Laut hier soll das kein Problem sein: https://forums.unraid.net/topic/92315-mixing-array-drives-xfs-and-btrfs/ Schritte wie dort beschrieben durchgeführt?

Ich habe das jetzt auch nur mehrfach bei Reddit gelesen, aber nie selbst getestet.

Ich sehe folgende Optionen: A) Stell ein Case rein, wenn es günstig sein soll B) Setz Martins Lösung mit dem liegenden Define R5 um, wenn es etwas teurer werden darf, aber dafür komfortabler ist. C) Gib mehr Geld für einen 19 Zoll Gehäuse aus Das es für letzteres kein Gehäuse gibt, das ausreichend Bays hat, würde ich einfach 2x sowas kaufen (300 €): https://www.fantec.de/produkte/serverprodukte/19-server-storagegehaeuse/produkt/details/artikel/1670_fantec_src_2080x07/ Zur Verkabelung nutzt man dann ein längeres SFF Kabel, wobei bei einem ausziehbaren Gehäuse darauf zu achten wäre, dass man immer beide Gehäuse gleichzeitig rauszieht, denn die SFF Kabel dürfen wegen SATA nicht länger als 100cm sein und die Backplane dämpft ja auch schon ein wenig das Signal, weshalb ich eher 75cm als Limit sehen würde. Das kann man aber lösen, in dem man beide Gehäuse zb an den Griffen mit Kabelbindern verbindet. Muss man wirklich mal an den unteren, kann man ja die Kabelbinder auftrennen und weiß dann auch direkt, dass man erst das SFF Kabel lösen muss. Oder man kauft das und nutzt ein mATX Board, so dass man innen weitere Käfige verbauen kann (200 + 50 €): https://www.fantec.de/produkte/serverprodukte/19-server-storagegehaeuse/produkt/details/artikel/2161_fantec_src_2012x07/ Bei beiden hat man das Problem, dass die von hinten verkabelt werden, was ja bei deiner Einbausituation nicht gerade von Vorteil ist. Besonders wenn noch mehr eingebaut wird. Es kommen also Kosten für Auszüge dazu (ca 40 € pro Paar). Ich persönlich favorisiere die Lösung mit zwei Gehäusen, weil das ordentlich aussieht und man später sogar zwei getrennte Server bauen könnte. Einer könnte per WoL auch nur bei Bedarf hochgefahren werden. Nimmt man sogar 2x die 12 Bay Gehäuse, hätte man sogar noch sehr viel Luft nach oben was den Speicherplatz anbelangt. Schlussendlich aber alles eine Frage des Budgets und WAF.

Ja eben nur einen Slot. Leider gibt es keine Mini DTX Boards (ITX mit zwei Slots). Und 2x M.2 kann man komplett vergessen, wenn man ECC haben will. Echt ätzend, dass die Hersteller am Markt vorbei bauen.

Tun sie das? Also meine Samsung sind normal warm. Dieser "Kupferaufkleber" tut meiner Ansicht nach einen guten Job.

The logs says: This means you should disable the docker and vm service and run the mover. And after it moved all data where it belongs to, then you can restart the docker and vm services. As long they are in use, the mover can't move them.

Did you analyze the writes?