Technically, containers always run in Linux. (Even on windows/OS X; on those platforms docker runs a lightweight Linux VM that then runs your containers.)

And I wasn't even using Docker.

How I lost a Postgres database:

1. Installed Postgres container without configuring a volume
2. Made a mental note that I need to configure a volume
3. After a few days of usage, restarted the container to configure the volume
4. ...
5. Acceptance

You are not alone.

sleep 120 #TODO: actually solve a problem
echo "Sorry, we could not solve this problem."

Features necessary for most btrfs use cases are all stable, plus btrfs is readily available in Linux kernel whereas for zfs you need additional kernel module. The availability advantage of btrfs is a big plus in case of a disaster. i.e. no additional work is required to recover your files.

(All the above only applies if your primary OS is Linux, if you use Solaris then zfs might be better.)

Go: Why is your every second sentence a caution?

I use rsync+btrfs snapshot solution.

1. Use rsync to incrementally collect all data into a btrfs subvolume
2. Deduplicate using duperemove
3. Create a read-only snapshot of the subvolume

I don't have a backup server, just an external drive that I only connect during backup.

Deduplication is mediocre, I am still looking for snapshot aware duperemove replacement.