37 minutes ago, KluthR said:

transmission never got backed up

I received this for all my dockers. 

 

I will have to check if any were backed up. 

 

In any case, what is the solution? 

1 hour ago, KluthR said:

Please add the mentioned volume path in the exclusion list directly inside its container config.

It has been added there as well

 

Edited February 24, 20242 yr by paperblankets

On 2/13/2024 at 5:23 PM, KluthR said:

I have at least to play with this. Unraids dockerMan is giving only the name/path of the used volume, not any info about the type.

Some update here:

 

the plugin can easily handle named volumes in future. The next beta has support for it.

1 hour ago, trurl said:

In any case, what is the solution?

As said: Read the "Allowed appdata sources" help block to understand how bind volumes are beind determined as internal/external.

You could also submit a debug log within the log tab to let me check your situation.

 

1 hour ago, paperblankets said:

It has been added there as well

🤦‍♂️Yea, I just checked and saw, that the exclusions list is not being checked within the function that determines the volumes. I note that and it will be fixed within a next release.

6 hours ago, trurl said:

I have the plugin configured to look for the appdata at /mnt/user/appdata.

It should include all appdata sources, both /mnt/user/appdata and any /mnt/[pool]/appdata if applicable, because when it looks at the path in the template it checks if that's within the sources, if it is then it's "internal". If you only specify /mnt/user then if you have a template configured to access /mnt/pool directly it'll be considered external.

Edited February 24, 20242 yr by Kilrah

Nothing explained so far is helping me to understand what I need to change. Do I need to specify /mnt/fast/appdata for the Appdata source instead of /mnt/user/appdata?

3 hours ago, KluthR said:

Read the "Allowed appdata sources" help block

I did

35 minutes ago, trurl said:

specify /mnt/fast/appdata for the Appdata source instead of /mnt/user/appdata?

That seems to have worked. Hadn't been backing up anything in appdata for months, just copies of my templates, many that I don't even use anymore. I'll clean those up.

8 hours ago, KluthR said:

Did you selected the folder that holds the ab_ folders?

Yes I am.  Just re-ran a manual backup and get the same issues.

1 hour ago, trurl said:

Nothing explained so far is helping me to understand what I need to change. Do I need to specify /mnt/fast/appdata for the Appdata source instead of /mnt/user/appdata?

Instead or additional. It depends where the primary mapping targets are located at. Otherwise all detected mappings are considered external and only being backed up if „backup external volumes“ is enabled.

17 minutes ago, BigMal said:

Yes I am.  Just re-ran a manual backup and get the same issues.

And those ab_ folders have not a suffix „failed“?

Is there any guide somewhere how to restore libvirt.img file from the vm meta?

If I do a restore of VM meta, I only get the content of /etc/libvirt restored, but what would be the way to transform this into libvirt.img?

Libvirt is not being backed up, only some contents of its mounted filesystem (the vm definition). 

6 minutes ago, KluthR said:

Libvirt is not being backed up, only some contents of its mounted filesystem (the vm definition). 

I see that, but how can I restore the VMs from this content? I presume, ultimately we need to recreate libvirt.img from these files.

The libvirt.img is mounted as /etc/libvirt/…

 

the plugin backs up the VM metadata, nothing more. And it restores it there. Anything apart from that (vdisk) needs to be restored/backed up somehow else.

Sure, I don't expect the vdisks to be restored. I have those. So if the content of /etc/libvirt/ gets restored by the plugin to /etc/libvirt/, then the restored files will be written directly into the mounted libvirt.img, so no need to take care of rebuilding this?

3 hours ago, KluthR said:

And those ab_ folders have not a suffix „failed“?

The one I am attemping to restore does not have "-failed" at the end.

 

9 hours ago, olympia said:

so no need to take care of rebuilding this?

No. If it was rebuilt/created by unraid, you should be ok after restoring.

 

7 hours ago, BigMal said:

The one I am attemping to restore does not have "-failed" at the end.

Please post a ls -a from the path you are having in the restore path field.

 

maybe you could add a screenshot from the restore page with the error message in place?

21 hours ago, KluthR said:

@trurl Now I see what happened. I believe transmission never got backed up. I recently raised the loglevel for your posted warning to be warn instead just info. So maybe the plugin shows now an issue when it was silent before:

 

https://github.com/Commifreak/unraid-appdata.backup/commit/1d970a9ce0292b53b6c037ba18cad26b1e7ebb35

Damn I think this is what happened to me. I've checked old backups and the ones that threw an error this week never had a tar.gz in the backup location. I just never noticed because I never got a notification (which I did after you made the change).

OK, I know there are no dumb questions.  Just dumb users.  I qualify as one.  🤪

 

Where do I find the log file for this plugin?  I only ever see "This log is not existing or empty" in the Status / Log tab.

On 2/24/2024 at 4:47 PM, KluthR said:

Please add some recommended Plex excludes (see 1st post)

 

Thanks! I'll try that and see how it goes tonight. The weird part is when I tried to do a manual backup that worked without errors. 

9 hours ago, KluthR said:

Please post a ls -a from the path you are having in the restore path field.

 

maybe you could add a screenshot from the restore page with the error message in place?

This is complete user error on my part. For those who may have similar issues, do the following:

 

As instructions clearly state, select the folder with the "ab_" folders in them. Not the actual "ab_" folder as I was doing (that is what caused the initial error.  I selected those folders because when I selected the backup folder and clicked "Next", I did not pay close enough attention to the fact that "Step 2" appeared below.  Then, I just followed the instructions.

 

Again, completely my fault. But, aopreciate the responsiveness and willingness to assist.

With the current version in the UI I get the "WARN: Multi mapping detected!" for almost all my containers, most of them being actually unique.

 

 

Also I got an error for a missing folder. That is an external volume, and external volumes are not being backed up for this container, so that should at most be a warning, not an error. 

 

Hmm. Need to check tomorrow. As well as the second issue you posted.

1 hour ago, Kilrah said:

With the current version in the UI I get the "WARN: Multi mapping detected!" for almost all my containers, most of them being actually unique.

 Seeing the same in all of my containers except 3.  Those have no appdata configured.