docker-nfs-server as a "data/system snapshot engine": feasible?

[johnnyutahh]

Is the following use-case feasible? (More-detailed questions at the end of this msg.)

Summary

I am investigating implementing a docker-nfs-server to primarily to provide convenient "snapshot" mechanism for my team's nfs servers with the nfs-filesystem purposely inside the nfs-server container, as part of the docker image and not externally mounted from the docker host or anywhere else.

Purpose, desired features and integrations

• Convenient and powerful snapshots. We're attempting to enable a means to fully snapshot nfs-server content (filesystem files and complete docker-container state). This seems potentially more easy, powerful, and/or convenient than trying to snapshot with zfs or some other alternative, at least because of the power and convenience of docker (maybe?) enabling easier-to-manage "full system snapshots".
• Easy docker-image export. Capture all the above state in a single file as a single export of an image for easier archiving and mobility between docker hosts.
• Run on a LUKS mount within the docker-nfs-server image. Run the nfs-server process, within the docker-nfs-server image/container, on top of a LUKS-based "filesystem in a file," for data-security purpose (and keep the LUKS-decryption secret/key stored separately from the docker-nfs-server image). We realize this may take some of my custom modifications of docker-nfs-server.

Our current environment's scale is SMALL

Pls note: our targeted network environment and nfs-client load is small enough, and the docker host beefy enough (CPU, memory, etc), where I am not yet concerned about system-performance things.

Questions

1. Is something like this use case part of the original intent for this (docker-nfs-server) project?
2. Is the LUKS integration feasible (with the NFS-served files and the LUKS mount inside the image/container)?
3. Does anyone see any additional problem with this (above) application/use case?
4. Are there any specific constraints or limitations (in this context) for which we should be aware?

[johnnyutahh]

Upon further reading of https://github.com/ehough/docker-nfs-server#starting-the-server :

Does "Provide the files to be shared over NFS ... from... files baked into custom image" mean that the docker-nfs-server container would read-and-write files directly from another docker container that contains/stores the files?

If so, by what means does it do this -- ie, how does the docker-nfs-server container communicate with files served by the filesystem in the "data container"?

(I'm unclear on what Docker's copy command does in this context; specifically, what does "baked into" mean? Which files get copied where, etc?)

[johnnyutahh]

At some point I'll be "cracking the hood and rebuilding the engine" (hopefully it's a minor rebuild, if no rebuild at all) to support my use case, which is totally cool and what I initially expected to do anyway.

I am trying to get @ehough 's attention by other means with as of yet no success. I've been preparing to do this work at some near-term, future point in hopes that Eric comes in and says "oh yeah, this is easy, just do 'X'" and saves my team some effort, while we work on other-more-pressing tasks.

In any case, the output from Eric's efforts looks (without yet testing it) remarkably good, and my team and I are very appreciative to not have to build a more-robust nfs-server container from scratch. Thanks Eric!