Cloudron Forum

Glad it worked out in the end 🙂

OK, instead of increasing the disk space or trying to hunt down files to delete, I decided to set up the new server on a temporary domain to test everything out (and might just migrate to that domain permanently).

One issue I ran into was Cloudron wouldn't recognize the DNS in the domain settings when changing the dashboard domain. Since I set up the server with IPv6 I had to enter both the IPv4 and 6 addresses into the DNS config for my domain (I'm doing it manually since Godaddy and NameCheap won't let you use their API unless you have a LOT of domains and/or pay a premium). I'll have to do that for every app individually.

I'll have to think ahead as far as disk space is concerned so I don't run into the Postgresql problem again.
Thanks for your help!

@RazielKanos yeah, you will have some down time when migrating. If apps don't change, then you can avoid downtime by restoring using 'dry run' - https://docs.cloudron.io/backups/#dry-run . Once restored on new server, just change the DNS. This way you won't have downtime but with the caveat that you will lose changes that were made to the old server since the backup that was restored on the new server.

Hi guys,

A quick update for anyone who may run into this in the future. Yes, that did the trick, I was able to create a /mnt/sync/ directory under Volume, and executed "Retry Task."

One thing that I did notice was that I couldn't restore from the last version of the backup, but the one previous to that went through just fine.

Really glad for such such a smooth migration process!

@girish Thanks for answering, I will try it and if I still face any issue, I will update by starting my own thread.

@cvachery yeah, I encountered the same (had to reset passwords post migration etc). Might be worth reporting upstream.

Hi @mazarian,

in /home/yellowtent/platformdata/logs you will the file box.log, which should give an indication of what went wrong during your restore.

I did not check what the documentation says about this, but earlier this week I performed a restore in a similar manner to you and watching the dashboard during the restore there was definitely some parallel activity going on during the restore. I would have said that it was probably something like two or three apps at the same time max.

@girish said in All previous folders and files have disappeared after migrating Nextcloud to a different Cloudron server:

Alternately, you have to wait for us to investigate if the situation has changed wrt migrating users from uid based installations .

Out of interest (because it came up again here did you ever get around to investigating this?

And re "uid based installations" - is that some legacy thing? i.e. are there non-"uid based installations" - and were you referring to installations of Nextcloud or installations of Cloudron? 🙂

I'm thinking/ hoping that perhaps you meant uid installations of Nextcloud and that was a legacy thing and now they aren't like that and perhaps Nextcloud is portable from one Cloudron server to another? But I'm not at all clear 🙂

@girish aftering giving both redis and the app a load more memory the import worked fine. I don't know why I didn't just try that before to be honest.

I'm not sure how it managed to half-work before so that the apps was running and the import seemed to have worked, but without the users, but I've just done the back import again and the users have re-appeared, so panic over. Phew.

Migration aside, maybe we should periodically check keys for validity and raise some notification 🤔

@hpz24 said in Best practice for migrating apps from one Cloudron to another?:

Now I'm curious: does an app actually survive the move to another cloudron instance with a different domain?

In most apps, yes. The federated apps like mastodon and matrix are a special case. They don't support changing the domain . Even though the app itself will work after changing the domain, expect bad things to happen (tm) after domain change. For example, not seeing proper history of old message etc. I haven't tried this much, so this is just a warning really.

I figured out the issue - posting here for anyone who encounters the same...
I had not whitelisted my new server's IP address with my registrar (Namecheap). Once I did this, installs and uninstalls are now working.

The error was actually an external error passed from Namecheap, not an internal Cloudron error message 🙂

@fbartels said in Backups and users:

Cloudron treats user names as unique

Yes, we used to uuid and then went and changed all the apps to use username so that migration from one Cloudron to another (or anywhere else) is easier. As long as the username exists on the other cloudron, user should be able to login.

@plains-digital yes, you can also restore app by app. https://docs.cloudron.io/backups/#import-app-backup . But obviously, restoring entire server via backup is far simpler.

I have not used VMWare tools extensively, but I think you can do the below

Take a full Cloudron backups before you do anything. I think the best approach is to simply use VMware snapshots. Snapshot the VM. Move/copy the snapshot to the end destination and create a new VM again from snapshot. Depending on your setup, maybe the move/copy is redundant. As I said, I don't really know much about the VMware tools. Change the IP address of the dashboard my.cloudron.example to the new IP manually. i.e via your DNS provider. Start the the new VM. You should be able to visit my.cloudron.example already and login Once you visit, go to Domains -> Sync DNS. This will resync all the DNS entries with the new IP automatically.

That should be it, I guess.

If something goes bad, please let us know here and you can always start up the old instance immediately and continue.

@luckow thanks for your input 🙂

@luckow said in Merging mulitple Cloudrons in to one big new one?:

why?

In part just so everything in one place and so I just have to manage, maintain, update etc one server instead of several servers.

But also because e.g.

I've got an instance of PeerTube on one of the smaller VPSs (it's bridport.tv so makes sense to have it on my.bridport.coop where I've got all the Bridport stuff), but I've realised that it really needs a lot more power than that server has.

I'd also like to give access to some of the apps of got on my.uniteddiversity.coop to all the people on my.bridport.coop - at present this would mean them creating another account and then not having the same credentials for both (although to be fair most of the apps currently on my.bridport.coop aren't LDAP enabled anyway, either because they don't have it - like Discourse - or because it doesn't really suit the use case - public instances of PeerTube, Mastodon, Pixelfed).

I think quite a few of the apps would likely benefit for the increased power the dedicated server would have.

The issues you've highlighted wouldn't be that big an issue for me because I think I'm currently the only person/ name who is on all of them so there aren't two Jane Does (but there would be if I started saying "sign-up over on my.uniteddiversity.coop so I can give you access to our shared x too".

The biggest issue would be getting the handful of people actively using some of the other Cloudrons over onto the One Big Cloudron, but currently the numbers of people I'm talking about would be manageable (but this gets harder as more people start joining the other secondary Cloudrons).

@jdaviescoates said in Server migration tips? Need same ubuntu version? Possible to do without downtime?:

I guess I could try:

add the ip of my old server to my /etc/hosts file on my laptop so I can access it again post DNS changes
boot up my old server and run a backup
Then try the restore email thing linked above by copying the relevant files from one server to the other (not sure how exactly I'd do that, I guess maybe with scp or something)

But I wonder if another option would be to

add the ip of my old server to my /etc/hosts file on my laptop so I can access it again post DNS changes
boot up my old server and run a backup
restore this new backup of the old server into the new server (although I guess this could now get messy - what would happen with emails that have since arrived on the new server).

I'd recommend the first option there to avoid overriding any emails on the new server which aren't on the old server. The first steps would be good because then you'd get a backup again you can follow the steps from the docs at that point to restore emails, essentially merging with the new server afterwards.

Definitely will be interested if @staff has any other recommendations though, will be good to know for future.

@eddowding said in Updating Cloudron to a stable version:

I was migrating servers when I noticed that I'm on 7.2.5, but the latest is 7.3.2.

When moving to the new server, you can install it as ./cloudron-setup --version 7.2.5 . 7.3 was out last week, just ironing out some regressions. We expect to start rolling it out next week.

We'll set up an fresh instance. This is quite simpler.
thanks for help!!!

@humptydumpty Thank you, that has actually worked!