Cloudron Forum

@msbt You can disable automatic backups of nextcloud. Then do a full box backup and then you can restore all the apps on the other server using the box backup. Nextcloud will get installed but won't have any data (as expected) because there is no backup for it. So, far so good. For nextcloud migration, one first needs a "snapshot" of the app on the old server i.e the database dump etc. For this, there is a CLI command called cloudron export --snapshot. This will simply create the database dumps etc. You can then wholesale copy /home/yellowtent/appsdata/{appid} from your old server into the new server using rsync/scp or whatever. Once copied, on the new server, you do cloudron import --in-place. This will then restore nextcloud from the dump files etc (thus, the in place). The catch is that I implemented cloudron export only after I read your post So, it will only be in the next release. But you can always apply https://git.cloudron.io/cloudron/box/-/commit/78752fde7a402821b40eeb75091089470933b23f on the old server. cloudron import has been there for a long time, it's a hidden thing that we use to import large backups into Cloudron. So, I guess you can wait for 6.0.1, which should be out shortly since we have to release it soonish as it had some regressions.

Ok I gotcha myself because anyway I create my own pain so from what I understand to being able to restore Cloudron verify the DNS first than app/data I forgot to authorize my new IP in my Cloudflare API code 9109 is probably related to the fact it was unable to edit the DNS.

@Nicolas One way to avoid this mistake is use getenv('CLOUDRON_MYSQL_USERNAME'), getenv('CLOUDRON_MYSQL_DATABASE') instead of the raw values. This way when you migrate next time, it will pick up the correct database connection values. The full env list for MySQL is at https://cloudron.io/documentation/custom-apps/addons/#mysql

Thanks! The migration went super smooth and fast with the "All In One" plugin.

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

@jdaviescoates We use a service called DNSMadeEasy. They've been acquired by DigiCert. They have a lot of nice features and reasonable prices that allow you grow in small increments. In our "package" a certain number of DNS queries are included. If we exceed the limit, we can buy more queries. Our practice was to use the lowest TTL possible, often using a value of 180. But as customer web traffic grew, we got closer to our limit. To prevent an overage, we increased TTL strategically which reduced queries. Hope this answers your questions.

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.