mgutt

Beide bieten die selbe Ausfallsicherheit. Unterschied zwischen RAID Pool und unRAID Array: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-1021986 Klingt sinnvoll. Dockerpfade etc. anpassen oder? Idealerweise sollten die Docker, also system und appdata auf dem SSD Pool liegen oder hast du das anders gemacht? Wenn du alle Shares, die auf dem HDD Pool liegen beim Cache auf Yes stellst und den Mover startest, dann wird der Mover alles vom Pool aufs Array verschieben. Dann prüfst du ob der HDD Pool wirklich leer ist und löst ihn auf. Rechts über das Ordnersymbol kannst du die Dateien des HDD Pools einsehen. Erst auflösen, wenn wirklich keine Dateien mehr drauf liegen!

Ja, Hardlinks funktionieren nur auf Dateisystem-Ebene und zuverlässig nur bei ext4, xfs oder btrfs. Eine Lösung wäre deine eigene "Cloud" bei Mutti hinzustellen. Erst hatte ich gehofft, dass das alternativ mit tar geht, aber das geht leider nicht, wenn man das tägliche Backup in ein jeweils eigenes Archiv packt: https://unix.stackexchange.com/a/665190/101920 Stattdessen müsste man jeden Tag den kompletten Backupordner eines Shares in ein tar packen: tar --create --file=/mnt/user/Backup/Shares/Music.tar /mnt/user/Backup/Shares/Music Das tar enthält dann die Hardlinks, ist also platzsparend, aber man hat man Ende eine immer größer werdende Datei, die man immer wieder komplett in die Cloud hochladen müsste (rsync könnte evtl nur Teile der Datei aktualisieren, aber welche Cloud unterstützt schon rsync). Eine andere Variante wäre, dass man für die Cloud inkrementelle Archive erstellt: https://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html Ich habe zB vom ersten Backup gerade wie folgt ein tar erstellt: tar --create --gzip --file=/mnt/user/Backup/Shares/Music/backup1.tar --listed-incremental=/mnt/user/Backup/Shares/Music/tar.snar /mnt/user/Backup/Shares/Music/20200701_044011 Vom zweiten Backup erstelle ich gerade so ein tar: tar --create --gzip --file=/mnt/user/Backup/Shares/Music/backup2.tar --listed-incremental=/mnt/user/Backup/Shares/Music/tar.snar /mnt/user/Backup/Shares/Music/20200801_044013 Allerdings wäre das "echt" inkrementell. Dh für die Wiederherstellung des neunten Backups, müsste ich die ersten neun Backups aus der Cloud herunterladen und das ausführen: tar --extract --listed-incremental=/dev/null --file backup1.tar tar --extract --listed-incremental=/dev/null --file backup2.tar tar --extract --listed-incremental=/dev/null --file backup3.tar tar --extract --listed-incremental=/dev/null --file backup4.tar tar --extract --listed-incremental=/dev/null --file backup5.tar tar --extract --listed-incremental=/dev/null --file backup6.tar tar --extract --listed-incremental=/dev/null --file backup7.tar tar --extract --listed-incremental=/dev/null --file backup8.tar tar --extract --listed-incremental=/dev/null --file backup9.tar Nicht so richtig toll, aber immerhin platzsparend.

Dazu einfach mal schauen was in dem Ordner enthalten ist: Erstmal für jeden Container ein Ordner: Wenn ich die drei Ordner im laufenden Betrieb lösche, dann ist der Tab "docker" in Unraid leer. Ich kann aber über Apps > Previous Apps die Container ganz normal wieder ohne Datenverlust starten und die Ordner werden neu erstellt. Die Ordner werden übrigens auch gelöscht und neu erstellt, wenn man einen Container bearbeitet. Ich habe das gerade mal mit Nginx gemacht: Parallel dazu habe ich ganz oft den Ordner in neuen Tabs geladen: Vorher: Nach dem "Removing": Und sobald der Container wieder erstellt wurde gibt es einen neuen Ordner "30b0...": Im Ordner "30b0... " sind nun auch alle Dateien neu, was man am Datum erkennt: Fazit: Der Inhalt des Ordners ist unwichtig. Aber: Wenn man den Docker Service startet, dann einen Container hinzufügt und der Server abstürzt, dann ist dieser hinzugefügte Container nach einem Neustart erstmal weg. Er kann aber problemlos und ohne Datenverlust über Apps > Previous Apps wieder installiert werden. Update: Passiert nicht mehr.

Ok, und besser geht das nicht? Weil das ist ja genauso wie bei mir. Der übernimmt einfach 1:1 den Albumnamen. Bei Dir steht zB "Jack Reacher 01 G". Der eigentliche Titel vom Album ist dadurch abgeschnitten. Erwartet hätte ich es so: Dh er liest zuerst den Gruppennamen der Hörspielserie aus, in dem Fall also "Jack-Reacher-Reihe": https://musicbrainz.org/series/6bb4bcff-ee6e-4e41-a4d1-0631fccd18bb Und daraus extrahiert er dann alle Alben-Titel, die man in seiner Sammlung hat und übernimmt diese 1:1 und nicht diesen "Kuddelmuddel", den man selbst in den MP3 tags hinterlegt hat. Weil was macht Plex denn, wenn man mehrere Hörspielreihen eines Künstlers besitzt? Nehmen wir zB H. G. Francis: https://musicbrainz.org/artist/c7d4bc4a-ccb2-4cdb-b0ae-b4c6b4902ccc Der hat viele Reihen: Gruselserie: https://musicbrainz.org/series/982cb14c-069a-4b47-af66-09360e62d0dd Edgar Wallace - Europa: https://musicbrainz.org/series/db80ffa7-b67c-45af-9889-3e71304cec27 Dreamland Grusel: https://musicbrainz.org/series/37f29ce8-f986-4171-943e-da4c142368bd Das würde dann ja, wenn ich das richtig verstehe bei Plex alles auf einer Seite angezeigt werden?!

Haben wir auch.

Die erste Frage wäre: Geht es denn ordentlich? Wenn ja: Was wäre denn die "optimale" Bezeichnung? Hier ein Beispiel: zB ist "hat Geburtstag" neu dazu gekommen. Gerade indexiert und vom Jahr her ist das denke ich richtig, aber warum übernimmt Plex die "012" vom Album-Titel? Ich hätte jetzt erwartet, dass Plex den Album-Namen von MusicBrainz übernimmt, also "Folge 12: ... hat Geburtstag": https://musicbrainz.org/artist/2c89e930-7769-403f-8145-f215bb8fb5ba Dann wäre ja alles einheitlich. Oder läuft das bei Musik nicht so wie bei Filmen?

Hier habe ich noch etwas Interessantes gefunden: https://forums.unraid.net/topic/95674-gpu-passthrough-with-single-gpu/?tab=comments#comment-915760

Bei Filmen und TV Serien weiß ich genau wie ich sie benennen muss, aber bei Musik habe ich bei Plex noch gar keine Ahnung. Ich habe die Alben zB so im Ordner: Das wird zwar in Plex beim Interpreten richtig zugeordnet, aber ich hätte jetzt wie bei einer TV Serie erwartet, dass man so eine schöne sortierte Liste hat und kein völliges Durcheinander: Also die Jahreszahlen scheinen ja teilweise zu stimmen, aber die Titel sind immer anders (mal mit Zahl und mal ohne). Ich dachte Plex holt sich die Alben bei einer Datenbank wie bei Filmen und benennt sie einheitlich?

Ursachen Wer einen SSD Cache einsetzt, hat evtl schon festgestellt, dass er permanente Schreibzugriffe auf der SSD hat. Es gibt dafür verschiedene Ursachen: Write Amplification Das bedeutet es wird mehr auf das Laufwerk geschrieben als die Daten eigentlich groß sind und das liegt daran, dass der festgelegte Datenblock größer ist als die Daten selbst oder es werden je nach Dateisystem zusätzliche Informationen wie Prüfsummen, Metadaten oder Journaling gespeichert, die eine hohe Amplification resultieren können. Healthcheck Wenn ein Container diese Funktion besitzt, schreibt er alle 5 Sekunden (!) in die Dateien "/var/lib/docker/containers/*/hostconfig.json" und "/var/lib/docker/containers/*/config.v2.json". Diese ermöglicht den "healthy", "unhealthy" oder "health: starting" Status in der Docker Übersicht: Mir bekannte Container, die das nutzen sind zB Plex, Pi-Hole oder der Nginx Proxy Manager. Container Logs Über die Logs eines Containers können wir sehen was er gerade macht. Manche Container schreiben sehr viel in "/var/lib/docker/containers/*/*-json.log". Ich hatte zB schon eine 500MB große Log-Datei bei Plex Interne Logs oder temporäre Dateien Innerhalb eines Containers können ebenfalls Logs oder temporäre Dateien erstellt werden. zb schreibt der Nginx Proxy Manager im Pfad /var/logs ständig in Log-Dateien oder der Unifi-Controller ständig in /tmp temporäre Dateien. Mit dem folgenden "find" Kommando können wir uns alle Dateien ausgeben lassen, die durch Container oder dem Docker Dienst geschrieben werden: find /var/lib/docker -type f -not -path "*/diff*" -print0 | xargs -0 stat --format '%Y:%.19y %n' | sort -nr | cut -d: -f2- 2> /dev/null | head -n30 | sed -e 's|/merged|/...|; s|^[0-9-]* ||' Es listet die 30 zuletzt geänderten Dateien auf. Wiederholt man das Kommando, dann sieht man schnell welche Dateien (teilweise im Sekundentakt) immer wieder aktualisiert werden: 09:36:29 /var/lib/docker/containers/*/hostconfig.json 09:36:29 /var/lib/docker/containers/*/config.v2.json 09:12:45 /var/lib/docker/containers/*/*-json.log 09:12:34 /var/lib/docker/overlay2/*/merged/tmp/*.log 09:12:34 /var/lib/docker/overlay2/*/merged/var/log/*.log ... 09:12:34 /var/lib/docker/btrfs/subvolumes/*/var/log/*.log Gegenmaßnahmen Was können wir nun dagegen tun: Docker vom docker.img auf "Directory" umstellen (ja, "/docker/docker/" ist richtig!): Damit reduzieren wir schon mal die Write Amplification, da das Schreiben einer kleinen Zeile in eine log/json-Datei mehr Datenblöcke im docker.img ändern kann, als das beim direkten Zugriff auf die Datei der Fall ist. Hinweis: Dadurch werden alle Custom Networks und Container gelöscht. Diese können dann einfach (ohne Datenverlust) über Apps > Previous Apps wieder installiert werden (Custom Networks müssen natürlich vorher neu erstellt werden! Geht übrigens auch per Kommandozeile) Bonus: Wer den Share "system" beim Cache auf "Prefer" gestellt hat, der sollte auch gleich den Pfad auf /mnt/<cache-pool-name>/docker/docker ändern. Grund: Die CPU wird bei /mnt/user... mehr belastet. Optional: Ist das erledigt und setzt man nur eine SSD ein, sollte man außerdem über den Wechsel von BTRFS zu XFS nachdenken, da XFS eine deutlich kleinere Write Amplification besitzt. Das ginge so: Alle Shares beim Cache von "Prefer" auf "Yes" stellen, Docker & VM Service auf "No", Mover starten, SSD sichten ob sie wirklich leer ist, SSD umformatieren, alle geänderten Shares beim Cache zurück auf "Prefer", Mover starten, HDD sichten ob sie wirklich leer ist, Docker & VM Service auf "Yes". Wir ändern über die Go-Datei den Unraid Code, so dass automatisch eine RAM-Disk vom Pfad /var/lib/docker/containers erstellt wird, in dem die healthcheck-Dateien liegen. Alternativ: Bei allen Containern mit "healthy" status folgendes einstellen (siehe auch unten) Wir ändern über die Go-Datei den Unraid Code, so dass automatisch eine RAM-Disk vom Pfad /var/lib/docker/containers erstellt wird, in dem die Container Logdateien liegen. Alternativ: Bei allen Containern die Container Logs umlenken: oder deaktivieren: Was wann gebraucht wird, erfahrt ihr hier. Um die Aktivitäten innerhalb der Container ermitteln zu können, müssen wir wissen welcher Container in welchen Pfad schreibt. Das oben genannte "find" Kommando hat zB diesen Pfad ausgegeben: /var/lib/docker/overlay2/b04890a87507090b14875f716067feab13081dea9cf879aade865588f14cee67/merged/tmp/hsperfdata_abc/296 rgendein Container schreibt also in den Ordner "/b04890a875...". Mit diesem Kommando finden wir heraus welcher das ist: csv="CONTAINER;PATHS\n"; for f in /var/lib/docker/image/*/layerdb/mounts/*/mount-id; do subid=$(cat $f); idlong=$(dirname $f | xargs basename); id="$(echo $idlong | cut -c 1-12)"; name=$(docker ps --format "{{.Names}}" -f "id=$id"); [[ -z $name ]] && continue; csv+="\n"$(printf '=%.0s' {1..20})";"$(printf '=%.0s' {1..100})"\n"; [[ -n $name ]] && csv+="$name;" csv+="/var/lib/docker/(btrfs|overlay2).../$subid\n"; csv+="$id;"; csv+="/var/lib/docker/containers/$idlong\n"; for vol in $(docker inspect -f '{{ range .Mounts }}{{ if eq .Type "volume" }}{{ .Destination }}{{ printf ";" }}{{ .Source }}{{ end }}{{ end }}' $id); do csv+="$vol\n"; done; done; echo ""; echo -e $csv | column -t -s';'; echo ""; In meinem Fall ist das der "unifi-controller": Außerdem prüfen wir genau in welchen Unterordner der Container geschrieben hat: /merged/tmp/hsperfdata_abc/296 Das "/merged" (oder auch "/diff") kann man ignorieren. Der Pfad des Containers beginnt also mit "/tmp". Diesen Pfad können wir normalerweise bedenkenlos in eine RAM-Disk packen, da bei Debian, Ubuntu und Unraid das bereits von Haus aus eine RAM-Disk ist und Anwendungen in der Regel ja auch auf diesen Betriebssystemen laufen. Aber Achtung: Falls ihr einen anderen Pfad ermittelt habt, darf dieser in der Regel nicht in eine RAM-Disk verlagert werden, da dass zum Datenverlust im Container führen kann! Wir öffnen nun also die Einstellungen des ermittelten Containers, scrollen nach unten und wählen "Add another Path...": Nun tragen wir "/tmp" beim "Container Path" ein und "/tmp/<containername>" beim "Host Path": Sobald ihr nun den Container startet, schreibt der Container nicht mehr in "/var/lib/docker/.../tmp", also auf eure SSD, sondern in "/tmp/unifi-controller" und damit in die RAM-Disk von Unraid. Nachdem das getan ist, wiederholen wir das "find" Kommando erneut und vergleichen noch mal die Ergebnisse: 2021-08-18 10:06:36.256939658 +0200 /var/lib/docker/containers/*/hostconfig.json 2021-08-18 10:06:36.256939658 +0200 /var/lib/docker/containers/*/config.v2.json 2021-08-18 09:49:32.698781862 +0200 /var/lib/docker/containers/*/*-json.log Die Schreibzugriffe auf die "/tmp" Ordner sind nun alle verschwunden, da wir diese in die RAM-Disk von Unraid ausgelagert haben. Die Schreibzugriffe auf /var/lib/docker/containers sehen wir zwar noch (außer ihr verwendet die --no-healthcheck/--log-driver Lösung, dann werden auch diese verschwunden sein), können diese aber ignorieren, da wir dafür über die Code-Änderung eine RAM-Disk ergänzt haben. Zur Belohnung genießen wir dann mal keine Schreibzugriffe auf unserem Cache 😁 Pedanterie Eventuell stellt ihr fest, dass trotzdem noch Daten auf die SSD geschrieben werden und nun wollt ihr es genau wissen. In diesem Fall lohnt es sich das "find" Kommando so anzupassen, dass ihr euch die neuesten Dateien in einem "appdata" Share anzeigen lasst: find /mnt/cache/appdata -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n30 In meinem Fall kam das dabei heraus und ich habe auch gleich mal eingekreist, was man optimieren könnte (auf eigene Gefahr, versteht sich): Da der Nginx-Proxy-Manager bereits eine RAM-Disk für /tmp benötigte, habe ich dann entschieden auch /data/logs in eine RAM-Disk zu packen, so dass ich es schlussendlich so gelöst habe: Den Pfad vom Unifi-Controller habe ich gelassen, da der letzte Schreibzugriff bereits vor mehreren Minuten erfolgte, so dass ich keinen Verschleiß der SSD befürchte. Ich habe dann ein paar Minuten gewartet und das Kommando wiederholt und tatsächlich ist mir dann noch was aufgefallen: 1.) Der Zerotier Container schreibt alle 30 Sekunden in eine conf-Datei, was mich nervt, aber nachdem ich die Datei versucht habe zu öffnen und nur Binärdaten darin enthalten sind, lasse ich davon erstmal die Finger. 2.) Der Unifi-Controller schreibt ständig in haufenweise Datenbank-Dateien. Diese sind natürlich für den Betrieb des Containers notwendig, weshalb wir daran nichts ändern können. Da mich aber die Statistiken von Unifi eh nicht interessieren, lasse ich den Container wie gehabt abgeschaltet. Ich aktiviere den nur, wenn ich etwas an den Access-Points ändern möchte. Alternativ könnte man überlegen ein Script zu schreiben, dass /mnt/cache/appdata/unifi-controller in eine RAM-Disk packt und regelmäßig den Container stoppt, die RAM-Disk sichert und dann wieder startet. Den Aufwand spare ich mir aber. 3.) Der Plex-Container schreibt alle paar Minuten in eine Log-Datei, was ich aber akzeptabel finde.

@TexasUnraid Ok finally solved it: https://forums.unraid.net/bug-reports/stable-releases/683-unnecessary-overwriting-of-json-files-in-dockerimg-every-5-seconds-r1079/?tab=comments#comment-15472 By that the RAM-Disk is created every time the docker service starts and removed if is stopped. I tested it only with the docker "path" option, but as the ram disk is created on "/var/lib/docker/containers" it should work for the docker.img as well. My Plex container now runs without the "--no-healthcheck" option and I have no write activity on my SSD 😀 In addition all container logs are in the RAM Disk as well. So killed two birds with one stone 🥳

Wie hast du zurückgebaut? Ich würde nämlich eher auf den tippen.

Ich teste die Tage das Script auch mal in Ubuntu. Mal sehen ob man da Anpassungen benötigt

LuckyBackup oder was auch immer auf dem Ziel installieren und die Dateien ausschließlich lesend abholen. Um Quelle und Ziel zu vernichten, müssten dann erstmal beide gehackt werden.

Ok, I found the problem. Although I created the ram disk under /mnt/cache/system/docker: df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 32850360 176 32850184 1% /mnt/cache/system/docker/docker/containers It is not part of /var/lib/docker (which is a mount of /mnt/cache/system/docker/docker) ls -la /mnt/cache/system/docker/docker/containers total 0 drwx-----x 5 root root 100 Aug 17 17:08 ./ drwx--x--x 16 root root 271 Aug 17 17:49 ../ drwx-----x 4 root root 220 Aug 17 17:39 48d6ab4b4ef6c6a480f59a8b8f7152be3d9e7a2b3c3f1e95a87225e1a25c8cfd/ drwx-----x 4 root root 220 Aug 17 17:41 7d92ab7aad8a794e78635a346b700585a30af1bea35946ed6a5146a1799bfd27/ drwx-----x 4 root root 200 Aug 17 17:41 82f6d43a65b699d1c988349274720cd59b230866159d638c5278c701ee66e3b1/ ls -la /var/lib/docker/containers total 0 drwx-----x 2 root root 6 Aug 17 17:47 ./ drwx--x--x 16 root root 271 Aug 17 17:49 ../ Not sure why this happens, but I can't add a ram disk inside of /var/lib/docker as after this paths contains files, the docker service is already running, which would break the containers. I even tried to create a tmpfs mount on /var/lib/docker/containers before I start the docker service, but starting the docker service creates the mount /var/lib/docker > /mnt/cache/system/docker/docker, which overwrites the tmpfs mount 🙈

Sadly it does not work. Something is really strange between /var/lib/docker and /mnt/user/system/docker. I tried several ram disk paths, but it seems to write to an invisible path.

Der Angreifer hat dann zwar nur in diesem einen Ordner Schreibrechte, aber da liegen ja die Backups drin. Verschlüsseln/löschen kann er sie dann ja trotzdem. Erlebe du mal eine Ransomware-Attacke. Dann reden wir weiter.

Dann hätte Unraid aber wieder Schreibrechte auf der Syno und bei einer Sicherheitslücke könnte der Angreifer das Backup auf der Syno platt machen.

I found an alternative solution: https://forums.unraid.net/bug-reports/stable-releases/683-unnecessary-overwriting-of-json-files-in-dockerimg-every-5-seconds-r1079/?tab=comments#comment-15472 By that "--no-healthcheck" isn't needed anymore. You missed to explain, that it is needed to add this to "extra parameters" of a container. The "tmpfs-mode" can be removed as 1777 is the default. PS I'm using the same trick for Plex and changed the transcode path to /tmp: Another idea would be to replace all these paths by tmpfs mounts: find /var/lib/docker/overlay2/*/merged/tmp -type d -maxdepth 0 But I'm not sure about this as docker changes the ids everytime the container is re-created. Needs testing.

@limetech I solved this issue as follows and successfully tested it in: Unraid 6.9.2 Unraid 6.10.0-rc1 Add this to /boot/config/go (by Config Editor Plugin): Optional: Limit the Docker LOG size to avoid using too much RAM: Reboot server Notes: By this change /var/lib/docker/containers, which contains only status and log files, becomes a RAM-Disk and therefore avoids wearing out your SSD and allows a permanent sleeping SSD (energy efficient) It automatically syncs the RAM-Disk every 30 minutes to your default appdata location (for server crash / power-loss scenarios). If container logs are important to you, feel free to change the value of "$sync_interval_minutes" in the above code to a smaller value to sync the RAM-Disk every x minutes. If you like to update Unraid OS, you should remove the change from the Go File until it's clear that this enhancement is still working/needed! Your Reward: After you enabled the docker service you can check if the RAM-Disk has been created (and its usage): Screenshot of changes in /etc/rc.d/rc.docker and /usr/local/emhttp/plugins/dynamix/scripts/monitor

Wie hast du das verifiziert? Denk dran, dass man das nicht einfach so sehen kann. Die Größen der Ordner kannst du zB so ermitteln: du -d1 -h /Pfad_zur_USB_Platte/Name_des_Unterordners | sort -k2 Hier siehst du zB dass die letzte Datensicherung der VM gar nichts belegt, aber im Ordner sind trotzdem 34.4GB große Dateien:

Genau das sollte ja gehen, wenn du zwei Scripte nimmst und den Zielpfad entsprechend verlängerst. Also nicht beide auf "/Backup" zielen lassen, sondern ein Script auf "/Backup/Sharename1" und das andere auf "/Backup/Sharename2". Oder hattest du das schon versucht? Wenn nein, dann probiere mal "Backup/einenAndereNamen", falls mein Script warum auch immer den Sharenamen ersetzen sollte. Wenn deine Syno eine Sicherheitslücke hat, ist alles weg, denn die Syno hat ja Root Zugriff auf den Unraid Server. Wer schreiben kann, kann schreiben. Und das gilt es zu vermeiden, wenn man sicher gegen Ransomware sein möchte. Also wenn solltest du Active Backup mit einem rein lesenden Zugriff kombinieren. Das Script erstellt völlig transparente Backups und braucht daher keine Software zur Wiederherstellung. Jeder Ordner ist ein Vollbackup und durch Hardlinks trotzdem inkrementell. Man nimmt also den Ordner von vor 3 Tagen und es sind 1:1 alle Dateien von der Quelle drin. Bei Active Backup, was ich früher auch gerne eingesetzt habe, gibt es auch inkrementelle Backups, aber die erfordern den Erhalt des gesamten Backup-Verlaufs, da jedes Folge-Backup auf das vorherige aufbaut. Ohne Active Backup kann man also nichts wiederherstellen. Das ist der Hauptunterschied zwischen den beiden Konzepten. Eine Absicherung gegen Ransomware bietet mein Script übrigens genauso wenig wie Active Backup. Diese Absicherung kommt erst dadurch zu Stande, in dem man es intelligent einsetzt. Also wie schon gesagt, die Quelle ausschließlich lesend mountet. Jein, man braucht ein teureres Syno Modell. Die J-Modelle können das zB nicht: https://www.synology.com/de-de/dsm/packages/ActiveBackup Außerdem geht es nur, wenn man BTRFS im RAID verwendet.

Dann haben wir denke ich aneinander vorbei gesprochen. Normal ist es so: Backups/Sharename1/20120801_040000/Sharename1 Backups/Sharename2/20120801_040000/Sharename2 Der letzte Unterordner ist dabei wie gesagt eigentlich überflüssig, aber wegen dem einfacheren Copy & Paste fand ich das irgendwie praktischer (und ich bin wie gesagt noch unsicher wegen der Position der Log-Datei). Du möchtest es dagegen so haben oder? Backups/20120801_040000/Sharename1 Backups/20120801_040000/Sharename2 Das Problem hierbei ist, dass es mehr als ein Backup pro Tag geben kann und der Ordner einen sekundengenauen Namen trägt ("_044022" = 04:40:22 Uhr nachts) und jeder Quellordner ein eigenes Script mit eigenen Aufbewahrungsregeln haben kann. Also vielleicht sicherst du zB den Share "domains" nur 1x pro Woche und den Share "appdata" 2x pro Tag und deinen PC halbstündlich und alles soll unterschiedlich lange aufbewahrt werden. Behalte das nun mal im Hinterkopf und nun stell dir vor du siehst dein Backup-Verzeichnis: Wo ist nun das vorletzte Backup von domains drin? Nicht jeder hat einen Datei-Explorer mit Verzeichnisbaum. Das einzige was ich mir in Zukunft tatsächlich vorstellen kann, ist dass man es so macht: Backups/Sharename1/20120801_040000 Backups/Sharename2/20120801_040000

Wenn es nicht gerade ein neues Mainboard werden soll, würde ich jetzt 20 € in eine USB PCIe Karte investieren. Irgendwas mit einem ASMedia oder JMicron Chip sollte denke ich Out of the box in Unraid laufen.

Ja der läuft sogar als Bridge. Du musst nur die IP in den Einstellungen hinterlegen. Sollte auf den letzten Seiten des Unifi Support Threads stehen. Ich hatte das Problem nämlich auch 😉

Good to know, but does not work either. I even tried to add the filter to the top of the file because I thought it could be related to this bug: EDIT: It works only if the rule is added after the "$RuleSet local" line, so I added this to my Go file: # ------------------------------------------------- # Suppress IPv6 Router Advertisement logs # ------------------------------------------------- sed -i '/$RuleSet local/a:msg,contains,"Router Advertisement from" stop' /etc/rsyslog.conf /etc/rc.d/rc.rsyslogd reload