Is it completely reliable to copy a running container with a --stateless flag? I’m trying to figure this out. What exactly is done under the hood during the copying process with this flag and how it differs from not using this flag? I found no information by googling, and it would be great if some details were available 
.
I wonder if I should stop containers for the 100% reliable automatic copying to a backup server, or they can stay running.
--stateless just means don’t attempt to transfer the runtime state.
That’s fine and what most people would probably assume a copy to look like as containers live-migration has not been much of a thing so far and even on VMs, copying the runtime state is often a bit weird as you now have two identical running copies of the same thing
So yeah, --stateless is fine. Your filesystem won’t be 100% consistent as it would if the container was stopped before the copy but that’s rarely an issue unless you’re dealing with very picky software or you’re copying right in the middle of a full OS upgrade.
So, does it only mean that a container is copied as stopped on the target machine? With the files taken as is from the running one? I’m just not sure what is included in the “runtime state”, and found no sources on that. Is it memory dump? Some specific files in the filesystem, that are ignored in the stateless mode?
Yep, that’s right, the container will be copied as stopped on the target using the current files from the source.
When possible (extremely rarely for containers), as stateful transfer would also carry all the current memory and running process state, so the target copy would arrive as running and be absolutely identical to the source, including all network connections, process uptime, process memory state, … It’s pretty rare that this is useful in a copy scenario, it’s obviously a lot more useful in a move scenario as that’s live migration, which is a pretty commonly used feature for virtual machines.