I really-really hope you are not relying on Docker only when protecting 19G of data. Docker volume operations are the equivalent of playing with sudo rm -rf, shit's going to happen once in a while.
I am a Docker newbie but I thought it wasn’t considered best practice to use Docker for anything where you care about the data in the container. I’ve only used for API’s batch jobs, etc.
You're correct that container root file systems should be considered ephemeral, and writing anything that needs to be persisted to them is a smell. However you can mount persistent volumes to a container specifically for the purpose of deploying stateful applications and referencing persistent data. How safe you can consider that data to be depends on the underlying tech that is provisioning the storage. For example a GCE persistent disk with the retain flag set is probably pretty damn durable. I would still back it up, however.
What advantage does Docker really give you for long live mostly stable resources like databases?
For batch processing, my usual pattern has always been to move the data from (slower) network storage to local storage, process, move results back to network storage.
Well whichever advantages of containers are important to you I don't think you lose them just because the process reads and writes persistent data. It seems like you're really questioning whether it's as compelling a use case, which is a bigger topic and depends on a lot of specifics.
I've never been willing to consider docker volumes persistent. In the big picture, a requirement of "posix filesystem semantics" and "persistent" is a pretty inconvenient and/or expensive requirement.