KluthR Posted February 9 Author Share Posted February 9 1 hour ago, DanielPT said: But can i be that the "App data" plugin is been making the backuop with a user and when duplicacy is restoring its trying to set the owner that Appdata backup is using? Dont know how duplicacy is working here. Appdata backup used to use root:root as user/group. The newest beta sets nobody:users as user/group. Maybe you could test the newest beta OR you set one test backup to nobody:users and test a backup/restore cycle. Quote Link to comment
DanielPT Posted February 9 Share Posted February 9 1 hour ago, KluthR said: Dont know how duplicacy is working here. Appdata backup used to use root:root as user/group. The newest beta sets nobody:users as user/group. Maybe you could test the newest beta OR you set one test backup to nobody:users and test a backup/restore cycle. Hi sir Meny thanks! How can i test that? I can see that duplicacy container is set to USR_ID 99 and GRP_ID 100 if that say you something. I made a post here https://forums.unraid.net/topic/152827-restoring-with-duplicacy-fails-becurse-of-permissions/ Quote Link to comment
casperse Posted February 9 Share Posted February 9 I seem to have experienced a corrupt docker.img vdsik and I think this plugin used/or do backup the whole vdisk file? I just cant find it? is it compressed between the many App backups? Quote Link to comment
KluthR Posted February 9 Author Share Posted February 9 59 minutes ago, casperse said: I think this plugin used/or do backup the whole vdisk file? No it does not. stop docker, remove the vdisk file and start docker. Your vdisk get recreated. You then have to use Previous apps or create every container again using your template. All settings and mappings should be there. https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file Quote Link to comment
casperse Posted February 9 Share Posted February 9 1 hour ago, KluthR said: No it does not. stop docker, remove the vdisk file and start docker. Your vdisk get recreated. You then have to use Previous apps or create every container again using your template. All settings and mappings should be there. https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file I know this, but recreating my custom docker lan and then selecting only the ones I used before (Seems I have many old dockers in my previous section under Apps) is allot of work (+50-60 dockers). Also it seems that some of my dockers have lost their repository so I cant reinstall them 😞 Maybe the new ZFS with snapshot could be used in the future for the vdisk file? (I cant remember if it was only the Appdata? Or a script to copy the vdisk every week? Sorry I was so sure that this plugin had the posibility to take a backup of the vdisk, maybbe it was another one? Quote Link to comment
KluthR Posted February 9 Author Share Posted February 9 I personally dont use a vdisk. I use a usual path as docker data. But thats a personal feeling. however, the docker vdisk contents are never being backed up, because this is not needed normally. I could add support for backing it up, but that needs the service to be stopped at some point. the restore process will be expanded by full automatic container creation in a future release. Quote Link to comment
KluthR Posted February 9 Author Share Posted February 9 57 minutes ago, casperse said: Sorry I was so sure that this plugin had the posibility to take a backup of the vdisk, maybbe it was another one? CA Backup 2 / 2.5. The predecessor of this plugin. Quote Link to comment
JeanLuc Posted February 9 Share Posted February 9 I'm going through fine tuning my each container backup and something came to me. My current schedule is having appdata.backup run once a week. When doing a backup of a containers directory, do you omit that containers backup dir? For example, Radarr has a default application backup weekly. It seems a little double redundant to be backing up the containers own backup. What is normal practice for this process? Quote Link to comment
DanielPT Posted February 9 Share Posted February 9 8 hours ago, KluthR said: Dont know how duplicacy is working here. Appdata backup used to use root:root as user/group. The newest beta sets nobody:users as user/group. Maybe you could test the newest beta OR you set one test backup to nobody:users and test a backup/restore cycle. HI I cant change a backup owner? Is that becurse the folder "Backup_external" is owned by root? Quote Link to comment
DanielPT Posted February 9 Share Posted February 9 @KluthR AH okay i just tryed to make a restore of a file in my picture folder that has "owner" nobody and that worked! When will the plugin be done and I can change it to "nobody" ? Quote Link to comment
Revan335 Posted February 10 Share Posted February 10 I have with the new Version from many Docker Containers Messages like this: rsync-server does not have any volume to back up! Skipping. Please consider ignoring this container. What's means Volumes? Every? Docker Container have Volumes like appdata/Name or /mmt/user/xyz Quote Link to comment
Kilrah Posted February 10 Share Posted February 10 (edited) 8 hours ago, Revan335 said: Every? Docker Container have Volumes like appdata/Name or /mmt/user/xyz Did you check? Not all do, and I only get that for those that don't. Warning's a bit annoying though, it's not a problem that there isn't anything to back up and ignoring means unnecessary manual intervention times 20 for me, plus more any time something new that doesn't is installed. Edited February 10 by Kilrah Quote Link to comment
KluthR Posted February 10 Author Share Posted February 10 22 hours ago, JeanLuc said: When doing a backup of a containers directory, do you omit that containers backup dir? No. How should the plugin be aware of those directories? 21 hours ago, DanielPT said: When will the plugin be done and I can change it to "nobody" ? The latest beta contains it. But its hardcoded to "nobody:users". The latest beta should go prod within the coming week 8 hours ago, Kilrah said: Not all do, and I only get that for those that don't Yes. And knowing that this warning is being raised AFTER synitizing external volumes, its just here to inform you "Hey, you want a backup for this one..." (because its not being ignored) "... but the final detected volumes are empty". It could be something wrong. So, if you EXPECT a container to be not being backed up, consider setting "Skip?" to yes or (if you want the container to be included in start/stops): 8 hours ago, Kilrah said: Warning's a bit annoying After reading my suggestion, anything else I missed which could be made better? 1 Quote Link to comment
Revan335 Posted February 10 Share Posted February 10 A Example for rsync I don't know what wrong that's its triggered the Warning🤔 Quote Link to comment
Kilrah Posted February 10 Share Posted February 10 (edited) 25 minutes ago, Revan335 said: I don't know what wrong that's its triggered the Warning There is no internal volume, and external volumes are not backed up, so there's nothing to back up for that container. 52 minutes ago, KluthR said: After reading my suggestion, anything else I missed which could be made better? Not really other than not having the warning / having a way to ignore it, but i as said it's not a big deal really. It's just that manually going to turn "skip backup" on for 20 containers is annoying when that's not actually a problem. Edited February 10 by Kilrah 1 Quote Link to comment
mortenmoulder Posted February 10 Share Posted February 10 Is it possible to tweak the compression level of zstd? I don't care if my backup takes 5 minutes or 30 minutes, if that saves me a couple of gigabytes per backup. Quote Link to comment
Revan335 Posted February 10 Share Posted February 10 28 minutes ago, Kilrah said: There is no internal volume, and external volumes are not backed up, so there's nothing to back up for that container. OK, thanks for the clarify. A Option to ignore this Warning what's great, than I will be Backup all Docker Container or his Config when his no self Data. Quote Link to comment
KluthR Posted February 10 Author Share Posted February 10 1 hour ago, mortenmoulder said: Is it possible to tweak the compression level of zstd? Not yet. I just added a tweak for the cores to use. Include a compression option should no big deal either. I‘ll see. Quote Link to comment
House Of Cards Posted February 11 Share Posted February 11 I noticed that the backup contains orphaned .XML files from old dockers I've since deleted. Any idea where those are located and being pulled from so I can delete them? If they are in the .IMG file itself, is there a way to clean that? Quote Link to comment
KluthR Posted February 11 Author Share Posted February 11 (edited) Every ever created container also lets Unraid create an associated xml. It is being kept also if you delete the container (for later recreation). These are located at /boot/config/plugins/dockerMan/templates-user. The .img (I assume you are talking about docker vDisk) has absolutely nothing to do with it. Edited February 11 by KluthR 1 Quote Link to comment
Kilrah Posted February 11 Share Posted February 11 2 hours ago, House Of Cards said: Any idea where those are located and being pulled from so I can delete them? Go to Apps -> Previous Apps, select / delete those you don't intend to use again. 1 Quote Link to comment
KuroSetsuna29 Posted February 12 Share Posted February 12 I started getting a new error recently: [11.02.2024 06:01:04][ℹ️][tdarr] No stopping needed for tdarr: Not started! [11.02.2024 06:01:04][❌][tdarr] '/tmp/tdarr' does NOT exist! Please check your mappings! Skipping it for now. [11.02.2024 06:01:07][ℹ️][tdarr] Should NOT backup external volumes, sanitizing them... [11.02.2024 06:01:07][ℹ️][tdarr] Calculated volumes to back up: /mnt/user/appdata/tdarr/logs, /mnt/user/appdata/tdarr/server, /mnt/user/appdata/tdarr/configs [11.02.2024 06:01:07][ℹ️][tdarr] Backing up tdarr... [11.02.2024 06:02:21][ℹ️][tdarr] Backup created without issues [11.02.2024 06:02:21][⚠️][tdarr] Skipping verification for this container because its not wanted! [11.02.2024 06:02:21][ℹ️][tdarr] Starting tdarr is being ignored, because it was not started before (or should not be started). And my mappings for tdarr are: /app/server <-> /mnt/user/appdata/tdarr/server /app/configs <-> /mnt/user/appdata/tdarr/configs /app/logs <-> /mnt/user/appdata/tdarr/logs /mnt/media <-> /mnt/user/media /temp <-> /tmp/tdarr Basically, the container is suppose to create the `/tmp/tdarr` folder when it starts, but I dont have the tdarr starting right now, so the `/tmp/tdarr` does not exist. Non-existant folders probably shouldn't result in an error, and was fine until recently. Either it should be a warning or check non-existant folders after sanitizing external volumes because it wouldn't have included it in the back up anyways. Right now my work around is to change my temp volume map, or create the folder during start up. Quote Link to comment
KluthR Posted February 12 Author Share Posted February 12 47 minutes ago, KuroSetsuna29 said: Non-existant folders probably shouldn't result in an error, and was fine until recently. Have to check but I believe no changes were made at those parts. It should minimum raise a warning. Quote Link to comment
Viking Posted February 12 Share Posted February 12 Hi everyone, I noticed a small problem during this week's backup. Recently, I changed all my docker paths from "mnt/user/appdata" to "mnt/cache/appdata". Since then, the plugin read all these paths as "external volumes" and no longer backup by default. Is this problem fixable? Should I wait for an upgrade? Or should I enable external volume backups and manage exceptions? On a by Docker basis ? Thanks in advance for your help! Quote Link to comment
Kilrah Posted February 12 Share Posted February 12 25 minutes ago, Viking said: Since then, the plugin read all these paths as "external volumes" and no longer backup by default. Path needs to be in appdata sources 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.