Cloudron Forum

@tshirt-chihuahu It should rarely happen (but it happens). I will put the workaround in the package itself. It seems that workaround works quite reliably for a couple of years now.

@echokos Right as @NCKNE suggested, you can enable the dynamic dns option under Domains view before migration and take a backup after you enabled it. With that the DNS records will be automatically updated post migration. After migration, you can turn off that option since the IP won't change anyways.

The backups also contain the sql dump and all the data files nicely structured, if required.

@girish said in Migrating the license:

If the domain name changes, we will have to do this by hand on our side.

nope, the main domain didn't change 😉

@girish said in Migrating the license:

we might have some license file that you can export/import

if you are happy with this kind of license and user are happy, why not keeping it that way 😉

Thank for your explanation and replied.

@subven said in Cloudron migration to new server: amazing!!!:

before it is tested and officially supported

ah indeed, I missed that 22.04 is not yet supported. I rephrase my sentence into "you can directly upgrade to the latest supported OS".

I’m having some similar thoughts about restoring / migrating Cloudron as @d19dotca .

So it is possible to set up Cloudron on different primary domains (or IPs) but still keep the same subscription.

The use-case I’m aiming for is just to serve the code closer to the readers / users. Will the apps on one Cloudron appear on the other Cloudron? @girish

Thank you @girish for the refund!
Much, much appreciated!

just an update, the syntax for the psql variables has changed, so the conversion script looks like this:

sudo -u www-data php occ db:convert-type \ --password ${CLOUDRON_POSTGRESQL_PASSWORD} \ --clear-schema --all-apps pgsql \ ${CLOUDRON_POSTGRESQL_USERNAME} \ ${CLOUDRON_POSTGRESQL_HOST} \ ${CLOUDRON_POSTGRESQL_DATABASE}

you must run this from within the nextcloud container.

also, I had some dificulties with the mysql migration, the temp mariadb/mysql docker container should match the same type and version as the source. In my case src had mariadb 10.5, so the container from the code sample above (mariadb 10.1) throw some strange errors while importing the sql dump.