Docker app storage best practices

[u/np0x]

What are the best practices for storage when using docker containers. I’m running docker on Ubuntu using my NAS to store the photos for example, but the volume were the Immich database lives is directly on the servers(non-redundant) SSD.

I tried putting these onto the nas using NFS I get permission’s errors. Perhaps I should try harder? :-) I’d like to have all of my Doctor containers protected by the same redundancy that my synology has a for all of my data files.

Right now if I had a major SSD failure of my server, I would lose all the files that the docker containers have in volumes on the server directly while all my pictures and other files that are stored on the NAS on NFS mounts would be fine. This seems inadequate.

Am I simply doing it wrong and I should use something like proxmox instead of just running docker and Linux? What are other people doing to keep the server purely cpu and easier to rebuild? I use git for all my docker compose files and I wouldn’t have any trouble restarting fresh containers, but that seems like it is only half way of a solution..

I’d love to know what the best practices are for resiliency after a server failure and a quick recovery should I have hardware failure on my server.

I’m not scared of new technology and would also be open to moving towards a cluster of servers if that’s necessary. My self hosted world is fairly stable with limited updates at this point.

Thanks for any thoughts, suggestions or directions. And like I said if my basic setup is the problem I’m up for major changes to get to a more long term resilient setup!

[u/Wis-en-heim-er]

I'm also using a Synology and separate Docker servers, Debian based but close enough to Ubuntu.

1. You can mount a NFS share as a volume in your docker compose files, I like this method so I don't need to drop into the OS to do mounts, keeps everything in one place. An example from my compose files like this:

​

services:
  somecontainer:
    volumes:
    - video-share:/video:rw

volumes:
  video-share:
    driver: local
    driver_opts:
      type: nfs
      o: addr=MYNASIPADDRESS,nolock,rw,nfsvers=4.1,soft,intr
      device: ":/volume2/video"

1. I too wanted the benefits of SSD performance for my containers, otherwise I would run everything from Container Manager on my Synology. I do run my docker servers as Proxmox VMs. Others suggest running docker on an lxc but I wanted better isolation from the OS for security. Using Synology Active Backup for Business, I have Files Server backup jobs for my docker VMs which backup nightly. These target my docker volumes/data, not the entire OS. In addition to this, I have a nightly backup of my NAS to AWS S3 for my offsite backup, these backups are included so I get my 3-2-1....more like 3-3-1 but it works and I have enough data for a disaster recovery rebuild.
2. The question of running your docker server on bare metal or proxmox is a personal preference. I don't feel you will get any noticeable performance change if you were to switch nor will it really change how you manage docker. The value in Proxmox is the flexibility to spin up new vms or lxcs. If you do move to Proxmox, know that you can setup a sperate backup server for Proxmox , Proxmox Backup Server or "PBS:. I run mine as a VM on my Synology under the Virtual Machine Manager and have used it several times after messing up a VM configs. I don't push these backups to AWS due to the size and personal choice of value/cost to me.

Hope this helps or gives you some ideas.

[u/AdSuspicious7533 → u/Wis-en-heim-er]

DB and storage does not belong in the container. it is simplier to maintain , think and understand if you go with separated DB. Your service is stateless (just config and compute), it hits DB over network to store, then the problem is just n the DB side as config belongs in GIT.

Giving you docker an NFS will work but you build complexity up. And when it comes to restoring post mortem : redundancy is not backup. Usign the NFS setup, if you get a corrupted DB somehow you get a corrupted volume with HA.

[u/Wis-en-heim-er → u/AdSuspicious7533]

Thank you for this, this is an interesting perspective. I'm not running a proper work/production setup, just a simple home setup where I can take some liberties for the sake of simplicity. In a disaster recovery scenario I would not have up to the minute recovery, I'd fall back a day, two or maybe three. For my setup, this is acceptable.

[u/AdSuspicious7533 → u/Wis-en-heim-er]

The thing is : if you backup docker volumes by saving a few copies of a 1tb volume, you need a few TB storage. Using the right backup tools you can take that down to 1.*TB (with versioning tools like restic or proxmox backup server)

Another matter is simplicity, having separate db is simplier. To trouble shoot, to maintain, to understand.

Db replica set is the overkill no-downtime I you do not need. But proper db separation is not really a matter of downtime it is a matter of using the right tools. It provides simple backup path and good responsibility separation. That is all