mgutt

Oh, dann sollte ich an der Stelle das dry-run denke ich weg lassen. Der Test kann ja ruhig in beiden Fällen wirklich gemacht werden. Danke für den Hinweis. Laut meiner Recherche wird der Zugriff als Root-User automatisch in nobody geändert: https://superuser.com/a/1226152/129262 Das ist halt das was ich meine. Wenn du auf ein externes System schreibst, kannst du niemals sicher sein, dass du auch da root bist, außer du nutzt wirklich den root-Login der Zielmaschine, was ich wieder als unsicher betrachten würde. Nur damit du das auch mal selber prüfen kannst. So kannst du alle Dateien finden, die dem User root gehören, die im appdata Share liegen: find /mnt/user/appdata -uid 0 Wenn du nun dieses Verzeichnis sicherst, kannst du das selbe Kommando auf der Zielmaschine selbst ausführen, um zu schauen, ob die Rechte noch passen. Zählen könnte man dann zB so: find /mnt/cache/appdata -uid 0 | wc -l find /mnt/extern/server/backups/appdata -uid 0 | wc -l Beide müssen logischerweise die exakte selbe Anzahl zurückgeben. Noch eine Option wäre es die Backups von Cache auf Array zu machen und das Backup dann in ein tar zu packen, was du dann auf ein externes Ziel deiner Wahl kopierst. Dafür reicht dann "cp". Die Hardlinks gehen dann natürlich nicht. Aber wenn man den gesamten Backup-Ordner sichert, dann erkennt tar die Hardlinks und fügt die Datei auch nur jeweils 1x im Archiv hinzu. Vorteil in einem tar ist, dass die Dateirechte im Archiv selbst gesichert werden. Dadurch kann man ein tar auch zB auf eine Windows-Maschine sichern und verliert nichts.

Ich habe zwischenzeitlich schon wieder welche gekauft. Sind noch 2 oder 3 sogar noch da. Schreib mir einfach eine Email / PN.

Was ist in diesem Ordner? Und wie sieht aktuell deine RAM Auslastung aus? Eventuell wiederholst du das Kommando einfach alle paar Stunden / Tage, um eine Tendenz auszumachen. Das wirkt auch als sei es zu viel. Mich wundert auch, dass /usr bei dir nichts zählt. Hat unRAID dafür neuerdings eine separate Partition? Führe bitte mal df -h aus.

Wenn du sie nicht gerade auf den Cache kopierst, befinden sich keine Dateien irgendwo doppelt. Dateien liegen bei unRAID entweder auf dem Array ODER dem Cache. Und du entscheidest, ob eine Datei permanent auf dem Cache liegen soll oder vom Mover auf das Array verschoben werden soll. Liegt dann eine Datei oder ein kompletter Share auf dem Array und die SSD geht kaputt, dann sind die Dateien verloren. Daher braucht es entweder ein RAID als Cache oder zeitnahe Backups. Desweiteren ist es meist wenig sinnvoll HDDs und SSDs im Array zu mischen. Ich mein wer will schon mit 50 bis 80 MB/s auf eine SSD schreiben. Dafür holt man sich ja eigentlich keine SSDs. Aber klar, machen kann man das. Wobei ich dann in den Disk Settings auf Reconstruct Write umstellen würde. Das sollte die Schreibgeschwindigkeit auf 200 MB/s erhöhen (es laufen dann beim Schreiben immer alle Disks des Arrays parallel, aber SSDs ziehen ja nicht so viel Strom bzw gehen schnell wieder schlafen, weshalb das in Ordnung sein sollte). Siehe auch: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=951565

Kurze Garantie, dafür mit 199 € für 18TB deutlich günstiger: https://www.ebay.de/itm/185843432850?epid=16060611231&hash=item2b4521bd92:g:CgUAAOSwRwhkLSbF Ich habe von dem Händler zwei 22TB Platten gekauft und bin zufrieden. Ansonsten würde ich aber eh nie mehr als 15 € pro TB zahlen. Also selbst so ein Angebot würde ich nicht wahrnehmen: https://www.mydealz.de/deals/2-x-western-digital-wd-red-pro-16tb-35-nas-hdd-ca-1754eur-tb-sata-7200rpm-512mb-cache-cmr-5-jahre-garantie-2227912 Jedenfalls geht es deutlich günstiger als 350 €. Man muss nur eben auf Angebote warten.

unRAID läuft im RAM, wie auch diese Datei. Dein RAM läuft also warum auch immer voll. Das ist natürlich nicht normal. Meist liegt es an Dateien, die in Verzeichnissen gespeichert werden, wo sie nicht sein sollten. Mit dem Kommando kannst du die jeweilige Belegung prüfen: du -hsx /* 2> /dev/null So sieht es bei mir aus: 12M /bin 715M /boot 0 /dev 15M /etc 0 /home 0 /hugetlbfs 0 /init 8.2M /lib 30M /lib64 0 /mnt 0 /opt 0 /proc 20K /root 1.1M /run 23M /sbin 0 /sys 76M /tmp 776M /usr 13M /var Weicht bei dir etwas auffällig ab?

Du kannst auch einfach den bestehenden Stick weiterverwenden. unRAID wird bei jedem Booten neu installiert. Wenn du das Array neu konfigurieren willst, dann geht das zb über Tools > New Config. Und wenn die Shares bzw Dateien auf Platten wegsollen, dann eben einfach die Ordner löschen.

On Port 80 or 443? Not possible as Nginx can't recognize other traffic than http. You could add a different port as a stream host, but then you could even forward the used irc port directly to your irc server without using nginx at all. If your provider allows only forwarding 80 and 443 you would need to use an additional container in front of Nginx like this one: https://github.com/yrutschle/sslh By that you could forward by the used protocol to the nginx or irc container.

Ja da steht ja auch dry run. Dann hast du denke ich die --dry-run Zeile aktiviert.

Dein Log sagt aber was anderes?!

Verstehe ich nicht. Der hat den Pfad doch kurz vorher erstellt 🤔 Sicher, dass der Pfad "Archiv" heißt und nicht "archiv"? Mal mit folgendem Kommando prüfen bitte: ls /mnt/user Bitte teste auch mal stattdessen einen Diskpfad. /mnt/user ist ja Unraid's virtueller Pfad auf alle möglichen Ziele. Nimm mal /mnt/disk1/Archiv oder welche Disk auch immer das Ziel sein soll. Ich bin von keiner Variante ein Freund, wenn man "appdata" sichert, da dort häufig Dateien drin sind, die "root" gehören und wenn man solche Dateien 1:1 sichern will, muss man auch root auf dem Ziel sein. Und das wäre ist riskant, weil ein Angreifer, der das eine Passwort knackt, gleich auch den Backupserver platt machen kann. Ich mache das komplexer, aber dafür deutlich sicherer. Ich habe einen rsync Container installiert, der rein lesend auf meine Daten zugreifen kann. Mein Backupserver verbindet sich mit diesem Container als root und kann daher die Dateien 1:1 ziehen, aber es kann niemals passieren, dass beide Server kompromittiert werden, da der Backupserver nur lesen kann und der Heimserver gar keinen Login vom Backupserver kennt. Auch kann der Backupserver die meiste Zeit aus sein, da er weiß wann das Backup fertig ist. Ich sichere übrigens appdata lokal vom Cache auf das Array, damit das Skript die Container sauber stoppt. Dh mein Backupserver holt nicht appdata direkt ab, sondern nur das Backup davon. Natürlich muss man das nicht so machen wie ich und kann ansonsten auch auf beliebige Ziele sicheren, aber das würde ich wie gesagt nur für Shares empfehlen, wo Nutzerrechte keine Rolle spielen bzw leicht repariert werden können wie zb persönliche Shares, wo Dokumente und Medien drin liegen. Und klar. SMB ist ein No Go wegen der Hardlinks. Irgendwie geht das wohl schon, aber das sollte man nur machen, wenn man es verifiziert hat.

Häh? Das bezieht sich auf SMB Shares von unRAID. Also wenn die das Ziel sind. Auf SMB sollte man sowieso niemals sichern. Dadurch gehen diverse Dateirechte verloren. Den Check habe ich selbst entwickelt. Ergänze bitte vor dieser Zeile: transfer_count=$(rsync --dry-run --itemize-changes --recursive --link-dest="$link_dest_path/link_dest" "$empty_dir/" "$dst_path/hard_link" | wc -l) Das: rsync --dry-run --itemize-changes --recursive --link-dest="$link_dest_path/link_dest" "$empty_dir/" "$dst_path/hard_link_test" Und dann brauche ich die Logs von dem Skript.

Snapshots sind keine Backups, weil sie auf der selben Partition existieren. Man kann Snapshots ja nicht auf andere Datenträger verschieben. Also kann man schon, aber dann sind sie auch nichts anderes als Backups, weil dann alle Daten 1:1 kopiert werden.

Sobald es wieder passiert die Logs posten. Die liegen dann in /boot/log, also auf dem Stick.

Spielt keine Rolle. Genauso wenig ob du den passenden Xeon holst. Hauptsache günstig. Ja das ist möglich Das be quiet! Pure Power 12 M 550W könnte eine Option sein. Aber Messwerte hat glaube ich noch keiner gepostet. Da du VMs betreiben willst und die den RAM reservieren, könnte es mit 16GB eng werden. Ich würde vermutlich 2x 32GB verbauen 😁 Wie viel Speicher belegen am Ende deine Medien? SSD Only ist vermutlich keine Option?

4K, SDR Tone Mapping und Subtitle Burn-In transcodiert der auf 1080p ruckelfrei? Dann brauche ich wohl doch ein neues Setup 🤔

Der eine testet 30 Sekundenclips und der andere hat angeblich 4K mit HDR und Untertiteln transcodiert, was nicht mal eine Nvidia GPU schafft. Ich bin skeptisch.

Der N5095 ist zu schwach für Plex: https://forums.unraid.net/topic/97626-support-plex-media-server-official/?do=findComment&comment=1304864 Das sollte auch für den N5105 gelten. Der ist ja quasi baugleich bzw sogar noch stärker in der TDP begrenzt.

Meist hilft da ein Serverneustart

Das Gewinde wird nicht gedruckt (geht so fein auch gar nicht), sondern man realisiert Taschen, wo man nachher Muttern reinsteckt. Hier sieht man so Taschen bei einem meiner Netzteilrahmen: Und hier die zwei Schrauben, die dann von oben reingeschraubt wurden: Je nachdem gibt es auch keine Hebelwirkung, weil man den Rahmen ja genauso breit wie das Netzteil machen kann. Ist nur die Frage, ob man rechts noch ein Loch am Gehäuse findet, wo man den Rahmen festmachen kann. In meinem Fall war das einfach wie man sieht, weil es zig Löcher gab. Oder meinst du allgemein wegen dem Gewicht des Netzteiles und weil es soweit absteht vom Rahmen? Gut, da hilft wie in meinem Fall natürlich der massive Druck. Also mit 2mm Dicke geht das natürlich nicht. Ich brauchte den Rahmen übrigens, weil ich ein Corsair Shift Netzteil verbauen wollte, was in dem Gehäuse nicht vorgesehen war: https://www.computerbase.de/forum/threads/mechanic-master-c26-deutlich-kleiner-als-worlds-smallest-matx-sliger-cerberus.1985999/post-28307462

This returns only relevant gpe interrupts: grep -P '[1-9]+' /sys/firmware/acpi/interrupts/gpe[0-9]*

Ich hatte jetzt den ganzen Halterahmen mit dickem ABS nachgebaut, so dass er nach rechts exakt die Schraubpunkte vom Netzteil abdeckt. Also unter das Netzteil kommt dann nichts. Das mit den Legosteinen meinte ich nur, um die passenden Abmessungen des Halterahmens zu ermitteln. Aber du machst das schon 😁

This shouldn't work as the movie itself has a complete different inode id on a complete different device (disk in array).

Noch mal: Hinlegen, nicht stellen. Dh das Netzteil schwebt über RAM und teilweiss der CPU und natürlich auch dem USB Kram. Dir fehlt dann nur der passende Halterahmen. Testweise halt mit Legosteinen die Höhe festlegen und dann abmessen und mit dem 3D Drucker einen passenden Halterahmen realisieren.

Und außer der Fehlermeldung kommt dann kein normaler Eintrag mehr?