To the author: thanks for all the work that goes in to sharing this. When people share with this much detail I always find at least a couple things that improve my setups.
Here are some I can share back:
- If you mount the data and config folders for a docker container you can skip backing up the container itself and back up the mounted folders with bog-standard backup tools. Recovery then means verifying the mount positions in the docker-compose file and running `up` on the new host
- When running cron (I also use separate cron containers as it’s been the cleanest and most stable solution), there are two handy tools:
- have the cron container use the image from the application itself: `image: nextcloud-app:latest` (easiest if you use a Dockerfile for the “base” image, even if it only contains `FROM nextcloud:stable`)
- use extension fields (https://stackoverflow.com/a/59796964)
For the containers, do you mean mounting them to a NAS? I already have them mounted locally on the VM so the files are easy to grab there, but I've never thought about mounting them on a NAS. I'll have to give that a think
For example in Proxmox I have /media/ssd-storage/Containers/ where each subfolder is mounted to it’s VM (therefore isolated) and each VM’s docker-compose file brings in the volume mounts to it’s containers.
Then, all containers are backed up with a duplication of the ‘Containers’ folder. In a couple cases the container itself needs to be shut down in order to be backed up safely but those are few, far-between, and outdated.
I think Ubuntu used /media instead of /mnt. I also ended up using /media on all my Linux boxes after using Ubuntu foe a while. I’m also currently using /Volumes (mostly from services that were on OSX and configured before Docker was available).
Veeam WAS quite RAM heavy when it used Microsoft SQL, but they have updated it to PostgreSQL which has helped, and Veeam for Microsoft 365 uses a fair chunk too. But the reason it actually has 10GB of RAM is that it seems when restoring files through the Arq application, it caches to RAM, and having more RAM makes it much faster. I could probably move it down to 8GB no issue
Keep in mind that most of those containers are very light and are not really "Doing" anything, unlike everything in the Backup VM
And there is no way Windows actually needs all that RAM, either - there is only so much an OS can do, I feel like maybe a lot of code in Windows (probably userspace) copies and caches way too much.
Here are some I can share back:
- If you mount the data and config folders for a docker container you can skip backing up the container itself and back up the mounted folders with bog-standard backup tools. Recovery then means verifying the mount positions in the docker-compose file and running `up` on the new host
- When running cron (I also use separate cron containers as it’s been the cleanest and most stable solution), there are two handy tools: