@luckow thanks for your input 🙂

@luckow said in Merging mulitple Cloudrons in to one big new one?:

why?

In part just so everything in one place and so I just have to manage, maintain, update etc one server instead of several servers.

But also because e.g.

I've got an instance of PeerTube on one of the smaller VPSs (it's bridport.tv so makes sense to have it on my.bridport.coop where I've got all the Bridport stuff), but I've realised that it really needs a lot more power than that server has.

I'd also like to give access to some of the apps of got on my.uniteddiversity.coop to all the people on my.bridport.coop - at present this would mean them creating another account and then not having the same credentials for both (although to be fair most of the apps currently on my.bridport.coop aren't LDAP enabled anyway, either because they don't have it - like Discourse - or because it doesn't really suit the use case - public instances of PeerTube, Mastodon, Pixelfed).

I think quite a few of the apps would likely benefit for the increased power the dedicated server would have.

The issues you've highlighted wouldn't be that big an issue for me because I think I'm currently the only person/ name who is on all of them so there aren't two Jane Does (but there would be if I started saying "sign-up over on my.uniteddiversity.coop so I can give you access to our shared x too".

The biggest issue would be getting the handful of people actively using some of the other Cloudrons over onto the One Big Cloudron, but currently the numbers of people I'm talking about would be manageable (but this gets harder as more people start joining the other secondary Cloudrons).

@jdaviescoates said in Server migration tips? Need same ubuntu version? Possible to do without downtime?:

I guess I could try:

add the ip of my old server to my /etc/hosts file on my laptop so I can access it again post DNS changes
boot up my old server and run a backup
Then try the restore email thing linked above by copying the relevant files from one server to the other (not sure how exactly I'd do that, I guess maybe with scp or something)

But I wonder if another option would be to

add the ip of my old server to my /etc/hosts file on my laptop so I can access it again post DNS changes
boot up my old server and run a backup
restore this new backup of the old server into the new server (although I guess this could now get messy - what would happen with emails that have since arrived on the new server).

I'd recommend the first option there to avoid overriding any emails on the new server which aren't on the old server. The first steps would be good because then you'd get a backup again you can follow the steps from the docs at that point to restore emails, essentially merging with the new server afterwards.

Definitely will be interested if @staff has any other recommendations though, will be good to know for future.

@eddowding said in Updating Cloudron to a stable version:

I was migrating servers when I noticed that I'm on 7.2.5, but the latest is 7.3.2.

When moving to the new server, you can install it as ./cloudron-setup --version 7.2.5 . 7.3 was out last week, just ironing out some regressions. We expect to start rolling it out next week.

yes, see e.g.

https://docs.joinmastodon.org/user/moving/

Or this short guide published yesterday

https://codingitwrong.com/2022/10/10/migrating-a-mastodon-account.html

@humptydumpty Thank you, that has actually worked!

@samaneha Which app do you want to migrate? The backups have the database dump and the data files. What else do you need to migrate?

Backup/Restore process is actually better than a disk clone as it allows for one to remove the older cruft, upgrade the OS, switch hardware, etc.. yet all the Apps and Cloudron instance settings work as originally backed up.

Very handy and a seriously difficult thing to do, hence the many disk imaging and other schemes to try and replicate a nicely configured system, which quickly become out of date, being so static.

Cloudron FTW! 😄

@girish I think it was ultimately a disk space issue - I restarted unbound and that seemed to do the trick. I have to move servers again because of a Vultr restriction (block storage not in the zone I had the VM in) that's unrelated to Cloudron so I'll see what happens. Thanks guys!

@LeeW Thanks for trying it and letting us know!

thanks for proving my point that one cannot have a discussion with you 🙂

@timconsidine said in Moving Cloudron to new server : stop apps?:

that I didn't set the PTR record in the new VPS provider until I started the migration

I ran into exactly this problem the last time as well 😄

@atridad yeah, I just bumped the internal default for data directory migration to be 1GB . I tested with ~500GB now and it's all good.

@girish
Thanks for the info and all the work (support) you have done for me Girish 👍👍

@shai you have to build a custom app, please see this guide https://docs.cloudron.io/guides/multiple-databases-lamp/

@brutalbirdie Thank you, I'll give that a shot!

Thanks guys! Yeah it's a weird issue for sure and likely very rare, so it's probably not a big deal. If it helps for reproducing it, here's a few notes:

27 apps installed at the time of backup/restore Backup & Restore used tgz format with OVH Object Storage in BHS region Backup from a LunaNode m.8 model in Toronto region Restored onto OVH b2-7 model (though since upgraded to b2-15) in BHS3 region LunaNode instance (source) was running Ubuntu 18.04 at backup time, and OVH instance (target) was running Ubuntu 20.04 at the time of restore. When I restored, I very nearly ran out of disk space on the included disk, leaving only ~ 1.5 GB of space remaining. When restoring initially, it failed to restore because of the issue I reported earlier, though doubtful this is a root cause. Immediately moved the boxdata to external disk afterwards though, so plenty of space free soon after the restore was done once I moved boxdata off (20 GB in emails alone so it takes up a lot of space).

Hopefully those notes above help in some small way. No worries though if you can't reproduce it, I imagine it's a very rare scenario and could have even been completely unique to me somehow. Hopefully others can chime in though if they experienced anything similar where cron wouldn't run at all (whether a restore involved or not, as I'm still not 100% certain it had to do with the restore though I presume it did).

One other note, the .sql file originally failed to upload due to the dump having the following line:

Create SCHEMA public;

I commented that out and the import ran fine. I'm guessing there is a command to dump the Postgres DB without a create statement but someone smarter than me probably knows it. I haven't used Postgres a day in my life until yesterday so I'm still getting to know it. I have only used MySQL, Maria and MS SQL and all of those have an option to dump without the create statement, but I figured it was just easier to comment that line out of the SQL file instead of looking up the command and doing a new dump.

@girish ah alright, was moving some LAMP 7.2 and 7.3 to 7.4., clone does not work in that scenario 😉

Depending on the provider, they already zero things out. For example, DO does this. Of course, you have to trust your provider.

@subven Thank you! I had not seen those docs 😯

It turned out that the Docker image of Mattermost used PostgreSQL, whereas on Cloudron if I'm not mistaken MySQL is used.

I tried converting migrating the PostgreSQL database to MySQL but it was a bit of a headache, so I have gone down the conventional route of using Mattermost's bulk export/import.

@girish I successfully migrated my Cloudron from one server to another. I followed your directions and updated Cloudron to v 6.0.0 before making my final backup of the old server.

Thank you.

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

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