I am currently in the process of installing Nextcloud AIO on an Ubuntu server for a maximum of five users. While setting it up, I started wondering whether I should clone the VM at a certain point, assigning it a separate IP and domain for a “production” and “test environment.”
This way, I could run updates, tests, and other changes in my test environment before applying them to my production environment.
However, this raises the question: How can I accurately replicate the production environment in the test environment? Has anyone done this before and has an idea of the best approach?
I assume that after cloning the installation, I would need to sync the data directory, MySQL database, and Nextcloud settings at least once a day using SCP and rsync, making sure not to overwrite the domain and IP of the cloned instance.
Which paths and config files would need to be synced for this to work properly?
I just use a similar setup (same apps) but not with the user data. I also sometimes use it to check mass upload speed and stuff like that, or new apps that I want to test before putting on the production setup. Also you can use release candidates and other beta versions and you can test it and try to make it fail.
I use just different subdomains (same ip address).
Like this, I usually see before when some apps start to have problems, or when the whole update/upgrade procedure has some issues. And it gives me time to figure it out. So, I don’t know if you really need user data for that. It is important to have the same environment (I don’t use docker, the images probably absorb already a certain amount of variables).
Thank you for your response. I now have two different VMs running AIO, each with separate IPs and separate domains. The files don’t necessarily need to be synced, but I’m wondering which volumes or configuration files should be synchronized in order to get a exact copy of the production environment.
I also want to give users the ability to run tests, so their profiles on the test server should match those on the production server. Perhaps I could achieve this using Borg—backing up the production environment via Borg, restoring it on the test environment, and then adjusting the IP and domain each time afterwards.