Cloudron migration to new server: amazing!!!

[subven]

@fbartels installing Cloudron on a clean 22.04 failed for me today. Setup script crashed because of unbound unable to start. Image is from Contabo. I switched to 20.04 because I do not see the benefit of using 22.04 before it is tested and officially supported.

[fbartels]

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

[RedzzDragon]

You migrated without downtime! You mean there was no need to change server IPs until the migration was complete?

I'm stacking here

[BrutalBirdie]

To add a new message to a long-dormant conversation.
Synonym: necropost

@RedzzDragon yes you can do that. BUT! Big ing but, this only works flawlessly when your migration does not require data synchronization.

Data . . . What? Can you explain please?

When the Old-Server A has DNS records and is serving a Webpage, New Server B starts, changes DNS records.
Then, what can happen?
DNS Cache and DNS delegation timing issue.
People may get the Old Server A served because the DNS cache still has the old IP.
This way you may end up with lost data. And when you then think, oh I can just migrate the old server AGAIN to the new one.
Welllll others users did new inputs on the new server? So what now?

If you only serve static content which is managed by you alone, easy-peasy.
Dynamic content with user input. eehhhhh

[jdaviescoates]

@BrutalBirdie what I've done in the past is this:

1. take full back-up of Old-Server A
2. dry-run import into New Server B
3. Edit my /etc/hosts file so that even though I've not updated DNS yet my laptop thinks everything is at New Server B and test if everything is working.
4. Presuming everything is working (and so far, it always have been as best as I could notice), update/ sync the DNS to New Server B and
5. Power down Old-Server A

I guess some people might be directed to Old-Server A while DNS changes propagate - but they wont be able to actually do anything/ enter any data as that server isn't running.

So kinda sorta no downtime plus no worries about data synchronization

The reality is that in my particular instance I don't have many users so it's the data issue and the possibility some people won't be able to do anything until their DNS updates isn't a huge deal

[humptydumpty]

I haven't done this, so bear with me. What if we had nginx redirect traffic on Old-Server A after confirming New Server B is set up properly via the dry run method?

In addition, we can lower the TTL days before the migration for the old server too so that when we update the DNS, it'll propagate faster.

[jdaviescoates]

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

I haven't done this, so bear with me. What if we had nginx redirect traffic on Old-Server A after confirming New Server B is set up properly via the dry run method?

That sounds like a good idea to me, but I wouldn't know how to do it. Guess I could search and get guidance from AI though

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

In addition, we can lower the TTL days before the migration for the old server too so that when we update the DNS, it'll propagate faster.

Yeah, whenever manually adding DNS stuff I always try to remember to have TTL as low as possible. I've never really understood why anyone would ever want high TTL (and now I'm wondering what Cloudron sets it as by default when setting up DNS records?)

[humptydumpty]

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

I've never really understood why anyone would ever want high TTL

For caching which lowers your latency and speeds up your site. It's non-noticeable in most cases, but I've been down that rabbit hole trying to optimize my WP sites Never again!

[crazybrad]

@jdaviescoates If you pay for DNS queries, increasing TTL reduces your cost (or keeps you below the threshold where additional payment required). But setting a TTL of 3600 (1hour) when you are not planning on making changes vs. 300 (5 min) when you are going to make changes is sensible. But I've seen some ridiculous 86400 (1 day) values too.

[d19dotca]

Funny enough for seeing this post recently… I’ll be migrating Cloudron to a new dedicated server from another next week as my rental agreement is up soon so it’s time to “upgrade” servers again.

I’ve usually had a pretty solid workflow for the Cloudron migrations, I did a lot of them over the years up until a bit ago, so I’ll be sure to document my experience and return here with any suggestions or tips. Hopefully they can help anyone else who has to do this exercise with an actively used Cloudron server that must keep downtime to an absolute minimum (if not near-zero).

[jdaviescoates]

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

pay for DNS queries

I didn't even realise that was a thing. Who charges for such things?

[d19dotca]

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

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

pay for DNS queries

I didn't even realise that was a thing. Who charges for such things?

Amazon AWS is one that charges. They charge per-million queries usually. It’s usually really cheap to be fair (like 60 cents per million) but can add up for businesses who generate a ton of queries. Also those typically don’t start until after a free layer of a billion queries or something like that. Haha.

https://aws.amazon.com/route53/pricing/

[crazybrad]

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