Yours is a harder one: the mentioned container changed its ImageID during backup. AutoUpdate enabled? The error code inside „Error stopping container“ comes directly from docker.

 

This issue should be retested with the new update.

I'll try to keep this as brief as possible, while also providing enough detail.

OS: 6.11.5

Plex Container: linuxserver/plex

Involved plugins: CA Backup / Restore Appdata (v2, 2022.12.13) and Appdata Backup/Restore v2.5 (2023.01.28)

 

I have had my appdata backup run on Mondays at 4am for years, even with the recently deprecated plugin. It hadn't been giving me issues until recently and I had read that v2.5 was giving people errors so I stuck with the v2 until last week, but my issue still occurred with v2.5. The issue seems to only be affecting the Plex container, as all other containers backup properly and restart without issue. This obviously makes me think it's an issue with the container, but I've tried to completely re-install it and the same thing keeps happening.

 

The issue is that after the appdata backup, Plex does not restart, and whenever I try to start it I get greeted with "Error: Server Error" with no other information. I cannot start the container, delete the container, I can hardly do anything to it. The one thing I was able to do one time was rename it (I changed it from plex to plex2). I have tried turning the Docker service off and on, but I was unable to unmount my unassigned disk (appdata), so something was stuck. I still could not update, delete, anything. My solve was to set the container to not autostart, restart the server, and then all works as expected when I start it up manually.

 

Where it gets weirder is that while the container is quite obviously not running, htop is still showing Plex Transcoder as working for HOURS, with it still using the CPU.

 

My question is, what can I do to try to pull logs if it happens again this Monday morning, or do you have any thoughts on how to solve this?

Let me know if you need any more info or diagnostics, thanks!

Thats a harder one as well. There were some reports about „Server error“ when the related docker container process seem to work but the container is marked down.

 

You should try to restart docker (or the whole system). You could also try to kill the found plex process and start the container.

 

those are states produced from something else, the backup script just tells the system „hey, stop/start xxx“ via the same methods the docker overview page does. Obe additional thing is the AutoUpdate feature.

 

maybe the new update brings better behavior. If not, Iam more than thrilled to do detailed analysis

Edited March 27, 20233 yr by KluthR

Thanks for the response. I've just changed it to wait a bit longer to kill containers and did a fresh install of your plugin. I'll see how it runs tonight and check the logs of the plugin (forgot those were a thing).

 

Thanks,

22 hours ago, KluthR said:

Same here: you dont stop all containers and wanted valid backups. Thats not possible.

 

turn off verification or allow all containers to stop.

Ok ill try that, thank you. 

I flipped some bits and bytes and I think Iam now ready to let you participate: The public beta is here! Ehm, not here, but there:

 

 

ANY beta discussion should be posted there. If Unraid and this plugin becomes stable, I close this topic.

 

Please share your thoughts (not here but there )

On 3/26/2023 at 11:45 PM, KluthR said:

Yours is a harder one: the mentioned container changed its ImageID during backup. AutoUpdate enabled? The error code inside „Error stopping container“ comes directly from docker.

 

This issue should be retested with the new update.

Thanks, that was the key. Ended up double checking my schedules and found I had auto-update scheduled at the same hour as Appdata backup. After fixing schedule conflict, no further errors.

Is Autoupdate not done within the plugin? I did not know that one can schedule it independently 😅

27 minutes ago, KluthR said:

Is Autoupdate not done within the plugin? I did not know that one can schedule it independently 😅

Its also a separate plugin.  It has its own settings for its schedule 

Good2know. That could be the cause for similar issues.

The plugin isn't deleting the older backups for me. I've got "Delete backups if they are this many days old:" set at '1'. At the end of the log it says;

Quote

[03.04.2023 00:32:56] done
[03.04.2023 00:32:56] Deleting Dated Backup set: /mnt/user/Backup/Unraid/Appdata/[email protected]
[03.04.2023 00:32:56] Backup / Restore Completed

 

But the folder and all the contents are still there;

 

Any ideas?

15 minutes ago, jmmrly said:

The plugin isn't deleting the older backups for me

Since this is not blocking anything, I wont fix this. Should be working with the new plugin within Unraid 6.12

Trying to use CA Appdata 2.5 using /mnt/remotes for destination.

 

I am getting the error: CA_backup.tar: Cannot write: No space left on device.

 

My remote target is an SMB share properly set up and working (I can browse and write from Plex) and with 16tb free.

 

Any thoughts?

 

 

Edited April 3, 20233 yr by mproberts

37 minutes ago, mproberts said:

I am getting the error: CA_backup.tar: Cannot write: No space left on device.

Please show /mnt/remotes in the file system or the listing at final destination: there must be a partial tar file in case of failure. Is it somewhere?

Target directory from UnRaid below.  I tried target configs with both:

/mnt/remotes/BACKUP_UnRaid OS Backup/

and 

/mnt/remotes/BACKUP_UnRaid OS Backup/Appdata/

 

Aside from my flashbackup file and the .DS_Store file (from my Mac touching the directory), there are no other files in the target directory.

Hm, found nothing interesting in the code which could prevent that. could you execute a

df -a

and share the result?

 

 

root@Wilhelmina:~# df -a
Filesystem                  1K-blocks        Used   Available Use% Mounted on
rootfs                       49391344     2174116    47217228   5% /
proc                                0           0           0    - /proc
sysfs                               0           0           0    - /sys
tmpfs                           32768        1192       31576   4% /run
/dev/sda1                    15248800      965472    14283328   7% /boot
/dev/loop0                          -           -           -    - /lib/firmware
overlay                      49391344     2174116    47217228   5% /lib/firmware
/dev/loop1                          -           -           -    - /lib/modules
overlay                      49391344     2174116    47217228   5% /lib/modules
hugetlbfs                           0           0           0    - /hugetlbfs
devtmpfs                         8192           0        8192   0% /dev
devpts                              0           0           0    - /dev/pts
tmpfs                        49474148           0    49474148   0% /dev/shm
fusectl                             0           0           0    - /sys/fs/fuse/connections
cgroup_root                      8192           0        8192   0% /sys/fs/cgroup
cpuset                              0           0           0    - /sys/fs/cgroup/cpuset
cpu                                 0           0           0    - /sys/fs/cgroup/cpu
cpuacct                             0           0           0    - /sys/fs/cgroup/cpuacct
blkio                               0           0           0    - /sys/fs/cgroup/blkio
memory                              0           0           0    - /sys/fs/cgroup/memory
devices                             0           0           0    - /sys/fs/cgroup/devices
freezer                             0           0           0    - /sys/fs/cgroup/freezer
net_cls                             0           0           0    - /sys/fs/cgroup/net_cls
perf_event                          0           0           0    - /sys/fs/cgroup/perf_event
net_prio                            0           0           0    - /sys/fs/cgroup/net_prio
hugetlb                             0           0           0    - /sys/fs/cgroup/hugetlb
pids                                0           0           0    - /sys/fs/cgroup/pids
tmpfs                          131072        2240      128832   2% /var/log
cgroup                              0           0           0    - /sys/fs/cgroup/elogind
rootfs                       49391344     2174116    47217228   5% /mnt
tmpfs                            1024           0        1024   0% /mnt/disks
tmpfs                            1024        1024           0 100% /mnt/remotes
tmpfs                            1024           0        1024   0% /mnt/addons
tmpfs                            1024           0        1024   0% /mnt/rootshare
nfsd                                0           0           0    - /proc/fs/nfs
nfsd                                0           0           0    - /proc/fs/nfsd
/dev/md1                   5858435620  4394856084  1463579536  76% /mnt/disk1
/dev/md2                   5858435620  4394282504  1464153116  76% /mnt/disk2
/dev/md3                   5858435620  4396368904  1462066716  76% /mnt/disk3
/dev/md4                   5858435620  4395751364  1462684256  76% /mnt/disk4
/dev/md5                   5858435620  3561133184  2297302436  61% /mnt/disk5
/dev/sdb1                  1875382960   467431776  1406625568  25% /mnt/cache
shfs                      29292178100 21142392040  8149786060  73% /mnt/user0
shfs                      29292178100 21142392040  8149786060  73% /mnt/user
/dev/loop2                  104857600    16292992    87988752  16% /var/lib/docker
/dev/loop2                  104857600    16292992    87988752  16% /var/lib/docker/btrfs
/dev/loop3                    1048576        4164      926140   1% /etc/libvirt
nsfs                                0           0           0    - /run/docker/netns/default
//BACKUP/UnRaid OS Backup 37043960800 20978234480 16065726320  57% /mnt/remotes/BACKUP_UnRaid OS Backup
nsfs                                0           0           0    - /run/docker/netns/bb81da434bbc
nsfs                                0           0           0    - /run/docker/netns/65b742e4bef7
nsfs                                0           0           0    - /run/docker/netns/6a03bf945432
nsfs                                0           0           0    - /run/docker/netns/22334e7d40a0
root@Wilhelmina:~# 

Oh, sorry - it should be df -h (h for human readable sizes) but it shares enough information.

 

TBH I dont see any issue. Whats a bit interesting:

 

tmpfs                            1024        1024           0 100% /mnt/remotes

 

But it could be normal.

Your backup share seems ok:

 

//BACKUP/UnRaid OS Backup 37043960800 20978234480 16065726320  57% /mnt/remotes/BACKUP_UnRaid OS Backup

 

Could you mount this same target again with a dofferent name with no spaces in it? it should make no difference, but better safe than sorry.

New plugin version status update

Tests are going well so far. No blocking issues were reported for now. My plan is to release a first stable, if no issue were reported this week.

The "v2.5" plugin is able to survive the Unraid update to 6.12 stable (as soon as its published) and will prompt you to install the new plugin. But it will NOT auto-backup anything in that case!

 

The new plugin will give you the opportunity to migrate your settings from the "old" plugin.

1 hour ago, KluthR said:

Could you mount this same target again with a dofferent name with no spaces in it? it should make no difference, but better safe than sorry.

 

That did it!

 

I'd thought of the spaces in the Windows directory earlier, but assumed since the OS (UnRaid & Krusader) saw it and worked to browse it was ok.  Probably a best practice to follow anyway (no spaces) when mixing OS's.

 

Thank you!

 

Hmm, okay. But I dont see why it was not working. The plugin can work with spaces in its destination path. I will check this.

Whats the current state of the plugin?

 

I am on 6.12-rc2 and installed the old one, 'v2'. But in the settings I cannot apply any changes I made. The 'apply' button is uncklickable/grey.

 

Tried turning off docker and then change settings, didn't help. Am I missing out on something?

Appdata Backup/Restore v2.5 isn't available as a stable version in CA, right? Need to apply urgent changes so that the appdata folder is backed up again.

See the pinned post and the 2nd one

Hello, I have settings to delete backups if they are 8 days old, but the old backup(March 23 backup) is still there. Can you please help me? How can I automatically delete old backups?

 

Edited April 5, 20233 yr by HHUBS

Sorry, no further updates for this. 6.12 is not far away (at least I think so). No issues known for the new plugin. If you still encounter issues then, post again.

Edited April 5, 20233 yr by KluthR