Unsolved Double Migration of NextCloud Apps
We are in a strange situation right now, we have two servers, Server A and Server B. We are trying to migrate NextCloud from Server A to Server B(for temporary storage) and then again back to Server A. (Sounds funny because we need to set up Server A with S3 storage). We are running Cloudron on both servers.
We have almost 200GB of data and while using Cyberduck to download files via FTP, the files are encrypted and they are not read by Server B. If we use Cyberduck for Nextcloud (Server A) to Nextcloud (Server B) transfer, it takes forever to read the files and it is a manual process.
Our Server A got down recently and we lost connectivity because storage got full on our local storage hence in the new setup we want to use S3 as our primary data location and use local storage as Database storage.
We are not able to locate the password for our existing nextcloud database because we also want to migrate our Nextcloud Talk.
We are new to Cloudron and would need a bit of detailed help.
Thanks for any help in advance.
The database password can be found in the app's environment. Just open a webterminal into the app and type
envto see all connection details.
For your first query, I am not sure I found any specific question in your description?
@nebulon thank you for your response.
We need help in finding a way to migrate data from Server A to Server B and then back to Server A. During this, we don't want to download data locally on our system.
It will be like we store the data temporarily on Server B, and set up our server A with Nextcloud and using S3 storage (we also need help in setting S3 storage as the primary storage location). And once the setup is complete, move everything back to Server A.
Server A is the production
Server B is the development/test
@chminc Can't you use the Cloudron backup function to store a backup with an external provider, implement it in Cloudron on server B if you have to, and then do the same the other way round?
Backblaze or Digital Ocean Spaces worked well for us in similar cases.
@ekevu123 thank you. We thought so, but will it include all data files (including the database)? Also, we had file encryption in place, won't that be a problem?
Another doubt that we have is, once we restore cloudron backup on Server B, and restore it back on Server A, How will we move Nextcloud data from primary storage to S3 or Backblaze or Digital Ocean?
@chminc a Cloudron backup contains everything including the database.
For your plans to use S3 for primary storage, I would suggest reconsidering this though, as we hadn't had good experience with Nextcloudo and S3 storage, causing unreasonably high load of requests against the storage. This is partly because Nextcloud works under the assumption of having a filesystem and an object store is not a filesystem.
@nebulon so we shouldn't do it because of the cost? We are just looking for a more stable and easily scalable solution, in terms of storage. Current setup hardly uses any RAM and CPU at all.
Do help us with the process of restoring or moving the backup to object storage.
@chminc the CPU and memory is likely not the issue there, but the I/O speeds to the storage. Generally Nextcloud really only works well with real filesystems, not object storages. However many VPS providers allow to attach disks to a server, which can be resized.
@nebulon the object storage that we used gave us around 15MBPS to 20MBPS. We used Cloudron Backup service to transfer a snapshot of the app from Server A to Server B, but once the restore was completed, it didn't have the complete data.
@chminc Indeed, I looked into this quite recently myself for our setup and came to very similar conclusions. It's not advised to use object storage. We will move to volume storage in case the space on the server won't be enough - it is not that much more expensive. But I have made really good experience with the Cloudron backup function, it restored everything completely error-free. And you can store the backup on object storage. Using encryption is not a problem at all.