Nextcloud on VM or Docker? Best set-up for proper backups?

Submitted ⁨⁨1⁩ ⁨year⁩ ago⁩ by ⁨notsofunnycomment@mander.xyz⁩ to ⁨selfhosted@lemmy.world⁩

Hi all, sorry if this has been asked/discussed before (I couldn’t find any directly overlapping posts):

I have been running the Nextcloud snap now for quite some time, and although things have run quite smoothly, I never really managed to properly back things up.

I make weekly backups of the database, config and data, but it’s very hard and time consuming to glue these elements back together. And as they say: when you can’t check whether a backup works, it’s not really a backup.

I have been experimenting with KVM/qemu lately and things look pretty great. The idea of simply backing up the entire OS that runs Nextcloud (a backup that you can easily deploy/run somewhere else to test if it’s working) sounds very attractive.

Reading around, however, tells me that some of you recommend running the Nextcloud docker (instead of a VM).

My questions:

What would be the advantage of running Nextcloud as a docker, instead of within a VM?
What would be a sensible way to have an incremental/differential backup of the VM/Docker?
The storage usage of my Nextcloud instance exceeds 1TB. If I run it within a VM, I will have to connect it to a 2TB SSD. Does it make sense to add the external storage space to the VM? How does that affect the ease of backing the full VM up? Or (as I have read here and there) should I simply put the entire VM on the external SSD?

source

Comments

Sort:hotnew top

PriorProject@lemmy.world ⁨1⁩ ⁨year⁩ ago
Docker is a powerful tool to increase confidence in your backups.

In a VM, the way you figure out which files to backup is to read the docs. If they’re wrong or you misread them, the only way you’ll find out is by doing a full restore test… which is often painful and complex in home setups.

In docker, the filesystem outside volumes is destroyed between every container restart. If your volume setup is insufficient, you’ll repeatedly lose state during your initial installation process between container restarts. You’ll continually test your state management throughout the lifetime of the service during restarts. This leaves a much smaller window for backup mistakes.

The tradeoff with docker is that the networking is complex (well, everything is complex… but the networking is where it often hurts). But if you’re able to deal with that one-time pain, it’s superior almost all the time for home setups. I think the only things I run outside docker are ssh and netdata. SSH because it’s stateless and works perfectly out of the box, and netdata because it wants permissions to everything… and is functionally stateless for me because I don’t care if I drop my observability data.
source
fraydabson@sopuli.xyz ⁨1⁩ ⁨year⁩ ago
From my experience docker seems to be best for me. I’m also no expert in any of this.

What I do is run the container in docker and then I user rsync to backup my files to both a secondary hard drive and off site storage with a backup provider.

I haven’t looked into database backups yet. Just files.

source
- partizan@lemm.ee ⁨1⁩ ⁨year⁩ ago
  docker exec nextcloud-mariadb-1 /usr/bin/mariadb-dump --defaults-extra-file=/backup/.mylogin.cnf -u root --single-transaction --quick --all-databases |gzip > /mnt/mysql/backup/nc${NUM}_dump.gz
  
  You are welcome
  
  source
p_consti@feddit.de ⁨1⁩ ⁨year⁩ ago
I’m not really an expert when it comes to backups, so I’ll only answer point 1:

The general advantage of docker over VMs is that it is not a full virtualization. A docker container still shares the same kernel as the host system (at least on Linux); thus processes in a container essentially run on your host and you can see them in your task manager (they are just heavily isolated). This also means it’s way easier to connect the filesystem (see github.com/nextcloud/docker for details). This generally makes docker containers more performant than full VMs. VMs also need a static allocation of memory, where docker simply shares the host memory and uses as much or little as it needs.
Of course this also means that a process can more easily gather information on your host, since it’s not full virtualization.
Like with VMs, you can easily just start the container(s) again, and you only need to save the data, since the container can be rebuilt.

I’ll add that the guide linked above uses docker volumes, which are docker-managed spaces for your data. You can export and import a volume, but generally don’t have access to the data (afaik). You can also mount a folder on your filesystem instead if you prefer to have acces all the time.

source
- dublet@lemmy.world ⁨1⁩ ⁨year⁩ ago
  Yes, indeed. One of the nice things about docker is that you can keep everything self contained, but then also map in volumes. This may be an external directory for configuration that you archive elsewhere but could also be something more advanced like a Kubernetes PVC.
  
  source
rambos@lemm.ee ⁨1⁩ ⁨year⁩ ago
Im running nextcloud in docker from lsio atm. Doing daily file backups, so not database, mostly because it seems its pain to test backups, but also dont rly need anything else (at least not for now).

There is also a community !nextcloud@lemmy.world

First time I hear about running nextcloud in VM. Following to learn more.

source
vegetaaaaaaa@lemmy.world ⁨1⁩ ⁨year⁩ ago
Follow the official documentation docs.nextcloud.com/server/latest/…/installation/

source
- Batbro@lemmy.world ⁨1⁩ ⁨year⁩ ago
  Don’t they offer an official all in one docker image?
  
  github.com/nextcloud/all-in-one
  
  source
  - boonhet@lemm.ee ⁨1⁩ ⁨year⁩ ago
    It’s more of a pain to get running than you might think for an official image. I got it running but definitely had issues getting started.
    
    source
noneabove1182@sh.itjust.works ⁨1⁩ ⁨year⁩ ago
I have the snap installed, for what it’s worth it’s pretty painless AS LONG AS YOU DON’T WANT TO DO ANYTHING SILLY

I’ve found it nearly impossible to alter the base behaviour and have it not entirely break, so if nextcloud out of the box does exactly what you want, go ahead and install it via snap…

I predict that on docker you’re going to have a bad time if you can’t give it host network mode and try to just forward ports

That said, docker >>>> VM in my books

source
Swiggles@lemmy.blahaj.zone ⁨1⁩ ⁨year⁩ ago
If you can use containers always use containers as a rule of thumb. VMs are less efficient in almost every way and they add some unnecessary complexity.

For docker you basically only have to backup the persistent data. So in case of the docker setup you just have to backup the mounts and probably your compose file you are using. This probably also answers your third question already. Container files can be left alone and don’t need to be considered for backups as they should be stateless and can reside in their default location (/var/lib/docker/overlay2 or so by default).

Overall it is quite simple as you only really have to consider the mounts and the docker setup. The mounts you define and should be really obvious and the docker setup is just a few config files at most or just the compose file.

source

Decronym@lemmy.decronym.xyz ⁨1⁩ ⁨year⁩ ago

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters	More Letters
HTTP	Hypertext Transfer Protocol, the Web
HTTPS	HTTP over SSL
SSH	Secure Shell for remote terminal access
SSL	Secure Sockets Layer, for transparent encryption

[Thread #34 for this sub, first seen 13th Aug 2023, 08:55] [FAQ] [Full list] [Contact] [Source code]

source

maggio@discuss.tchncs.de ⁨1⁩ ⁨year⁩ ago
My friend and I run most things in kubernetes (k3s), and then we use longhorn to backup volumes, which then can be re-used if your cluster crashes. Here’s a blog post describing the process (although not for nextcloud specifically, it could be applied to Nextcloud as well, as we do this for nextcloud as well)

Octopusx blog: Backup and Restore

source