Cloudron migration to new server: amazing!!!
-
@imc67 Awesome, definitely interested to follow your experience with Netcup.
I got to the end of their checkout and just hesitated from searching around on their support and changed direction to Hetzner last minute and very happy with that.
Netcup certainly is the highest specs and features for bucks I could see but I just have so many users I fell for the bigger name of Hetzner and really need a decent Teams/Members setup to have various Sys Admins per VM.
Keeping an open mind though so do update as you go.
Agreed - Cloudron is a revelation - the dedication and community makes all the difference when you find system designers that just get it and focus on the sum of a thousand user needs details.
Great story!
@marcusquinn I'm using Netcup
And did a very easy migrate from Linode to Netcup as @imc67 reports.I'm fine with NetCup. Only comments I would make is :
- their deployment on order is not instantaneous : they do a check for new customers and even after, it can take a little while. Quick enough, but not 100% automated. So don't order a server at 3am and expect it to be live at 3:15am.
- not immediately clear from site/emails, but their deployed servers are all debian. No choice on signup. BUT you can use console to wipe it with another OS of your choice.
- they're German and the forum is mostly German, minimal English content, although if you post a question, some kind soul will usually reply in English. Just not mainstream content. I use a translation utility )already) so I highlight and get translations, but. bit long-winded
Generally I'm happy to recommend Netcup
-
@marcusquinn I'm using Netcup
And did a very easy migrate from Linode to Netcup as @imc67 reports.I'm fine with NetCup. Only comments I would make is :
- their deployment on order is not instantaneous : they do a check for new customers and even after, it can take a little while. Quick enough, but not 100% automated. So don't order a server at 3am and expect it to be live at 3:15am.
- not immediately clear from site/emails, but their deployed servers are all debian. No choice on signup. BUT you can use console to wipe it with another OS of your choice.
- they're German and the forum is mostly German, minimal English content, although if you post a question, some kind soul will usually reply in English. Just not mainstream content. I use a translation utility )already) so I highlight and get translations, but. bit long-winded
Generally I'm happy to recommend Netcup
@timconsidine said in Cloudron migration to new server: amazing!!!:
Generally I'm happy to recommend Netcup
I've got a little test server with them too, just to try them out, but I won't be using them again. The Hetzner experience is orders of magnitude better for hardly any more money. The thing I most disliked about Netcup is that they advertise hourly pricing but then you have to pay 6 months upfront. The whole thing is a bit clunky compared to the great UX on Hetzner.
-
@timconsidine said in Cloudron migration to new server: amazing!!!:
Generally I'm happy to recommend Netcup
I've got a little test server with them too, just to try them out, but I won't be using them again. The Hetzner experience is orders of magnitude better for hardly any more money. The thing I most disliked about Netcup is that they advertise hourly pricing but then you have to pay 6 months upfront. The whole thing is a bit clunky compared to the great UX on Hetzner.
@jdaviescoates I have one small Hetzner instance, but I doubt use it much, so not familiar.
Initially I didn't like the 6 months billing on small servers (nb only on small ones), but then I realised it saved me a lot of bank reconciliation work and invoice tracking. So now I am ok with it.
-
I'm preparing for the move. Cloudron version has to be the same as mentioned in the guide.
What about the Ubuntu?
Currently, I'm on 18.04. Can I move directly to Ubuntu 20.04 LTS? -
@asnd said in Cloudron migration to new server: amazing!!!:
Currently, I'm on 18.04. Can I move directly to Ubuntu 20.04 LTS?
yes, or even directly to 22.04.
@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 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.
-
You migrated without downtime! You mean there was no need to change server IPs until the migration was complete?
I'm stacking here
-
You migrated without downtime! You mean there was no need to change server IPs until the migration was complete?
I'm stacking here
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 Ahas DNS records and is serving a Webpage,New Server Bstarts, changes DNS records.
Then, what can happen?
DNS Cache and DNS delegation timing issue.
People may get theOld Server Aserved 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
-
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 Ahas DNS records and is serving a Webpage,New Server Bstarts, changes DNS records.
Then, what can happen?
DNS Cache and DNS delegation timing issue.
People may get theOld Server Aserved 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@BrutalBirdie what I've done in the past is this:
- take full back-up of
Old-Server A - dry-run import into
New Server B - Edit my
/etc/hostsfile so that even though I've not updated DNS yet my laptop thinks everything is atNew Server Band test if everything is working. - Presuming everything is working (and so far, it always have been as best as I could notice), update/ sync the DNS to
New Server Band - Power down
Old-Server A
I guess some people might be directed to
Old-Server Awhile 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
- take full back-up of
-
I haven't done this, so bear with me. What if we had nginx redirect traffic on
Old-Server Aafter confirmingNew Server Bis 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.
-
I haven't done this, so bear with me. What if we had nginx redirect traffic on
Old-Server Aafter confirmingNew Server Bis 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.
@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 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?)
@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! -
@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.
-
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 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.
@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?
-
@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?
@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.
-
@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.
