Moving entire Cloudron from Linode to Digital Ocean
-
My current Linode server using Cloudron is based on Ubuntu 20.04. They do not offer 24.04 yet, but Digital Ocean does. I created a droplet at DO with Cloudron/Ubuntu 24.04 and am having trouble getting it running, much less restore my backups.
My goal is to ultimately use the same domain (lets just call it example.com), but the recommended way of using the etc/hosts file on Windows to fake the DNS and doing a dry run is not working for me, for example:
123.123.12.12 my.example.com
But I can only access it directly from the IP in the browser.I tried setting it up with an alternative domain instead. Let's call it exampledomain.com. I created an A record pointing my to the IP. The Cloudron setup just sits there waiting for the DNS propagation when a DNS check reveals it is propagated.
I noticed there is a restore option, so I click it. I downloaded the last backup config, which was saved to a volume named CloudronVolume on the Linode server. I uploaded the backup tar files to the new volume on the DO server. I try to restore the config and it tells me:
"Access denied. Create /mnt/CloudronVolume/snapshot and run "chown yellowtent:yellowtent /mnt/CloudronVolume" on the server"My volume on DO does not have the same name. Does it need to? I gave the entire volume permission, so I'm not sure where to go from here. Any help would be greatly appreciated.
EDIT:
I did have to change the name of the directory for the volume because Cloudron is looking for that specific configuration. -
After adding a volume to my old Linode Cloudron server, setting up backups to go there and restoring to the new DO server my old Linode Cloudron is now freaking out. I tried moving an app's data to the volume and it throws the error:
An error occurred during the data migration operation:
Addons Error: Error setting up postgresql. Status code: 500 message: connect ECONNREFUSED ::1:5432I can't even start apps on it:
FileSystem Error: Could not create nginx config directory: ENOSPC: no space left on device, mkdir '/home/yellowtent/platformdata/nginx/applications/acc4c4d3-9bed-42a5-b440-946c4dd86b99'I don't understand why something like the Postgresql setup or IPV6 changed on my old Cloudron server. What could have caused the sudden change and how do I fix it?
-
@nebulon I'm not sure how best to reduce that disk space. I tried removing onlyoffice (which is stopped currently) but it said "Addons Error: Error tearing down postgresql. Status code: 500 message: connect ECONNREFUSED ::1:5432"
I'm looking at the backups through the command line and also the directory sizes:
I don't want to delete something and make the problem worse. -
I think the best approach at this point is to start over with the whole server restore and ensure that the new server has enough space.
The overlay filesystems are virtual disks from docker and the size there is not correct so that can be ignored. But / being on max capacity is the main issue.
To cause less downtime, I would suggest to reactivate the old server and first then try to get a successful dry-run restore on the target server: https://docs.cloudron.io/backups/#dry-run
-
It's my old server that is having the problem. I tried deleting some of the larger and older backups, freeing up several GB of space. I retried the config but get this error:
I don't understand why my old server would be the one with the database issue. I only added a volume and configured backups to go there because I was running out of space. I moved those backups to my new server and the new one seems to work fine right now (I've been setting the DNS manually in my hosts file and enabling/disabling records in there to bounce back and forth between the old and new server - flushing the DNS on my Windows workstation as well and verifying the IP in the browser inspect>network tab). -
So the postgres addon got corrupted due to the previous disk space issue. Sometimes database systems are not very forgiving in such cases. First make sure to have some disk space available and then follow the steps at https://docs.cloudron.io/troubleshooting/#corrupt-addon for the postgres addon service.
-
OK, instead of increasing the disk space or trying to hunt down files to delete, I decided to set up the new server on a temporary domain to test everything out (and might just migrate to that domain permanently).
One issue I ran into was Cloudron wouldn't recognize the DNS in the domain settings when changing the dashboard domain. Since I set up the server with IPv6 I had to enter both the IPv4 and 6 addresses into the DNS config for my domain (I'm doing it manually since Godaddy and NameCheap won't let you use their API unless you have a LOT of domains and/or pay a premium). I'll have to do that for every app individually.
I'll have to think ahead as far as disk space is concerned so I don't run into the Postgresql problem again.
Thanks for your help! -
-