A container is a temporary isolated environment where we don’t even save anything that has to be migrated. If you did that, you will need to switch to the right way eventually, which is using volumes or bind mounted folders for persistent storage. Then you can move the data the way you would without containers and just recreate the container on a new server by running the same command you did on the original server.
You can choose copying out data from the container (docker cp --help) even when the container is stopped but not removed and changing the container definition to mount that folder on the new server
Or you can run docker container commit to make an image from the container, use docker image save to save that image, copy the tar file to the new server, and use docker image load on the new server. You will also need to change the command you used to create the container, because you will have a new image with a new name.
But again, the right way is not storing data in the container. So even if you don’t want to do it now, don’t forget about it.
Checkpoint is used for point in time checkpoints of a container, so this container can be restored at any existing checkpoint.
option a) manually (see @rimelek’s answer). option b) Docker swarm services can be used to run containers that could be spawned on other nodes, if the node they are running becomes unavailable. Volumes would need to use remote shares accessible by all nodes where the container could be potentially spawned.
Not possible. It is possible for Kubernetes, though it requires a commercial product cast.ai