mgutt

Klar. Innerhalb einer VM, die auf Unraid selbst läuft, sieht das natürlich anders aus. Dann braucht es aber natürlich auch eine potente GPU im Server. Denk dran, dass die immer Strom zieht, auch wenn die VM heruntergefahren wurde.

Schaue ich mir heute Abend an. Eigentlich hatte ich ja schon SSL für die DuckDNS bei dir eingerichtet. Sollte also kein großes Problem sein.

Trotzdem so machbar. Docker deaktivieren, Cache Yes, Mover starten. Die Dateien sind nun auf den HDDs. Jetzt Pool wechseln, Cache Prefer, Mover starten. Die Dateien sind auf dem neuen Pool. Docker aktivieren. Das docker.img ist übrigens unwichtig. Kann man auch löschen. Dann muss man nur eben die Container "neu installieren". Dazu einfach auf Apps > Previous Apps gehen und den Container neu laden. Datenverlust ist ausgeschlossen, da die Daten in appdata und nicht im docker.img liegen.

Unwahrscheinlich, dass das an Unraid liegt. Welches Board wird verwendet? Werden nur Onboard SATA Buchsen verwendet? M.2 verbaut, die evtl SATA Buchsen deaktiviert? PCIe Karte installiert, die evtl SATA Buchsen deaktiviert?

Falls du aus dem Raum Köln / Bonn kommst, hätte ich noch ein paar Boards zum Testen da

Pools bieten sich an, wenn du die maximale Performance haben willst. Für ein Backup Ziel eher unwichtig. Selbst die Parity ist unwichtig in deinem Szenario. Wichtiger wäre ein Offline und oder Remote Backup. Also eine Platte per USB anklemmen und nach einem Backup an einen Remote Standard bringen und dort gegen eine andere Backup Platte tauschen. Zb der Spind auf der Arbeit oder bei Mutti zu Hause. Das dann als Schutz gegen Ransomware, Einbruch und Feuer.

Sind die CPU Sockel Pins alle in Ordnung? Eventuell braucht der i3 weniger, weshalb es da nicht aufgefallen ist.

Ich sagte PC, nicht Server. 1GB Logs sind viel mehr GBs im Browser. Öffne mal den Task Manager des PCs, wenn du dir die Logs anschaust. Die Arbeitsspeicherauslastung explodiert. Die Browser sind einfach nicht dafür gebaut so viel Text auf einer Seite darzustellen. Selbst manche Texteditoren mögen das nicht.

Nein. NPM leitet alles auf Port 80 um. NPM muss nur auf 80 und 443 lauschen können. 80 für die Verifikation des Zertifikats und 443 für den eingehenden Traffic der Besucher. NPM ist also derjenige, der ver- und entschlüsselt. Die lokale Kommunikation zwischen NPM und Nextcloud ist dann wieder unverschlüsselt. Nutzt du IPv6? Der NPM Container in Unraid funktioniert dann nicht, da man den Standartport nicht auf 80/443 ändern kann. Daher bin ich gerade dran den Original NPM Container bei Unraid bereitzustellen. Bei IPv6 erlaubt der Router nämlich normalerweise kein Port Forwarding. Daher öffnet man im Router Port 80/443 und leitet sie auf 80/443 von NPM.

Gut, kommt natürlich auf die Verteilungsregeln an. Wenn alle Platten vom selben Share benutzt werden, dann klar.

Ich würde jetzt erstmal einen Ubuntu Stick fertig machen und schauen ob er damit bootet. BIOS Update schon geprüft? RAM bitte auch mal einzeln testen.

Viele nutzen die GPU für Docker Container und dafür muss sie in Unraid selbst verfügbar sein. Außerdem nutzt Unraid die GPU automatisch für die Ausgabe des Terminals. Daher muss man Unraid erstmal dazu zwingen keine GPU zu nutzen, wenn man nur eine hat und diese in einer VM verwenden möchte. Um Unraid "headless" zu starten, daher: - Legacy Boot - GPU (auch evtl USB Controller der GPU) an VFIO binden - Logs auf den Stick schreiben lassen - Daumen drücken und neustarten ^^ Falls Unraid nicht mehr bootet die vfio config Datei vom Stick löschen und das Log checken.

Die Logs werden vollständig angezeigt. Dies überlastet schnell den RAM deines PCs. Besser ist es sich die Logdatei herunterzuladen und mit einem Texteditor anzuschauen.

Du musst die GPU an VFIO binden (Tools > System devices), ansonsten verwendet sie Unraid und ein paralleler Zugriff führt dann zum Absturz. Da deine CPU keine iGPU besitzt, solltest du für Unraid eine GT710 / GT1030 installieren. Es kann auch so gehen, ist aber meist Gefummel. Besser Unraid eine mitgeben und man hat Ruhe und kann jede zusätzliche an VFIO binden und dann an die VM durchreichen. Willst du es ohne zweite GPU probieren, wäre der erste Schritt das System im Legacy Modus zu booten. Außerdem die GPU an VFIO binden. Beim Rest bin ich raus. Muss dann jemand anderes was zu sagen.

Klar geht auch. Konzeptionell kannst du dir alles mögliche ausdenken. Manche benutzen als Array nur einen leeren USB Stick und betreiben ausschließlich einen SSD Pool im RAID1 oder RAID5 oder RAID... geht alles. Wenn du inkrementell sicherst, musst du nur nur beachten, dass ein laufender Docker Container nicht zuverlässig gesichert werden kann. Sicherer wäre es den Container für das Backup zu stoppen. Das gleiche gilt für VMs.

Ein Docker kann keine beliebigen Platten wecken. Der hat doch in der Regel nur Zugriff auf appdata und domains und beide liegen in der Regel auf dem cache Pool.

Schönes Projekt. Dann hoffen wir, dass das Schule macht 😉

Ok. Das ist nun wirklich komisch. iperf schnell, SMB und FTP langsam... Wie geht das? ^^ Hast du einen Managed Switch im Netz, der evtl bestimmte Ports drosselt? Eventuell mal mit einer Direktverbindung probieren, damit wir das Netzwerk ausschließen können. @Ford Prefect Hast Du noch eine Idee?

Auch nach Zeitplan? Also, dass er erst die Aktivität nach 23 Uhr überwacht und nur dann herunterfährt? Dann wäre das für ihn auf jeden Fall die bessere Lösung. Mitten in einem Parity Check etc runterfahren, ist ja ich nicht gerade schick.

Ja und welche Optionen bietet dir Windows an?

Ja, ein anderer Container verwendet den Port 7900 bereits. Wenn du macinabox installierst, scroll ganz nach unten und klick auf "Show docker allocations". Da siehst du alle Container und deren Ports. Beispiel:

Der Befehl ist falsch. Der müsste so lauten: find /mnt/user -name "*macinabox*" Also er durchsucht dann alle User Shares. Vom Prinzip könnte man auch einfach selbst nachschauen. Die Ordner sind ja schließlich alle bekannt: Wie man sieht speichert er Dateien in "domains", "isos", "system" und "appdata". Ich habe macinabox testweise mal installiert. Vorher: Dann habe ich den Container wieder gelöscht. Nachher: Demnach sind die folgenden Verzeichnisse und Dateien zu löschen, um es in den Ursprungszustand zu versetzen: rm -r "/mnt/user/appdata/macinabox" rm -r "/mnt/user/domains/Macinabox"* rm "/mnt/user/isos/Catalina"* rm -r "/mnt/user/system/custom_ovmf" Ob im Falle von Big Sur noch weitere Dateien erstellt werden, müsstet ihr selbst mal schauen. Außerdem könnte man das Container Template löschen (wird dann neu aus dem App Store geladen): rm /boot/config/plugins/dockerMan/templates-user/my-macinabox.xml Das hilft aber nur, wenn man was bei den Container-Einstellungen "kaputt geändert hat" und es noch mal mit den Standardwerten versuchen möchte. Einen anderen Einfluss sollte das nicht haben. Wenn du den Container löschst, dann fragt der dich ja, ob du wirklich alles löschen willst. Diesen Haken lässt man drin. Dann sollte der bei der nächsten Installation die Pakete neu herunterladen. Tut er das nicht, dann weil ein anderer Container diese Pakete bereits heruntergeladen hat. Das ist kein Fehler und völlig in Ordnung so.

Is there a maximum limit of the atop log size, so I could still use the atop package but resize my log parition accordingly? EDIT: To answer my own question. No, it's impossible to know how much atop will log as it is fixed to a time frame: When atop is installed, the script atop.daily is stored in the /etc/atop directory. This scripts takes care that atop is activated every day at midnight to write compressed binary data to the file /var/log/atop/atop_YYYYMMDD with an interval of 10 minutes. Furthermore the script removes all raw files which are older than four weeks. The script is activated via the cron daemon using the file /etc/cron.d/atop with the contents 0 0 * * * root /etc/atop/atop.daily With this command the cron file is changed: sed -i 's/+28/+7/' /etc/atop/atop.daily

Das ist genau das was ich aktuell in Erfahrung bringe. Bei Gigabyte fehlt die CPU nämlich auch: https://www.gigabyte.com/de/Motherboard/W480M-VISION-W-rev-10/support#support-cpu

Uff.. nicht normal was aktuell abgeht.