Jump to content

mgutt

Moderators
  • Posts

    11,373
  • Joined

  • Last visited

  • Days Won

    124

Everything posted by mgutt

  1. Es produziert auf jeden Fall weniger CPU-Last. Eher auf dem Niveau von FTP. Unwahrscheinlich. Kannst du da mal was vorbereiten, was ich testen könnte?
  2. Did you read the initial post?! This thread has absolutely nothing to do with CPU load.
  3. I found a strange bug, which seems to be caused of Unraid's virtual filesystem. It is noticeable if you use /mnt/user/... as destination path and as long the last backup is located on the cache. It does not happen if the last backup is fully moved to the array or if /mnt/user/... is not used as destination path. What results through this bug: Usually the timestamp of directories are correctly taken from the source. In this example, the directories were created in 2016: But if the last backup is on the cache and I use it through /mnt/user as link-dest Parameter in rsync, the timestamps are overwritten by the current time: AND: Strangely it creates all dirs on the array with the correct timestamps, too: So they were created twice through a single rsync command?! This is the command I used to induce the bug: rsync --archive /mnt/remotes/MARC-PC/Users/Marc/Downloads/ /mnt/cache/test rsync --archive --link-dest=/mnt/user/test /mnt/remotes/MARC-PC/Users/Marc/Downloads/ /mnt/user/test10 It does not happen if I use /mnt/cache as the link-dest: rsync --archive --link-dest=/mnt/cache/test /mnt/remotes/MARC-PC/Users/Marc/Downloads/ /mnt/user/test17 Or if I use /mnt/cache as destination: rsync --archive --link-dest=/mnt/user/test /mnt/remotes/MARC-PC/Users/Marc/Downloads/backup-2.6.2020_04-07-17_bindner/homedir/mail/iontophoresis-device.com/versand/ /mnt/cache/test19 So it happens only if both paths are set to /mnt/user/... which is the default behaviour if the destination path has been set to /mnt/user/... At the moment I'm not sure if the script should disallow the usage of /mnt/user/... as destination path 🤔
  4. Wie kann das sein, wo du vorher noch mit UEFI booten konntest? Der einzige Unterschied zwischen UEFI und Legacy ist der Name des Ordners "EFI" auf dem Stick. Heißt er "_EFI", dann bootet er Legacy. Den Stick vielleicht auch mal bei einem anderen PC testen. Siehe auch:
  5. Deine CPU hat keine iGPU. Dementsprechend hat dein Server nur eine GPU, die sich Unraid beim Booten krallt, weil dein BIOS es nicht erlaubt ohne GPU zu booten. Damit ein Durchschleifen an eine VM trotzdem funktioniert, braucht man Glück und muss viel herumprobieren. Nicht jede Hardware-Kombination macht das möglich. Siehe auch diesen Thread:
  6. Das ist eine SMR. Es ist also kein Wunder, dass das Array so lahm ist. Du meinst einen RAID Controller im IT Modus. Ein SATA Controller schleift ja bereits alles 1:1 durch
  7. 1.) Der Cache des Shares muss auf Ja gestellt werden, damit der Cache geleert wird 2.) Der Mover muss den Cache sehr schnell leeren, wenn du nur 120GB zur Verfügung hast. Auf der Übersicht beim Mover einfach den Zeitplan anpassen. 3.) Du musst den Free Min Space des Cache und des Shares größer einstellen als die größte Datei, die du auf den Server hochladen möchtest, was vermutlich eine 120GB SSD ziemlich nutzlos als Cache macht. Man will den Cache ja schließlich noch für Docker verwenden. Solltest du das nicht tun, machst du eh was falsch. 4.) Mehrere LAN Anschlüsse erhöhen nur die Geschwindigkeit, wenn du SMB Multichannel und RSS korrekt konfiguriert hast. Könnte aber bei der verbauten CPU eng werden, da man dafür eine sehr hohe Single Thread Leistung benötigt. 5.) 30 MB/s ins Array deuten daraufhin, dass du SMR Platten im Array hast oder mit SATA Port Multipliern arbeitest. Beides ist nicht empfohlen.
  8. Hätte ich tatsächlich auch erwartet, dass das dann auf lokale IPs umstellt. EDIT: Ah noch was denkbar. Und zwar steht hier noch eine Bedingung: https://support.parsec.app/hc/en-us/articles/4440911373325-Parsec-Connectivity-Requirements Sollte also die Domain parsec.app auf eine lokale IP auflösen, kann der Router das evtl auch unterbinden. Die Fritz!Box macht das zB. Nennt sich DNS Rebindschutz. Solltest du sowas haben, dann dort die Domains parsec.app und parsecgaming.com eintragen.
  9. Das heißt, dass seit 54 Tagen kein Backup erstellt wurde, obwohl das Skript regelmäßig gestartet wird. Das ist also ein Hinweis darauf, dass dein Backup-Prozess fehlerhaft ist. Im Skript gibt es dafür eine Einstellung, die man theoretisch auf 99999 stellen kann: # notify if last backup is older than X days notification_backup_older_days=30 Kann ich allerdings nur von abraten. Der Hinweis macht ja schließlich Sinn. Ansonsten wäre dir jetzt vermutlich auch nicht aufgefallen, dass deine Disk nicht ansprechbar war. Habe ich auch lange genutzt und bin froh davon weg zu sein. Google mal nach Hyper Backup Explorer Operation failed. Gibt genug Leute, die ihre kompletten Backups deswegen verloren haben. Ich nehme lieber andere Nachteile in Kauf als proprietäre Backups zu erstellen. Das UD Plugin ist ok, aber war in meinen Augen noch nie fehlerfrei.
  10. Kann dein Router NAT-Loopback bzw Hairpinning? Nur so wäre es bei einer IPv4 überhaupt möglich lokal auf die Public IP eines Clients zuzugreifen.
  11. Üergibst du dem Container bestimmte User IDs? Zeig mal die erweiterte Ansicht von den Containereinstellungen.
  12. Auf keinen Fall in das Array. Entweder separater Pool oder ins Array sichern. Ich habe nur eine SSD, daher mache ich Letzteres.
  13. Ich nutze das Skript: https://forums.unraid.net/topic/97958-rsync-incremental-backup/
  14. Ja, BTRFS ist nach wie vor unberechenbar. Höre ich auch aus dem professionellen Bereich. zb kann es passieren, dass das Volume zu 100% voll ist und dann nicht mehr gemountet werden kann. Ich hatte bei einem Kunden dann auch mal den Fall, dass eine NVMe aus dem RAID1 keine wiederherstellbaren Daten enthielt. Zum Glück die andere aber. Ist nur halt komisch bei einem RAID1. Und eben die Sache, dass man nie wirklich weiß wie voll das RAID wirklich ist und die extreme Anfälligkeit bei Stromausfall.
  15. Du musst auf jeden Fall die VMs immer neu erstellen. Es bringt nichts die XML zu ändern, wenn in libvirt der alte virtuelle Rechner angesprochen wird und du zwischenzeitlich beim Host zwischen Legacy und UEFI usw wechselst. Also jede Änderung und jeden Test, den du machst, solltest du immer auch an eine neue Maschine koppeln. Ansonsten kann dir niemand deine Fragen beantworten. Wie gesagt ist das absolut abhängig von der Hardware. Wenn du nicht gerade jemanden im Forum mit genau deinem Board findest, der auch Single GPU passthrough geschafft hast, wirst du keine weitere Hilfe dazu finden.
  16. Ich behaupte, dass das mit UEFI nicht geht. Und single passthrough ist sehr hardwarespezifisch. Hast du beim Booten von Unraid auf dem alten System die Ausgabe von BIOS und Unraid gesehen oder war da die GPU Ausgabe von Anfang an schwarz? Warum hast du eigentlich nicht gleich einen 5700G geholt? Dann hättest du den Stress jetzt nicht.
  17. Da muss man tatsächlich manchmal Geduld haben und erstmal nichts machen. Je nach Größe läuft das Update noch. Daher besser auf die CPU Last des Containers schauen und warten bis der sich beruhigt hat, bevor man sich wieder einloggt.
  18. Das Laufwerk UNRAID wurde beim letzten Abschalten des Servers nicht ordentlich getrennt. UNRAID ist der USB-Stick. Musste der Server bei dem Neustart hart abgeschaltet werden? Wenn nein, dann stimmt was nicht mit dem Stick. Der Inhalt des Sticks ist auf jeden Fall schon beschädigt. Daher bitte den Stick neu machen und /config aus einem Backup wiederherstellen.
  19. Kleiner Tipp: schreibt auch im Container /mnt/user/Papa und du sparst dir das unnötige Umdenken was wo sein sollte.
  20. Are you able to login into NPM? The logs of NPM do not show errors, too? Please follow the 5xx error steps on the first page.
  21. Einfach gar nicht benutzen? Das Server Backup von meinem ehemaligen Server ist schon ewig in meinem Profil. Da löscht sich gar nichts.
  22. Keine Änderung. Nach dem Neustart sieht noch alles gut aus, aber sobald man die GUI geöfnet hatte, sind zig Skripte dauerhaft offen: root@Tower:~# pgrep -af http 2839 /usr/local/sbin/emhttpd root@Tower:~# pgrep -af http 2839 /usr/local/sbin/emhttpd 3948 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/notify_poller 3950 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/session_check 3952 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/device_list 3954 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load 3956 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/parity_list 4168 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/wg_poller 4170 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_1 4172 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_2 4174 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3
×
×
  • Create New...