Cloudron Forum

Hello @davejgreen @davejgreen said: Is migration of users and email boxes only possible by using the "looking to restore" button for restoring full Cloudron backups? Yes. @davejgreen said: And is that button only available when you first install Cloudron? Yes. @davejgreen said: We have a second server up and running with a newer version of Ubuntu and Cloudron and were thinking about importing each app individually (after backing it up from the old Cloudron onto a backup site hosted on the new Cloudron), but I'm not sure if there's a way to import the users and email boxes? If not, I guess this approach will not work for us, we'd have to use a third site for a full backup. This is not recommended. The new server should be installed with the exact Cloudron version you are currently using. Otherwise you wont even be able to restore the system backup. @davejgreen said: Do we need to purchase another one for the new Cloudron instance? No. Once migrated simply write a mail to support@cloudron.io and inform us and we will switch the licence to the new server. To minimize downtime use the dry-run backup restore option: https://docs.cloudron.io/backups#dry-run-restore This way, you can restore the whole system, without changing DNS records and can validate each app / step manually. The old server stays up and running, serving all the apps, mail, chat etc. After a review of the migration, when ready to switch permanently, go to Domains view and click Sync DNS.

@joseph thanks a lot for your prompt answer. I migrated and after 24 hours I saw this problem. So, right now what other I did: I enabled LAMP recovery mode I disabled LAMP recovery mode I rebooted whole VPS (not only LAMP app) Problem is solved after those further steps. Migration script could be improved to update cron job container ID if any cron job configured in a specific app.

@robi said: @girish Can a migrations check be added to run until none remain, which hopefully evades the stuck condition too? this would actually be a good addition to the CLI toolset... @girish @james

There is no look-into-it. There is only do-it.

Perfect. Everything works as intended. Thank you, @girish, and have a great beginning of your week

@Shai You would need to edit your local computers /etc/hosts file and add in the old IP address of the previous Cloudron install for the domain name that you’d type in the browser bar. Then you should be able to use the hostname to still access the older Cloudron server.

oh that is true, I forgot about Cloudron 7 not being supported/tested on Ubuntu 24. So then yes you have to first install Ubuntu 22, then restore Cloudron, then update Cloudron, then follow the guide at https://docs.cloudron.io/guides/upgrade-ubuntu-24/

Dedicated servers from OVH are well priced too, worth it in my opinion but it likely depends greatly by region. I’m in Canada and there’s only so many local options, with OVH servers being the cheapest by far but still very powerful. I’d only recommend OVH if you’re a pretty decent sysadmin though because their support is not the quickest.

Indeed they're back when they login with OIDC, thanks for the tips. This ticket can be closed I think.

@necrevistonnezr I guess you mean the rsync binary. Sure that will work "locally" but the real benefit of rsync (protocol) comes from having a server component. This server component will not be used with nfs mounts (the topic of this thread). If you want to use rsync just locally, there are also other tools you can use. I don't have any context more than that one sentence though I was just replying in passing.

@javiergutzp have you seen https://docs.cloudron.io/backups/#move-cloudron-to-another-server ?

@svtx life of a teenager

Ok, it seemed running the /home/yellowtent/box/setup/start.sh to trigger the migration after restoring the database (because of the ERROR 1046 (3D000) at line 22: No database selected i needed to add these two lines to the dump file: CREATE DATABASE box; USE box; Then it was able to backup the database and run the migration.

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.