[Plugin] Appdata.Backup

[KluthR]

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.

[DanielPT]

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/

[casperse]

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?

[KluthR]

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

[casperse]

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?

[KluthR]

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.

[KluthR]

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.

[JeanLuc]

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?

[DanielPT]

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?

[DanielPT]

@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" ?

[Revan335]

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

[Kilrah]

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

[KluthR]

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?

[Revan335]

A Example for rsync

I don't know what wrong that's its triggered the Warning🤔

[Kilrah]

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

[mortenmoulder]

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.

[Revan335]

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.

[KluthR]

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.

[House Of Cards]

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?

[KluthR]

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

[Kilrah]

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.

[KuroSetsuna29]

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.

[KluthR]

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.

[Viking]

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!

[Kilrah]

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