Revan335

Ich kann 16 GB raus lesen. Hast du auch noch Hersteller/Modell? Ist das der selbe Hersteller/Modell/Größe wie der erste und die anderen? Sind das USB 2 oder 3.x?

Kannst du mehr Details nennen? Hersteller/Modell/Größe?

Was habt ihr den für Sticks bzw. was macht ihr damit? Ich hatte ebenfalls noch keine Probleme mit meinen. Es gab/gibt ne gefälschte Charge? von Sandisk Sticks vor denen von Unraid auch gewarnt wurde/wird. Falls ihr einen davon erwischt habt, kann es durch aus sein, das die deshalb blacklisted sind.

Das stimmt, da kommt meine ich ne Meldung. Hab ich im aktuellen Fall nicht. Dann muss ich sie übersehen haben, gesehen hab ich keine. Hab über den Klonen Button eine Dublette einer der vorhandenen Aufgaben erzeugt. Das scheint luckyBackup laut dem Eintrag im Cron Job Log nicht gefallen zu haben, wie ich jetzt gesehen/entdeckt hab. Also Source/Destination ist nicht identisch. Da wird gewiss ne Meldung angezeigt würde ich mir denken.

Aber interessant das dann direkt das ganze Profil/alle Jobs nicht ausgeführt wird ohne Fehlermeldung. OK, im Cron Job Log stehtwas dazu drin. Aber in luckyBackup selbst oder den einzelnen Job Logs wäre sowas deutlich hilfreicher. Vielleicht auch nur ein Gedankenfehler von mir wie ich das luckyBackup Profil und dessen Jobs verstehe. Vielen Dank!

Die Cron Log Datei kannte ich noch gar nicht. Habe den Fehler vermutlich gefunden. Scheinbar mag luckyBackup keine Jobs mit gleichen Quell/Ziel Pfaden. Teste den Weg auch noch auf dem anderen Server. Gibt es vielleicht noch ne andere Möglichkeit eine Aufgabe/Task nochmal ausführen zu lassen ohne ein neues luckyBackup Profil erstellen zu müssen? Sonst muss ich mal die Startzeit des Profils anpassen und schauen ob sich dann die Some Files Vanished Meldung erledigt. Das deutet für mich auf ein Timing Problem hin, das luckyBackup was sichern möchte was nicht mehr da ist. Bspw. weil es sich nicht mehr im Cache sondern auf dem Array befindet oder in der Zwischenzeit verändert wurde. Danke für den Hinweis/Wink! @alturismo

Weitere Versuche: - Aktualisierung erzwingen, damit der Docker Container neu erstellt wird - Server Reboot - neuen Scheduler erstellt inkl. @reboot und in Crontab eingetragen (beides ohne Erfolg) Der Ordner Schedules wird auch unter Appdata aktualisiert. Schreibzugriff ist also vorhanden. Im Log Ordner ändert sich leider nichts @ich777 Du hattest im Englischen Thread von User Scripts gesprochen mit denen du deine Jobs machst. Wie machst du das, dann teste ich das auch noch?

Hat leider nicht geholfen.

Dort ist noch alles unverändert. Uhrzeit, Konsolen Modus. Hab Uhrzeit und Konsolenmodus (aus/an) mal geändert und neu in den Cron eintragen lassen. Mal schauen ob es hilft.

We need a new Template for this Functionality?

So, I know I'd too. But the Console Mode are not changed but he's not running. I disable/enable the console mode, and tryed again this night.

What was the changes on the Updates from Krusader and luckyBackup? And working the luckyBackup Jobs by yours? By me, no more. 😥

This on is the right Entry:

This one. I must show I which but I think the ordering is on the Main Thread and the Release Documentation that are also linked on that thread.

When your Folders are Docker Directory mnt/user/docker, the Appdata mnt/user/appdata and you used exclusive Shares than its the new Default. When you don't used exclusive Shares or mnt/cache and so the Docker Files are only on the Cache Drive you have a big increase issue of Speed, Power Cost, ... and never ending Drives. When you used the linked Documentations/Guides than he was under the Docker Directory mnt/user/docker. The order of the steps and starting the individual components/services is important so that they also end up/display in the Docker Directory. But when you have the Legacy Snapshots under system is something wrong. Maybe the Docker Compose is the issue. I don't using this. Why you are using not the inbuild Docker Functionality?

Exclusive Shares: https://docs.unraid.net/de/unraid-os/release-notes/6.12.0/#exclusive-shares A New Feature for/from 6.12.

The old Default but not changed at the Moment in New Configs is system/docker. I hope this come with 6.13. The new Default from Documentation/Release Notes from 6.12 is /docker. For example /mnt/user/system/docker or /mnt/cache/system/docker and /mnt/user/docker or /mnt/cache/docker user should have exclusive Shares enabled for prevent Performance and other Issues. All Requirements ... for this, Migration ... is explained in the Documentation and the linked Threads from me. I recommended to change/migrated why you are on the Start and not many Docker Containers at the Moment. The User Data from the Docker Container are on appdata. The Docker Directory Folder/Image only have the Docker Images and no User Data. Only Custom Config like Autostart, Delay you are created new after removed the old Folder or changed/created to the new Location. With the overview in ZFS Master Plugin you are seen that creation correctly. You see the Docker Folder and the Legacy .... Snapshots under this and not under the actually from your Screenshot. After the Migration completed and worked, you can excluded from showing and have a clean List. You can converted the Folders/Shares on the ZFS Device to Datasets when he was not created automatically. This was explained to in the linked Thread. Don't touch the Docker Directory/Folder in this Steps. He not neaded a convertation to Dataset and managed by the ZFS Docker Service. As far as I know. If you have any further questions, just ask, and we are helped.

This come when the Docker Directory are not correct created/with the new Default. The Path ... changed with 6.12/ZFS. By correct/new Default you can see this under the Docker Path Folder and not under the system folder directly. You can find a How Two here: https://forums.unraid.net/topic/141919-umstieg-oder-migration-auf-zfs And a sameles Problem: https://forums.unraid.net/topic/141435-zfs-datasetssnapshots-löschen/?do=findComment&comment=1279149 But true you can exclude from showing. I have excluded after Migration to the new Default.

Ich hatte gesehen das es scheinbar ein Update des Docker Containers gab sowie auch von Krusader. Funktionieren bei euch noch die Jobs? Seit dem 14. bei mir nicht mehr auf beiden Servern. Es existieren auch keine Logs und reboot des Containers wurde auch schon mehrfach gemacht um den GUI "Bug" auszuschließen. Manuell geht es noch und erzeugt dann auch die Logs für den Job. Gibt es noch Logs von luckyBackup die ggf. mehr verraten können?

Schade, das es scheinbar bei include only nicht zum gewünschten Ergebnis kommt.

Hier einmal eine Grafik, die das Konstrukt hoffentlich besser verständlich macht. Dadurch wird verhindert, das bspw. das Backup System was an den Main Daten ändern kann, da der Zugriff nur "ro" erfolgt. Trotz "ro" bei /mnt/user am Backup Pfad/luckyBackup, funktioniert der "rw" Mount von /mnt/user/Test_LB und der Pfad ist somit beschreibbar. Es sieht derzeit gut aus, luckyBackup meldet keine Fehler mehr und in den Logs kann ich auch nicht mehr die Meldungen bzgl. cannot delete non-empty directory: .luckybackup-snaphots und seine Unterordner finden. Das Aufteilen und entfernen von Include only scheint also der entscheidende Knackpunkt zu sein. Vielen Dank an alle für die Unterstützung! Viele Liebe Grüße Revan335

Nein, war noch ein Gedankenfehler. Hab es korrigiert. Ist nun ohne include. Genau. Werde versuchen es anhand einer Grafik verständlicher darzustellen. Danke schon mal an alle für die Mühen und Wirren meines Geistes/Kopf/Hirns! Viele Liebe Grüße

Schaue heute nochmal rein. Bin gestern zu nicht mehr viel gekommen.

Diese aus einem oberen Post: Da wird in den Unraid Dokumentation zum Release/New Default Pfad erklärt, wie man besten den neuen Docker Share anlegt. Bei Fragen einfach fragen.

Hier mal das Log vom ersten Test Lauf: =====================================<br><font color=magenta>Ausführung der Aufgabe : <b>Raster - Clients Backup DUPLICATE Test</b>, startet</font><br>Quelle : <b><font color=blue>/mnt/user/Test/</font></b><br>Ziel : <b><font color=blue>/mnt/user/Test_LB/</font></b> receiving file list ... 96 files to consider ./ Test/ Test/Ubuntu_LXDE.txt 0 0% 0.00kB/s 0:00:00 72 100% 70.31kB/s 0:00:00 (xfr#1, to-chk=90/96) Test/nextcloud.log 0 0% 0.00kB/s 0:00:00 3.53M 100% 102.03MB/s 0:00:00 (xfr#2, to-chk=89/96) 0 files... deleting .luckybackup-snaphots/ Number of files: 96 (reg: 2, dir: 94) Number of created files: 3 (reg: 2, dir: 1) Number of deleted files: 1 (dir: 1) Number of regular files transferred: 2 Total file size: 3.53M bytes Total transferred file size: 3.53M bytes Literal data: 3.53M bytes Matched data: 0 bytes File list size: 2.18K File list generation time: 1.125 seconds File list transfer time: 0.000 seconds Total bytes sent: 96 Total bytes received: 3.53M sent 96 bytes received 3.53M bytes 2.36M bytes/sec total size is 3.53M speedup is 1.00 <font color=cyan>&nbsp;&nbsp;&nbsp;&nbsp;-----| Sichere Profile, Logdateien und Schnappschuss-Daten -> Ok |-----</font><br> <font color=magenta>Ausführung der Aufgabe : <b>Raster - Clients Backup DUPLICATE Test</b>, beendet</font> =====================================<br> Hier vom zweiten: =====================================<br><font color=magenta>Ausführung der Aufgabe : <b>Raster - Clients Backup DUPLICATE Test</b>, startet</font><br>Quelle : <b><font color=blue>/mnt/user/Test/</font></b><br>Ziel : <b><font color=blue>/mnt/user/Test_LB/</font></b> receiving file list ... 96 files to consider ./ 0 files... cannot delete non-empty directory: .luckybackup-snaphots/default.profile/snaps cannot delete non-empty directory: .luckybackup-snaphots/default.profile/snaps cannot delete non-empty directory: .luckybackup-snaphots/default.profile/profiles cannot delete non-empty directory: .luckybackup-snaphots/default.profile/profiles cannot delete non-empty directory: .luckybackup-snaphots/default.profile/logs cannot delete non-empty directory: .luckybackup-snaphots/default.profile/logs cannot delete non-empty directory: .luckybackup-snaphots/default.profile cannot delete non-empty directory: .luckybackup-snaphots/default.profile cannot delete non-empty directory: .luckybackup-snaphots Number of files: 96 (reg: 2, dir: 94) Number of created files: 0 Number of deleted files: 0 Number of regular files transferred: 0 Total file size: 3.53M bytes Total transferred file size: 0 bytes Literal data: 0 bytes Matched data: 0 bytes File list size: 2.18K File list generation time: 1.148 seconds File list transfer time: 0.000 seconds Total bytes sent: 55 Total bytes received: 2.20K sent 55 bytes received 2.20K bytes 900.40 bytes/sec total size is 3.53M speedup is 1,568.48 <font color=cyan>&nbsp;&nbsp;&nbsp;&nbsp;-----| Sichere Profile, Logdateien und Schnappschuss-Daten -> Ok |-----</font><br> <font color=magenta>Ausführung der Aufgabe : <b>Raster - Clients Backup DUPLICATE Test</b>, beendet</font> =====================================<br> Docker Container: docker run -d --name='luckyBackup' --net='bridge' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Lucy" -e HOST_CONTAINERNAME="luckyBackup" -e 'ROOT'='false' -e 'TURBOVNC_PARAMS'='' -e 'DATA_PERM'='770' -e 'UMASK'='0000' -e 'UID'='99' -e 'GID'='100' -e 'CUSTOM_RES_W'='1024' -e 'CUSTOM_RES_H'='768' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:8080]/vnc.html?autoconnect=true' -l net.unraid.docker.icon='https://raw.githubusercontent.com/ich777/docker-templates/master/ich777/images/luckybackup.png' -p '8081:8080/tcp' -v '/mnt/cache/appdata/luckybackup':'/luckybackup':'rw' -v '/mnt/user':'/mnt/user':'ro' -v '/mnt/user/Test_LB/':'/mnt/user/Test_LB/':'rw' --restart=unless-stopped 'ich777/luckybackup' Die Pfade für die anderen Jobs hab ich mal raus genommen. Hab den Ziel Pfad auf dem Backup Server auch mal auf Test_LB geändert damit es besser unterscheidbar ist. Die Quelle (Der andere Unraid Server) wird wie gesagt per SSH angesprochen und holt sich darüber die Daten. Hier neue Screenshots: Sowie vom Zielpfad: Vielen Dank schon mal für die bisherigen und künftigen Mühen! Viele Liebe Grüße