bastl

Kann ich nachvollziehen. Was ich von meinen Tests her sehen konnte, funktioniert das meiste ja auch schon super. Bisher sind mir nur Kleinigkeiten aufgefallen was Bedienerfreundlichkeit angeht, was keine prio hat, wie die recht versteckte Option für den Restore-Test-Pfad. Eine genauere Job Planung für die Tests wäre dennoch in meinen Augen sinnvoll. Aktuell sag ich geplant, stell nen Intervall ein das Level, drücke Speichern und ein Klick auf "Jetzt Testen" entscheidet dann an welchem Tag und welche Uhrzeit der Test läuft. Ist so nicht gerade ideal keinen wirklichen Einfluß auf die Ausführungszeit zu haben. Dass so ein Test je nach größe des Repos und je nach Quelle auch schnell mal sehr lange dauern kann ist mir bewußt. Ein Hinweis dazu gibt es ja auch bereits, schonmal gut. Dennoch müßte man irgendwie dem User eine Option geben es detailierter konfigurieren zu können. 2 Kleinigkeiten hätte ich an dieser Stelle noch: für die Zeitplanung sowie Retention eine stündliche Option -H, --keep-hourly wäre super und ein Möglichkeit gezielt von Hand einzelne Backups aus einem Repo löschen zu können wäre noch toll. Durch meine Tests und durch die Typ-ID Umbenennung hatte ich in dem betreffenden Repo dann 3 Archive die angezeigt wurden aber nur 2 ausgelesen wurden. Löschen konnte ich über das WEB-UI das unter anderer "Typ-ID" erstellte Backup dann nicht und mußte übers Terminal ran. Einen Github Account um Feature Requests einzureichen besitze ich nicht, sonst hätte ich das bereits getan, deswegen an dieser Stelle. und vielen Dank nochmal für dieses Projekt.

Hallo zusammen. Kurze Frage: Wo finde ich denn die Einstellungen um die Restore Jobs zu planen? Unter Restore-Tests finde ich nur ob geplant, Intervall und das Level, was ich konfigurieren kann, nicht welchen Tag des Monats oä. Der Hinweis "Die zentrale Steuerung erfolgt in Planung & Policy pro Job. Diese Seite führt den fälligen Plan aus und zeigt die Ergebnisse." hilft leider auch nicht viel, da unter den Job Einstellungen selbst nichts von Restore Test zu finden ist. Bin ich blind, läuft der Task dann automatisch nach dem Backup wenn das Intervall überschritten wurde, oder ist das noch noch nicht implementiert. Danke

Hi Thorsten, I think I found a bug. I tried to edit an existing backup job, more specifically, I only changed the Type ID from “config” to “pfsense” and left everything else unchanged. As soon as I clicked save, I received the following error: Fehler: Der Job wurde gespeichert, aber der Zeitplan konnte nicht übernommen werden: Unknown job key: config_localThe job now shows “Noch kein Backup durchgeführt” in the jobs tab. On the dashboard, I can see a newly created location. There are now two locations: the old “config” location and a new “pfsense” location. I had already created a backup using the old Type ID, which is still displayed on the dashboard. The new “pfsense” location is shown with a message indicating that this job has not been run yet. Edit: In the reports section, I can also see the "old" naming "config"

Thanks! I noticed something else. I had to search for the section where you set up the “allowed restore path” for the third time now. From a UI perspective, users generally work from left to right, with the relevant settings located on the right-hand side. Placing this option in another tab is why I couldn’t find it 😅 It would be better to place it either directly on the restore settings or on the general settings page, where all the other paths are already managed. Thanks

Hi Thorsten, First of all, thanks for the plugin. I’m currently in the process of testing it, and so far it looks like I might switch my existing Borg backup scripts to your plugin. Everything is working well so far. I only have one question. During the job creation process, you can exclude folders from the selected source folder. Currently, I use Borg’s --exclude-if-present NAME option to exclude certain folders. I already have several folders containing .nobackup or .NOBACKUP files, and when I use --exclude-if-present .nobackup Borg skips those folders. For example, I use this method to exclude the "files_versions" and "files_trashbin" folders for each Nextcloud user. Would it be possible to implement this as an additional option in the source selection tab? It would be very useful, otherwise, I would have to add two folder exclusions for each user, as well as for other folders 😝 Thanks!

Does this mean it is not possible anymore to connect to the server locally via lan ip and self signed cert and I am forced to install the Unraid Connect Plugin? If so, why?

Kann gut möglich sein, dass der CPU Takt in der VM einfach falsch angezeigt wird, vom Host quasi nicht an die VM korrekt weiter gegeben wird. Kann mich erinnern, dass ich das bei nem alten Threadripper System in ner VM auch schon gesehen hab, dass nur 800MHz angezeigt wurden, trotz dass auf dem Host auch der Boost aktiv war und funktionierte. Am besten einfach folgendes auf Unraid mal parallel zur aktiven VM laufen lassen watch grep \"cpu MHz\" /proc/cpuinfo Und noch paar Sachen am Rande: core0 nutzt Unraid grundsätzlich immer für sich um Tasks im Hintergrund zu bedienen. Ist nicht wirklich empfohlen den Kern gleichzeitig auch für eine VM zu verwenden. Angenommen deine VM veranstaltet im Hintergrund irgendwelche Updates, lastet die CPU stark aus, dann kann gleich direkt dein ganzer Server betroffen sein und Unraid wird extrem lahm bis hin zu freezes. 4 Kerne können Windows heutzutage in einer VM auch schon ganz schnell an die Grenze bringen. Großartig Performance ist da nicht zu erwarten. Wird sich definitiv langsamer anfühlen als wenn du Win10 direkt auf der Kiste laufen hast. Was auch noch ne extreme Bremse ist, wenn deine vdisk der VM nicht auf ner SSD/NVME liegt, sondern auf ner alten HDD vielleicht oder noch dazu auf ner Array Platte was nochmal stark bremst.

In one of the latest Unraid versions it changed slightly how shares are configured. Currently if you wanna use a cache drive combined with the array and move the data with mover to the array you have to define 2 options. In my case I have set the appdata share to be on the cache pool: I have set the primary storage as Cache and the secondary as Array and the Mover action "Array -> Cache" so if Mover starts it always will move files to the Cache pool. With this setup I see the same info as you because the files are not protected by the redundancy of the array if the cache pool only consists of 1 drive. If you have a mirrored pool with 2 or more drives the warning will go away. The reason why I have set it up this way is to be able to spin down the array disks. As an example if you use Nextcloud or Jellyfin/Plex you will always see some activity which will prevent the array disks to spin down. In my example if you switch the Mover action at the bottom of the share settings to "Cache -> Array" the unprotected files message will go away. In case of the drive failure for the single drive cache pool I have setup to backup the whole appdata folder each night. There are different ways to do this. "appdata backup" for example is a useful plugin for this. Most people have set it up this way that the appdata share housing all the docker configs and databases, sits on a fast ssd pool, single or multi drive, depends on the setup. In my case I use 20+ dockers and the size of the appdata share is 18GB. So it's not a big waste of space. As I said, depends on your usecase, you don't have to. Nextcloud for example if only using the array will prevent disks in the array to spin down if you use it on your phone, upload pictures, sync calendar and contacts. So it's better to combine it with the cache option. In my setup all my data I upload to Nextcloud will be stored on the cache pool first and moved to the array at night. The setup for the Nextcloud share hosting all the user data looks like this: primary storage: Cache secondary: Array Mover: Cache -> Array Usually best practice is to have data you access on a daily basis on a fast cache pool. If it's a single ssd you need to backup the data to prevent data loss. If you have a mirrored cache pool with more than 2 drives you have an extra layer of redundancy, but keep in mind raid is no backup. Depending on your network speed in most cases putting data on the cache first and let the mover transfering it to the array at night is the way to go. In case you have large amounts of data coming in exceeding the size of the cache, put it directly on the array as primary storage without a second storage or the mover take action. Not sure why you did that. In general the defaults are fine. docker.img in system share configs for the dockers in appdata share Short hint how docker and all the paths work in case you don't got it already. In most cases you basically have 3 paths where data is sitting. The application itself lets say Nextcloud is inside the docker.img file in the system share. In case you loss it, it's not big of a deal. You can easily recreate that file and reinstall all your dockers. The configurations for the dockers living in the appdata share. You should backup the appdata share regularly to don't loss any configurations in case of a drive failure. For both of these shares in most cases there is no need to change the defaults. The third path most of the containers use are where the userdata is in. Media files in Plex or uploads from your phone to Nextcloud for example. These paths are also shares in Unraid and can be configured as you like. Only on cache pools, on Array only or on Cache first and moved to the Array later. Depending on the amount of data coming in or used by these shares and depending on how large your pools are, you have to configure these shares. example for my Nextcloud path mappings: As you can see all the configurations from Nextcloud are mapped to the /mnt/user/appdata/nextcloud path and the user data are in the /mnt/user/nextcloud share. Don't blindly try to replicate these bindings. They differ depending on which Nextcloud docker you're using. Just as an example. go settings >> docker and disable the docker service make sure your deafult paths matching the defaults you see in the picture above in case you have manually moved your docker.img somewhere else, move it back to /mnt/user/system/docker/ check your system and appdata share settings, for appdata see my first picture, the system share should look like the following go to the main page of unraid and start the mover by pressing "move" and wait till it's finished. As long as it's moving filles, the button will be grayed out. optional: go to the shares page and click on compute for the system and the appdata share to check where data is siiting on. After mover is done go back to the docker settings and enable the service again

Servus. Hier wird dein Problem liegen. Beim Boot der VM wird normalerweise die Karte initialisiert allerdings nur, wenn ein Monitor angeschlossen ist. Meine 1050ti funktioniert auch nur in einer Win VM, wenn ein Monitor dran klemmt. Es gibt auch HDMI Dongles, die der Karte einen Monitor vorgaukeln, wäre eine Option, wenn du keinen Monitor anklemmen willst. Das ist eins der Symptome wenn kein Display dran hängt. Die Karte wird nur als Basic Display Adapter erkannt versehen mit einer Warnung und Treiber lassen sich auch nicht installieren.

Ich bin ja nicht der Käufer, und selbst hab ich bisher immer einen Bogen um solche Angebote gemacht. Ausnahmen würde ich ja noch machen, wenn ich direkt beim Angebot sehe die Platte kommt aus nem Rechenzentrum und hat x Betriebsstunden, x TBW etc. Wenn die SMART Werte wie angegeben zurückgesetzt wurden und ich quasi 0 Möglichkeiten hab deren Gebrauch nachzuvollziehen sind es mir die paar Euro Ersparnis auch nicht wert. Kannst du in deinem Fall nachvollziehen bei welchen Modellen die hohen Werte vorhanden sind? Scheint ja so zu sein, dass es bei deinen 18TB Modellen auch nicht einheitlich ist. Kommt das nur ab einem gewissen Modelljahr vor, oder bei einer besonderen Firmware Version?

Ok. Das ist mir auch gerade neu. Die letzten Seagate Platten die ich hatte, zeigten das noch nicht so, allerdings auch schon paar Jahre her. 2-3TB Modelle waren das. Ich habe dennoch Bauchschmerzen bei "recertified" Platten. In einem Kommentar steht folgendes: Stell dir vor du kaufst nen gebrauchten PKW, bei dem einfach mal alle alten Unterlagen gelöscht und der Kilometerstand auf 0 gesetzt wurde für 20-30€ günstiger als Neuware.

Wenn mal bei "Raw_Read_Error_Rate" 3-4 oder so steht und nicht hoch geht, würde ich mir garkeine Sorgen machen, aber 37673480 bei gerademal 256h Laufzeit ist nicht ok. Je nachdem wie man die Platte testet, wird es vielleicht garnicht direkt auffallen. Formatieren und Daten drauf kopieren mag vielleicht noch funktionieren, beim Lesen der Daten wird man es dann aber sicherlich merken. "recertified" wird denke mal nen Rückläufer sein. Jetzt weißt du auch warum. Wird keinen Sinn machen nen extended Selftest laufen zu lassen, wenn die Platte intern in ihrem eigenen Log schon Lesefehler verzeichnet hat. Probier mal ohne die Platte ob der Server stabil läuft

Eine deiner Festplatten (ST18000NM000J-2TV103) hat in den Smart Werten sehr hohe Werte bei den Fehlerraten. Mit der Platte stimmt definitiv was nicht Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-- 076 064 044 - 37673480 3 Spin_Up_Time PO---- 090 090 000 - 0 4 Start_Stop_Count -O--CK 100 100 020 - 17 5 Reallocated_Sector_Ct PO--CK 100 100 010 - 0 7 Seek_Error_Rate POSR-- 079 060 045 - 80588272 9 Power_On_Hours -O--CK 100 100 000 - 256 10 Spin_Retry_Count PO--C- 100 100 097 - 0 12 Power_Cycle_Count -O--CK 100 100 020 - 16 18 Unknown_Attribute PO-R-- 100 100 050 - 0 187 Reported_Uncorrect -O--CK 100 100 000 - 0 188 Command_Timeout -O--CK 100 100 000 - 0 190 Airflow_Temperature_Cel -O---K 075 063 000 - 25 (Min/Max 14/28) 192 Power-Off_Retract_Count -O--CK 100 100 000 - 15 193 Load_Cycle_Count -O--CK 100 100 000 - 27 194 Temperature_Celsius -O---K 025 040 000 - 25 (0 14 0 0 0) 197 Current_Pending_Sector -O--C- 100 100 000 - 0 198 Offline_Uncorrectable ----C- 100 100 000 - 0 199 UDMA_CRC_Error_Count -OSRCK 200 200 000 - 0 200 Multi_Zone_Error_Rate PO---K 100 100 001 - 0 240 Head_Flying_Hours ------ 100 100 000 - 255 (232 238 0) 241 Total_LBAs_Written ------ 100 253 000 - 51453398249 242 Total_LBAs_Read ------ 100 253 000 - 219259610467

@KluthR First of all, thanks for the plugin. I'am using it for quite some time now and never had any issues with it. Yesterday I switched from the old 2.5 version to the new one during the latest Unraid update and tested a bit. So far so good, compression works fine, copy flash backup to different location and also the grouping feature and the autoupdate dockers are working. Now to my issue I have. I have a mariadb and nextcloud container grouped together, stop-backup-start works, but the available update for the mariadb container isn't applied when grouped together. Is this a known bug or not yet implemented for the grouping feature? The logs show no errors and no hints that the plugin tries to update the container like it did on the netdata container which is in no group. -- [21.02.2024 22:20:37][ℹ️][nextcloud] Method: Stop all container before continuing. [21.02.2024 22:20:37][ℹ️][nextcloud][Nextcloud] Stopping Nextcloud... done! (took 1 seconds) [21.02.2024 22:20:38][ℹ️][nextcloud][MariaDB-Official] Stopping MariaDB-Official... done! (took 2 seconds) [21.02.2024 22:20:40][ℹ️][Main] Starting backup for containers [21.02.2024 22:20:40][ℹ️][Nextcloud] Should NOT backup external volumes, sanitizing them... [21.02.2024 22:20:40][ℹ️][Nextcloud] Calculated volumes to back up: /mnt/user/appdata/nextcloud/apps, /mnt/user/appdata/nextcloud/config, /mnt/user/appdata/nextcloud/nextcloud [21.02.2024 22:20:40][ℹ️][Nextcloud] Backing up Nextcloud... [21.02.2024 22:21:37][ℹ️][Nextcloud] Backup created without issues [21.02.2024 22:21:37][ℹ️][Nextcloud] Verifying backup... [21.02.2024 22:22:20][ℹ️][MariaDB-Official] Should NOT backup external volumes, sanitizing them... [21.02.2024 22:22:20][ℹ️][MariaDB-Official] Calculated volumes to back up: /mnt/user/appdata/mariadb-official/data, /mnt/user/appdata/mariadb-official/config [21.02.2024 22:22:20][ℹ️][MariaDB-Official] Backing up MariaDB-Official... [21.02.2024 22:22:30][ℹ️][MariaDB-Official] Backup created without issues [21.02.2024 22:22:30][ℹ️][MariaDB-Official] Verifying backup... [21.02.2024 22:22:33][ℹ️][Main] Set containers to previous state [21.02.2024 22:22:33][ℹ️][MariaDB-Official] Starting MariaDB-Official... (try #1) done! [21.02.2024 22:22:35][ℹ️][Nextcloud] Starting Nextcloud... (try #1) done! [21.02.2024 22:22:38][ℹ️][netdata] Stopping netdata... done! (took 2 seconds) [21.02.2024 22:22:40][ℹ️][netdata] Should NOT backup external volumes, sanitizing them... [21.02.2024 22:22:40][ℹ️][netdata] Calculated volumes to back up: /mnt/user/appdata/netdata/lib, /mnt/user/appdata/netdata/cache, /mnt/user/appdata/netdata/config [21.02.2024 22:22:40][ℹ️][netdata] Backing up netdata... [21.02.2024 22:22:59][ℹ️][netdata] Backup created without issues [21.02.2024 22:22:59][ℹ️][netdata] Verifying backup... [21.02.2024 22:23:02][ℹ️][netdata] Installing planned update for netdata... [21.02.2024 22:23:28][ℹ️][netdata] Starting netdata... (try #1) done! --

@GatorMB Do you have a idle session to Unraids WebUI opened somewhere on your network? I have an issue the server freezing randomly if I have a websession opened from a Windows box with Firefox. Randomly every 1-2 days with root logged in to Unraid, the server will freeze without any errors catched in the logs. If I log off or shutdown the Windows pc the server won't crash.