How do I test restoring / migrating to a new server?

[d19dotca]

Hello,

I am aware of the documentation for migrating Cloudron to a new server, but am unaware of how to test this while still keeping the old one running temporarily. Maybe I'm missing something or this is a total noob question, but wouldn't I run into licensing issues at that point having effectively two Cloudrons running?

The reason I bring this up... I'm considering moving away from a VPS at one provider and moving to another provider, but since I've never done the migration of Cloudron before I want to ensure I know how to do it first, particularly because there are a dozen client sites hosted on it right now and in particular two client domains that I have no control over their DNS as it is managed by another team for them, so I often have to wait for them to update the IP address before I can finally kill off any old server in favour of the new one.

So what I'm hoping to do is test the process, and once I know it's good, do a final restore point for any new emails that may have arrived in the hours or days between and then cut-over to the new server once and for all. But I have a few concerns such as the automatic DNS stuff... so I have many of my domains on DigitalOcean DNS and Cloudron controls it for me automatically. When I migrate to a new server, will it overwrite all the IP addresses for all of those domains right away, or will it wait for me to do something first? That's the part I'm most worried about in running this test. That and licensing of course.

How could I go about restoring/migrating to a new server while being in compliance with my license for Cloudron and not messing things up for my clients?

Any help would be appreciated.

[girish]

@d19dotca You are correct to worry about the DNS being updated during migration.

In 4.2, we have made a change which allows you to restore from the IP itself and not after setting up the admin domain. Once 4.2 is out, you can migrate like below without turning off your old server:

1. Change the Cloudron DNS backend of your current setup to no-op temporarily.

2. create a backup of Cloudron. This backup you now created has "no-op" as the dns backend.

3. Put back the DNS configuration.

4. Setup cloudron in new VPS and then start the restore with the backup created in step 2.

5. DNS setup will now be skipped when restoring the apps.

6. Now this is the tricky bit. To access dashboard and apps, you have to add a /etc/hosts entry (in your PC/laptop and not on the server) my.domain.com to point to cloudron. You have to add this entry for each of your apps.

In 4.2.1, we will add a flag to the restore UI, where you can skip the DNS operations of all the domains. This will allow you to not have to do steps 1 & 3. This is essentially the task at https://git.cloudron.io/cloudron/box/issues/644

Finally, about the licensing, it won't be a problem since we don't actually check if the same license is duplicated across many installs. We just trust our customers not to do this for evil

Finally, I am open to suggestions on how to make this simpler...

[d19dotca]

@girish That's great to know, thank you! I will wait before migrating then so it's easier to do.

A request for clarification though... when you say "Change the Cloudron DNS backend ... to no-op"... do you mean all domains on the Cloudron or only the main one the Cloudron runs on? I have about 15 domains on my Cloudron, would I need to do that for them all or just the one main one?

[girish]

@d19dotca Mmm, yeah, it has to be done for all the domains. I suggest waiting for the 4.2.1 update, if possible. Otherwise, it seems like a lot of drudgery

[d19dotca]

@girish That's fair and understandable. I will hold out. Hoping it can be released in about a month's time or so, that'd be ideal.

As to the comment from earlier where you were open to suggestions on how to make this task simpler... I guess if it were me, I'd envision a sort of bulk method. So on the restore screen after deploying the new Cloudron, it'd be great if it walked you through the process not only pointing to where the backup file is but also asking for these options on it automatically, such as whether all domains should have an updated IP address (that can then envoke the no-op maybe automatically without needing to do that before on the backup step?), and if so which domains from the backup (I suppose it'd need to read it a bit first to know which domains exist) need to change and which ones need to stay the same, etc.

And maybe worthwhile to add an info dialogue about testing where a user would need to edit their local hosts file on their computer to reach out to the new server if the IP address hasn't been changed and this is a test. I mean probably most people know that but couldn't hurt to have that to avoid support cases you may get down the road. Being in tech support myself, I always try to think about how I can prevent emails & calls. haha

If I was thinking about the far future... I would also see if there's a way to essentially just do-away with backups for migration purposes, so I would envision a situation where I could deploy a new Cloudron and simply tell it to migrate from my current Cloudron server and give it the credentials it needs, where it can then copy the data on the fly and that could also then add to the possible feature of asking which domains to migrate or change IP of, etc before it actually does anything. This is probably far fetched and not easy to do, but just what I would see as an ideal because it'd cut out a lot of the "middleman" steps if you will.

[vjvanjungg]

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