Investigate/Implement support of backup-restore plugin

[LongLiveCHIEF]

Determine what changes could be made to enable support of the backup-restore bundled plugin.

• Need to identify what problems exist with current implementation (users have reported permissions errors)

• identify changes that could be made to allow restore to work without errors

• determine any caveats to those changes due to docker ecosystem

• implement changes if severity of caveats is low

reference discord conversation start: https://discordapp.com/channels/704958479194128507/744267928559550566/760421775925444658

[LongLiveCHIEF]

/cc @ax42 if you do any further testing for this one, drop logs in this thread in case we get other contributors/historical reference. Also feel free to copy over any logs or steps you already shared in discord.

[ax42]

https://gist.github.com/ax42/58d0c4c41eeabd91600a64e6d3280578 is the log file of the restore failing.

[LongLiveCHIEF]

The current method the backup/restore plugin uses to restore is this:

1. move octoprint's basedir -> basedir.bak
2. unpack the backup to basedir
3. delete the backup

This means that if any other active process is using the basedir on the host filesystem, then the backup restore will fail since the OS prevents this in order to prevent fatal cascading process failures. If you're using docker to mount a volume to octoprint's basedir, then docker process will have an open fd for the octoprint basedir, and step 1 above will fail.

This isn't just a docker problem. For example... another good example would be if you're using NFS or some other externalized file server mounted onto the host as octoprint's basedir.

Basically, this one comes down to how the backup/restore is implemented, and isn't something that needs to be fixed within the docker image itself. If there is a technique the implementing user wishes to attempt based on mounting to different container volumes than the basedir, then docker allows that for specifically that type of reason, but it's not something you'd change in the docker image because a docker image should be implementation agnostic in order to do what docker does.

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/backup-restore-fails-on-device-or-resource-busy/27182/2

[LongLiveCHIEF]

I've now implemented plugin persistence via #132, I think I've identified a way to officially support backup/restore plugin from within the docker container.

What I'm going to try is this;

• change the octoprint --basedir in the service start command so that it is a sibling directory to PYTHONUSERBASE, instead of the way we have it right now where PYTHONUSERBASE is a child of the octoprint basedir.

I'm going to test the following approach:

• have the docker image create an /octoprint/octoprint directory as the --basedir
• have the image create the /octoprint/plugins directory explicitly, and leave it set as the PYTHONUSERBASE

This approach should mean the we can keep the current usage of mounting the /octoprint as the container volume, which should make existing usage docs compatible so it doesn't impact users, but still enables backup/support by decoupling the basedir as the volume mount directory.

If this works, we'll need to remove the config.yaml pre-setting for the disabled status of this plugin.