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?
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.gzYou are welcome
What would be the difference between this and creating a volume to the data directory and backing up that one?
I mean, is it not recommended? Is there a potential to backup in the middle of a DB transaction which would make the backup useless?
Exactly, you can end up with inconsistent DB state. Only possible filesystem level solution is take a LVM/btrfs/zfs snapshot and copy the DB files from there, but at that point, the dump is much easier and more convenient.