mgutt

Bezogen auf ZFS (und den manuell erstellten SMB Shares), ja, aber nicht das mit dem USB Stick. Das machen sehr viele so, die unRAID nur als VM Host verwenden. Updates wird das ebenfalls überleben. unRAID in einer VM geht übrigens nur mit durchgeschliffenem USB Stick. unRAID wird nicht auf einem Datenträger installiert, sondern installiert sich bei jedem Booten automatisch in den RAM.

Hmm komisch. Welches Netz nutzt der Container? Ist die Mac-Adresse wie die von den Containern aufgebaut? Man erkennt ja ein Muster 02:42...

Uff. 1.) Which power supply are you using? 2.) How do you use the GPU? It's power consumption should be in idle between 8 and 35W, but if it is not used by Unraid or an VM it has a much higher power consumption (as it never reaches the idle state). 3.) Aren't you using a spin down delay for your HDDs? 4.) Why do you have a SATA extension card installed although your MB has 8 SATA ports onboard? 5.) Why do you have an Asus 10G card installed although your MB has 10G onboard? 6.) Why do you have an additional USB PCIE Card? Your MB is for sure a bad basis for an efficient server as it has: - additional SATA controller for Port 7 and 8 - TB - WiFi - 10G - RGB A small, but additional impact are high-frequency RAM modules and their amount (2x 32 GB is more efficient than 4x 16 GB)

Also hast du wieder zwei Clients mit der selben IP? Das darf nicht sein. Egal ob es nun geht oder nicht. Das wird nicht lange gut gehen. Ich vermute mal, dass du einen Container oder VM mit der selben IP wie den Unraid Server betreibst. Oder schlicht ein ganz anderes Gerät in deinem Netzwerk. Mit diesem Befehl kannst du dir alle MAC-Adressen aller Container anzeigen lassen: docker inspect -f '{{.Name}}{{ printf ": " }}{{range .NetworkSettings.Networks}}{{.MacAddress}}{{end}}' $(docker ps -aq) Ist da die MAC-Adresse dabei, die du in der Fritz!Box als separates Gerät siehst? Hinweis: Viele Container haben MAC-Adressen und tauchen nicht in deiner Fritz!Box auf, weil der Container im bridge Netzwerk läuft. Nach außen ist der nur über die MAC-Adresse des Unraid Servers zu sehen. Sie existiert nur intern und könnte über die Console des Containers so verifziert werden: ls /sys/class/net/*/address | while read line; do echo -n "$line: "; cat "$line" ; done

Hast du RSS verifiziert? Hast du einen Disk Share angelegt?

Server abstecken und in der Box die Freigaben löschen. Danach beide Geräte unter Netzwerk löschen. Auch nach unten scrollen bei den früher verbundenen Geräten schauen. Evtl auch die löschen. Nun Server wieder verbinden und Freigabe neu einrichten.

die fc/fd Adressen nennt man Unique-Local-Unicast-Adressen: https://de.wikipedia.org/wiki/IPv6#Link-Local-Unicast-Adressen die fe80 sind die Link-Local-Unicast-Adressen: https://de.wikipedia.org/wiki/IPv6#Link-Local-Unicast-Adressen Konvertiert man IPv4 in IPv6, kann die Adresse sogar mit 0000: bzw ::ffff anfangen: https://stackoverflow.com/a/56865588/318765 Ach ja und man kann natürlich auch 0000: in 0: kürzen. Die wunderbare komplexe Welt der IPv6. 😒

fd Adressen sind lokalen IPv6. Da müsste man mal das Script anschauen und bei mehreren IPv6 entsprechend rausfiltern. Es können übrigens noch mehr als zwei sein.

Version 1.0 released: # - Allow setting "--dry-run" as rsync option (which skips some parts of the script) # - Create destination path if it does not exist # - Fixed wrong minimum file count check # - Fixed broken recognition of remote "mv" command As announced the script creates the destination directory, now. And it is possible to test the script by adding the rsync option "--dry-run" which disables all "mv" and "rm" commands.

Ist das so? Ich kenne keinen Fall und wir haben auf der Arbeit massig USVs (bei über 100 Standorten). Ansonsten ist es vermutlich klassisch eine Frage der Batteriechemie. Manche sind ja wie Brandbomben und andere verkokeln einfach nur.

Bitte beachte, dass sowas zu Konflikten führen kann: - Du kopierst deine Filme, merkst, dass der Cache läuft und stellst auf Nein. Jetzt ist zB der Film "Batman" auf dem Cache. - Du kopierst wieder deine Filme und sie landen direkt auf dem Array und wenn du fertig bist, aktivierst du den Cache wieder - Du wartest, aber der Mover verschiebt die Filme nicht, denn "Batman" ist durch das zweite Kopieren bereits auf dem Array In so einem Fall müsste man dann manuell Hand anlegen und die Dateien auf dem Cache löschen. Das Deaktivieren des Caches hättest du dir übrigens sparen können, in dem du einfach den Mover deaktiviert hättest und bei dem Share bzw der SSD einen Minimum Free Space von sagen wir mal 50GB festgelegt hättest. Der Cache wäre dann irgendwann zu voll gewesen und er hätte die weiteren Filme direkt auf das Array geschrieben.

Auf Grund der wenigen SATA Ports ginge es denke ich nur so: Du packst einen USB Stick ins Array, damit du Docker und VM nutzen kannst (ist eine grundlegende Voraussetzung in Unraid). Nun installierst du das ZFS Plugin und mountest deine zwei ZFS RAIDs per Kommandozeile nach /mnt/<zfs_pool> und packst in die Go File die entsprechenden Kommandos, damit das beim Neustart automatisch passiert. Jetzt heißt es alle Pfade in den Docker-Einstellungen und VM-Einstellungen auf /mnt/<zfs_pool>/<blabla> ändern. Außerdem kannst du vom Prinzip alle Shares löschen (die kann man nicht auf deine ZFS Pools umbiegen, sondern zielen auf den USB Stick). Nun kannst du über die SMB Einstellungen eigene SMB Freigaben von Hand festlegen. Beispiel mit Schreibrechten: [Fotos] path = /mnt/<zfs_pool>/Fotos comment = browseable = yes # Private writeable = no read list = write list = max,maria valid users = max,maria case sensitive = auto preserve case = yes short preserve case = yes Oder nur mit Leserechten: [Filme] path = /mnt/<zfs_pool>/Filme comment = browseable = yes # Private writeable = no read list = max,maria write list = valid users = max,maria case sensitive = auto preserve case = yes short preserve case = yes "max" und "maria" sind wiederum Nutzer, die du in Unraid angelegt hast. Sollte ZFS irgendwann mal offiziell unterstützt werden, würde der Teil mit dem manuellen Mounten und den von Hand angelegten SMB Freigaben wegfallen. Wäre also deutlich komfortabler. Schlussendlich wird es aber nie so sein, dass man ZFS im Array nutzen kann (bzw hätte dann keinen Vorteil, da die Selbstheilung bei einzelnen Volumes nicht möglich ist). Daher wirst du immer mit dem leeren USB Stick im Array arbeiten müssen.

Such mal hier im Forum nach USV. Da gibt es schon ein paar Themen zu. Ansonsten Amazon Bewertungen lesen. Wenn dir eine Wiederherstellung kein Kopfzerbrechen bereitet, kannst du natürlich auch auf eine USV verzichten.

Eine USV sollte man in jedem Fall haben, wenn man BTRFS formatierte Datenträger hat. Bei XFS ist es eher egal. BTRFS RAIDs mögen das gar nicht und man sollte immer einen scrub machen, was unRAID leider nicht selbst tut.

169.254. heißt, dass dein Server keine Verbindung zum Router hat bzw von dem keine IP-Adresse bekommt.

@Meles Meles With version 1.0 I will add a solution which creates the target path through an rsync hack if it does not exist: As you can see it requires enabling the new setting "create_destination" (enabled by default). In addition I totally changed the source/path settings as follows: Now the user needs to set the full destination path for each backup job individually (which is automatically created if it does not exist). And thanks to this change I could completely remove the replacement path thing. 😋 I will test the new version and release it in a few hours.

Version 0.9 has been released: # - Fixed wrong backup path in some situations # - User-defined replacement rules for backup path # - new setting "skip_error_host_went_down" which skips backups if host went down during file transfers # - Important Change: /source/<timestamp>/source has been changed to /source/<timestamp> # - Fixed wrong counting on keeped backups if multiple source paths have been set Now, everyone is able to setup their own replacement rules for the backup path. The default replacements are: replace_paths=( "/mnt/user;/Shares" "/mnt/;/" ) This means if the source path contains "/mnt/user" it will be replaced against "/Shares". So instead of this path: /mnt/user/Backups/mnt/user/Music/<timestamp> It will copy the files to: /mnt/user/Backups/Shares/Music/<timestamp> Feel free to create your own rules or remove all of them. Another important change is the subdir after the <timestamp> path. Many people are confused why it's generated "twice" like "/Music/<timestamp>/Music". Now it's only "/Music/<timestamp>". Note: This change will cause generating a new full backup without hardlinks. Of course old backups will stay intact.

Why do you set a destination path, which does not exist?! This is something which I should not add, as some people backup to directories, which are mounts and if they don't exist while the backup starts, mkdir would create a destination which should never exist. Simply think about a user who accidentally starts a backup to an USB drive, SMB mount or SSHFS mount, which isn't connected or lost connection. In unRAID you would then create a dir which is located in the RAM and crash the server. Same is valid if you write locally to Unraid and stop the array. It replaces /mnt/user against /Shares and not only adds /Shares. It's only a small feature to shorten the destination path. I think I will move this to the settings and let the user decide which replacement rules should be used. Yes you are correct. I will fix this bug.

Stimmt. Ich dachte mit unBalance geht das nicht, aber geht ja wohl 🙈 Ich habe die Anleitung nun auch um unBalance erweitert.

Ich habe den gerade mal testweise installiert. Bei mir stoppt der Container direkt und im Log steht folgende Fehlermeldung: ts=2021-12-19T21:06:53.830Z caller=main.go:437 level=error msg="Error loading config (--config.file=/etc/prometheus/prometheus.yml)" err="open /etc/prometheus/prometheus.yml: no such file or directory" Ich habe dann hier den Tipp gelesen: https://forums.unraid.net/topic/87798-support-selfhostersnets-template-repository/page/14/?tab=comments#comment-979458 Also die prometheus.yml aus dem Download rauskopiert und nach /mnt/user/appdata/prometheus/etc/prometheus/prometheus.yml kopiert. Und nach wie vor der selbe Fehler. Also schaue ich mir die Container Einstellungen an und stelle fest, dass der Container /mnt/userappdata/prometheus/etc mit /etc/prometheus verlinkt hat. Solche Sachen werde ich wohl nie verstehen. Jedenfalls habe ich die yml nach /mnt/user/appdata/prometheus/etc/prometheus.yml verschoben. Danach ließ sich der Container fehlerfrei starten. Deine Fehlermeldung verweist dagegen auf /prometheus. Dieser Pfad ist im Container nach /mnt/user/appdata/prometheus/data verlinkt: Existiert dieser Ordner nach starten des Containers? Und was heißt "appdata" gelöscht. Du hast doch hoffentlich nicht den ganzen appdata Ordner, also den Share gelöscht?! Und falls du nur den Unterordner "prometheus" meinst, hast du ihn wirklich gelöscht? Prüfe was in /mnt/user/appdata liegt. Es kann hier keine Rechteprobleme geben, denn wenn du den Ordner gelöscht hast, dann wird der Container ihn mit den richtigen Rechten neu anlegen.

Glückwunsch, davon stimmt gar nichts 😅 Eine Parity ist keinen Platte wo Dateien drauf liegen, sondern sie enthält nur die "Quersumme" aller Daten aller Platten. Eventuell hilft dir diese Erklärung um ein RAID bzw die Parity besser zu verstehen: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-1021986 Deswegen kannst du zB 5 Platten mit jeweils 10TB im Array haben und brauchst trotzdem nur eine 10TB große Parity, um irgendeinen Festplattenausfall abzusichern. Nein. Wenn Platten einem Pool zugewiesen werden, dann bilden diese ein RAID, was ausschließlich von Unraid genutzt werden kann (zB für den Cache oder als Speichort für Docker Container). Auf diesem RAID könnte man dann aber zB virtuelle Festplatten als vdisk-Dateien ablegen, die dann von VMs verwendet werden. Wenn man dagegen eine Platte 1:1 durchschleifen möchte, muss man diese aus Sicht von Unraid ignorieren, also als Unassigned Device stehen lassen. Dann weist man sie der VM zu und nur die VM kann diese dann nutzen. Beide Methoden haben Vor- und Nachteile. Wenn du zB mit vdisk-Dateien arbeitest, hat das den Vorteil, dass du mehrere virtuelle Festplatten auf einer Platte ablegen kannst. Du kannst also problemlos 10 VMs starten, deren virtuelle Platten (vdisk-Dateien) in Wirklichkeit alle auf der selben Platte liegen. Das hat auch den Vorteil, dass du kompakte virtuelle Festplatten über Unraid sichern kannst. Hast du dagegen eine 1TB Platte 1:1 an die VM durchgeschliffen, dann hast du die komplett für die eine VM "verschwendet" und Backups gehen nur platzsparend, wenn du innerhalb der VM eine Backup-Software verwendest. Der Nachteil von mehren vdisks ist, dass du dir die Performance der Platte mit anderen Prozessen teilst, die ebenfalls auf die Platte zugreifen. Der klassische Aufbau bei Unraid ist eigentlich so: - viele große HDDs im Array als Speicherplatz für eher selten genutzte Dateien - mehrere SSDs im Pool als Speicherplatz für schnelle Uploads (Cache), häufig genutzte Dateien, Docker Container und virtuelle Festplatten (vdisks) Es sind aber zig andere Konstellationen denkbar. zB könnte man nur einen USB Stick ins Array packen und alle seine HDDs in einem Pool verwenden. Oder man hat nur SSDs, packt die alle ins Array und verzichtet auf Pools. Oder man hat neben dem Array mehrere Pools. Oder zusätzlich noch Datenträger, die man 1:1 an VMs durchschleift... Was man macht, hängt schlicht vom persönlichen Bedarf ab. Für den ersten Einstieg empfehle ich dir aber den klassischen Aufbau. Dh du machst eine New Config und weist die 6TB Platten wieder den Slots zu, wo sie vorher auch drin waren (daher der Screenshot). Dann nimmst du die zwei M.2 SSDs und erstellst daraus einen Pool. Fertig. Die SATA SSDs kannst du weglassen. Mehr Performance bringen dir die eh nicht in der VM, da sie auf 550 MB/s limitiert sind und nicht mal ansatzweise so viele parallele Zugriffe wie M.2 SSDs verarbeiten können. Das einzige was man evtl überlegen könnte, wäre ein zweiter Pool mit den SATA SSDs und darauf dann die Docker Container ablegen, damit diese Zugriffe von der M.2 weg kommen, aber ob das lohnt... hängt auch davon ab wie viele Container man schlussendlich im Einsatz hat und wie viel die eigentlich schreiben.

Viele kennen ja bereits mein Skript, mit dem man inkrementelle Backups erstellen kann: Eigentlich sind sie streng nach Definition gar nicht "inkrementell", da jedes Backup ein 1:1 Vollbackup darstellt. Da aber mit Hardlinks gearbeitet wird, transferiert rsync nur neue Dateien, wodurch der Speicherplatzverbrauch genauso gering ist wie bei inkrementellen Backups. Meiner Ansicht nach sind Hardlink-Backups das bessere inkrementelle Backup, da man alte Backup-Ordner nach Belieben einfach löschen kann, während die restlichen Vollbackups erhalten bleiben. Bei einem klassischen inkrementellen Backup ist das nicht möglich, da das alle Folgebackups zerstören würde. Jedenfalls habe ich nun Version 0.7 veröffentlicht, wo kleinere Fehler behoben wurden und es gibt auch neue Funktionen, die von anderen gewünscht waren: - Sicherung auf SSH Server - Temp, tmp, Cache ... Verzeichnisse ausschließen - Benutzerdefinierte rsync Optionen - Bessere Multi-Plattform Unterstützung (das Skript läuft nicht nur auf Unraid) - diverse rsync-Hacks, die es erlauben auf SSH Server zu sichern, die ausschließlich das rsync Kommando erlauben Gerade auf die rsync-Hacks bin ich echt stolz, da ich weltweit nichts dergleichen gefunden habe. Ich verschiebe zB komplette Ordner mit rsync ohne sie vorher zu kopieren oder ich lösche mit rsync, wo andere "rm" verwenden würden. Sogar das "find" Kommando konnte ich mit rsync ersetzen, um das letzte erfolgreiche Backup zu ermitteln. Dadurch können Administratoren einen SSH User verwenden, der ausschließlich das rsync Kommando verwenden darf. Obwohl ich schon einige Zeit investiert habe, gibt es immer noch massig Ideen umzusetzen: - besonders große Dateien wie vdisks splitten, um auch hier von Hardlinks zu profitieren - wenn Ordner gesichert werden, die von Containern genutzt werden, soll dieser automatisch gestoppt werden - Sicherung von SSH Servern (also als Quelle) - vor dem ersten Vollbackup testen ob das Ziel Hardlinks unterstützt Ich wurde auch gefragt, ob ich das nicht mal als Plugin herausbringen möchte. Der Haken daran ist, dass man sich dann die Möglichkeit verbaut das Skript auf anderen Plattformen einzusetzen. zB nutzen manche das Skript auf ihrer Syno und sichern damit auf ihren Unraid Server. Und wieder andere nutzen gar kein Unraid (buuuhh ^^). Ich müsste also einen Weg finden, womit ich das Skript 1:1 in einem Plugin nutzen kann. Muss ich mal sehen ob ich dazu irgendwann eine Lösung finde.

I've released version 0.7 with the following enhancements: # - Empty backups stay invalid (must include at least X files) # - Fixed growing log file problem # - Logs are now located in the backup dir itself # - Added support for SSH destinations (replaced find, rm and mv commands against pure rsync hacks) # - User-defined rsync options # - User can exclude directories, defaults are /Temp, /Tmp and /Cache # - Enhanced user settings (better description and self-explaning variable names) # - Multi-platform support (should now work with Unraid, Ubuntu, Synology...) # - Replaced potentially unsafe "rm -r" command against rsync # - User-defined rsync command to allow optional sshpass support # - Keep multiple backups of a day only of the last X days (default 1) # - Important Change: The latest backup of a month is kept as monthly backup (in the past it was only the backup of the 1st of a month) # - Important Change: The latest backup of a year is kept as yearly backup (in the past it was only the backup of the 1st january of a year) If you want to backup to an SSH server, simply add the login information to the backup_path in the following format: backup_path="user@server:/home/backups/" Of course this works only if you have exported your ssh keys to enable passwordless SSH connections. If you instead prefer "sshpass", you could enable these two settings: # user-defined rsync command alias rsync='sshpass -p "<password>" rsync' # user-defined ssh command alias ssh='sshpass -p "<password>" ssh -o "StrictHostKeyChecking no"' I have several ideas for the next version(s) left: # - chunksync hardlinks for huge files (like images) # - docker auto stop and start for consistent container backups (compare container volumes against source paths) # - auto accept ssh key, but only if /backup_path/source_path is empty (on very first execution) # - what happens if backup source disappears while creating backup (like a mounted smb share which goes offline) # - add support for ssh sources # - rare case scenario: log filename is not atomic # - test on very first backup if destination supports hardlinks # - check if ssh server supports "rm" (is 50% faster than rsync hack) # - should we use failed backups as source if last X backups failed (to allow progress)?

Tools > New Config und die HDDs da zuordnen wo sie waren (vorher Screenshot machen) und die SSD weglassen. Danach einen Pool mit der SSD erstellen. Wenn du nur eine SSD hast auch gleich Backups einrichten.

@ich777 Apache released l4j 2.16 as the special env var does not work and yesterday they released 2.17 because of another DoS hole. So the information on the official minecraft website is outdated. Only an update to the most recent version helps. As I'm using a custom paper server I downloaded the most recent version from here, which contains the most recent l4j: But I'm still waiting a few days until my server gets public access again.