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?
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
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.