SMB mount /var/lib/docker/volumes to a fileshare?

[Shadow]

I've setup MailCow on my DS718+ by running it in a seperate Ubuntu VM.

MailCow stores all its data, like emails and databases in Docker volumes. So this is apparently saved in /var/lib/docker/volumes . These Docker volumes look like simple folders to me..
For backup purposes I wonder if it would be easy to have al this data saved on a volume of my NAS, as that would automatically have that data be included in my regular HyberBackup schedules.

So, lets say I copy all the data from /var/lib/docker/volumes to \\nas3.mydomain.com\MailStore (this is the DS718+ which is the host of this Ubuntu VM).
Then in this Ubuntu VM stop the entire MailCow stack
Delete /var/lib/docker/volumes
Recreate /var/lib/docker/volumes as directory
in /etc/fstab , mount /var/lib/docker/volumes to \\nas3.mydomain.com\MailStore
Start up all the MailCow Docker containers again

Would this work? Or is this too much of a bold idea?

Some screenshots:

 

[one-eyed-king]

So, lets say I copy all the data from /var/lib/docker/volumes to \\nas3.mydomain.com\MailStore (this is the DS718+ which is the host of this Ubuntu VM).

You can directly declare volumes that are backed by nfs using the local driver. The term "local driver" is ambigous, as it only indicates that the volume is registered on each docker node speratly , even in a docker cluster. Thus, if you want to change any parameter of the volume, you would need to delete it on every node of a cluster. The local driver actualy supports bind/cifs/nfs and whatever mount is able to mount on that machine. In my experience this approach causes less problems with stale nfs share mounts, as docker should remedy the stale situation by restarting the container or remounting the share itself.

I don't know the options from the top of my head, but can lookup at least how you would use it a docker-compose.yml.

Update:
In a compose.yml it would look like this:

volumes:
remote-vol-1:
    driver_opts:
      type: nfs
      o: addr=192.168.200.19,nfsvers=4
      device: :/volume1/docker/MailStore

In the example 192.168.200.19 is the ip of my nas and the device path is the path to the MailStore folder in the docker share (which is on volume1). I just picked up MailStore from your post - I am not using it

And use it like this in your service:

services:
  my-service:
    ...
    volumes:
    - remote-vol-1:/path/in/container
    ..

 

[one-eyed-king]

I just realize I ignored that you asked for CIFS/SMB. The docker-compose.yml syntax looks slightly different for CIFS:

volumes:
  remote-vol-2:
    driver_opts:
      type: cifs
      o: username=_myuser_,password=_mypass_,uid=1026,gid=100,vers=3.0
      device: //192.168.200.19/docker/MailStore

Make sure to configure the options ( o: ) and device parameters according your own setup.

Unluckily you can not specify a credential file in the volume declaration. Instead you need to declare the options for username and password for each volume.

Though, from my experience nfs v4 shares are more reliable, but suffer from the restriction that inotify events (e.g. when a file listener is used to trigger actions on file creat or change event) are not propagated to the nfs client. It is said that CIFS does propagate these type of events - I never verified it...

Regarding backups: are you sure the backups will be consitent if the container is not stopped during backup?

Wouldn't it make more sense to leave the data local in the vm and create a chron job that stops the container, creates a tar archive from the volume's source folders and write the resulting archive to a remote nfs/cifs share, and then start the contaiener again? I am aware this will result in up to a couple of minutes service downtime, but you can be sure that the backup is consistent.

 

[Shadow]

Wouldn't it make more sense to leave the data local in the vm and create a chron job that stops the container, creates a tar archive from the volume's source folders and write the resulting archive to a remote nfs/cifs share

Actually, the MailCow package comes with a backup script that can do exactly this (without stopping the containers). See: Backup - mailcow: dockerized documentation

So I did indeed try to setup a cronjob, but it doesn't work.....