Cloudron Forum

@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.

@girish Here's what I found: https://www.qwant.com/?q=long+run+copies+via+cp+causing+oom+memory Various OOM workarounds: https://github.com/rfjakob/earlyoom https://github.com/hakavlad/nohang https://github.com/facebookincubator/oomd https://gitlab.freedesktop.org/hadess/low-memory-monitor/ https://github.com/endlessm/eos-boot-helper/tree/master/psi-monitor Understanding OOM Score adjustment: https://last9.io/blog/understanding-the-linux-oom-killer/ Possible LowFree issue: https://bugzilla.redhat.com/show_bug.cgi?id=536734 Parallel vs sequential copy: https://askubuntu.com/questions/1471139/fuse-zip-using-cp-reported-running-out-of-virtual-memory And lastly, since you use stdio as output, perhaps it fills that up somehow. If it were redirected to disk it might be different. That might also enable resuming a failed restore.

@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.

@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