Everything posted by KluthR
-
[Plugin] Appdata.Backup
I would say „cache“ volumes never seems worth a backup.
-
[Plugin] Appdata.Backup
Your sources setting is wrong. Did you understood how it works? Did you read the help block? Your appdata layout is also custom, you dont use a "appdata" share with holds the regular appdata. For your setup to work, set the allowed appdata sources to /mnt/user/ and set Plex container excludes to "/mnt/user/data_store". The sources field is not be meant to hold every appdata container path. That should do it. You also maybe want to create a /mnt/user/appdata and store Plex's and tautullis appdata in there. Then you can change the sources path to "mnt/user/appdata" and clear the excludes fields (as external volumes get ignored by default). Let me know if this helps.
-
[Plugin] Appdata.Backup
The log gets cleared after reboot. you can check the syslog after reset, the syslog is stored on the flash.
-
[Plugin] Appdata.Backup
Hmm. The container was stopped but a internal file from postgre shrank during backup. Ill need to release an update for the plugin, this includes some methods to view processes that access the files in question.
-
[Plugin] Appdata.Backup
the backup gets created by unraid itself. I just call the method and save the result bzfirmware is fixed part of the unraid system and needs to be there.
-
[Plugin] Appdata.Backup
There is no default backup location. How should the plugin know it?
-
[Plugin] Appdata.Backup
I discarded the idea of the "dropdown". I built support for zfs detection by checking all volumes in question against their used fs type. If all are zfs, the plugin forces the zfs method. If at least one is non-zfs, the plugin uses the confugured method. The detection needs all volumes to be set to the zfs pool. That means, that the default paths (/mnt/user/appdata) are not working, because they are overlays and could target in different file systems (as I understood). So the share needs to be set to an exclusive zfs pool device for now ("Exclusive access: Yes" or let the docker volume point to a diskX path). Thoughts? Maybe I also misunderstood some things - I dont use the Array feature in any way, since Unraid supports Pool-devices. I also await the Array-less feature of Unraid to get rid of my dummy Array device
-
[Plugin] Appdata.Backup
Yea, that makes sense The same way I do. I also use the exact same method to start the containers.
-
[Plugin] Appdata.Backup
Some thoughts for the ZFS capable version In order to do things for ZFS capable volumes a bit smarter, the script needs to know if appdata is lying on a ZFS file system. I would offer a multi selectable dropdown with all unraid shares which the user can (de-)select. This idea brought me to the idea to generally replace the "appdata sources" textfield with a select field with fixes values (coming from the share settings). Would there be any reason to not use those pre-defined share paths? With this I could simply ask Unraid which FS type is used there. If ZFS, the plugin will use snapshots to create backups. If not, the traditional way is being used. Any thoughts? A few more words to my snapshot idea: The plugin would stop all containers (in order), create the snapshot, start all containers (in reverse order) and then starting the backup from the snapshot path and finally delete the snapshot.
-
[Plugin] Appdata.Backup
The error says it all „No such container“ I dont know why docker thinks its not there. I would need to vuilt in more debug infos here. But for now: please do a „docker ps -a“ when this happens.
-
[Plugin] Appdata.Backup
Take a look at /tmp/appdata.backup/
-
[Plugin] Appdata.Backup
No idea. Share a debug log please.
-
[Plugin] Appdata.Backup
I dont know yet. but - correct me if iam wrong - rsync can also continue copy on partial transferred files as well in case of am error..?
-
[Plugin] Appdata.Backup
Error seems clear: check if the destination is writeable.
-
[Plugin] Appdata.Backup
I call Unraids backup method and save the original archive then. Its Unraids way of making the flash backup.
-
[Plugin] Appdata.Backup
There is a /tmp/appdata.backup/running file which gets removed when the script does not run anymore.
-
[Plugin] Appdata.Backup
I would say: yes. Open the container advanced settings. I believe there is a option to skip just the backup
-
[Plugin] Appdata.Backup
Hmm. Process is dead but the system still lists it (not in the screenshot). Delete the „running“ file for now.
-
[Plugin] Appdata.Backup
Please check /tmp/appdata.backup/running. This file should contain a number. Run „ps aux | grep *number*“.
-
[Plugin] Appdata.Backup
Interesting. Please open a terminal and enter „ps aux | grep backup“. I cant imagine what should run this long after the „Done“ message…
-
[Plugin] Appdata.Backup
Not possible
-
[Plugin] Appdata.Backup
The one which is set as destination: /mnt/cloud1/appdata however: you are sure that the filesystem is ok? The error message is very clear. What does unraid show in its log screen? please try without compression (or use single core option, not milticore).
-
[Plugin] Appdata.Backup
That looks weird. Which file system is used on destination side?
-
[Plugin] Appdata.Backup
No No, not yet
-
[Plugin] Appdata.Backup
Its important to use the path which is used for your containers main appdata. Then decide if external paths should be included.