Cloudron Forum

I will probably have to update https://docs.cloudron.io/backups/#restore-cloudron with more information like @subven has written since it seems this is not very clear.

@girish my initial questions are all resolved now. I'm having some new problems though. Namely that it seems the Cloudron installer is installing Gnome which is making my server enter sleep mode. I disabled it now but I'm confused as to why Gnome is being installed.

Fixed it by taking a new backup, after I reinstated my API Credentails

It worked! My instance and dashboard are back online with all my data restored. I can feel the awesomeness of Cloudron again. In the end the install with ./cloudron-setup --version 5.6.3 seem to have worked on Ubuntu LTS (after a minor version downgrade of NGINX). Now that I've mastered the install/restore I can always go back to Ubuntu 18 if I have any problem. Thank you again for your help.

@shai Yeah, it's tricky Thanks for your this hint, anyway, here's a screenshot for lazy ppl [image: 1607555574126-screenshot-2020-12-10-at-01.05.01.png] [image: 1607555601662-screenshot-2020-12-10-at-01.07.01.png]

For completion sake: https://docs.cloudron.io/backups/#restore-email

@robi The fsmetadata.json is only used in rsync backups. It's used to keep track of empty directories and 'x' bit of files when using rsync mode. We do this because object storage services (like s3, gcs and friends) cannot track this since they are not a filesystem but an object store. This is not needed in tgz because tgz format can encode this information inside the tarball. In essence, fsmetadata.json is usually owned by root. If it's owned by yellowtent, it's probably because maybe you restored the Cloudron in the past or something. The restore logic changes the permission of all files to yellowtent after downloading so that restore can continue as non-root user.

glad to have helped

@d19dotca OK, I have scheduled https://git.cloudron.io/cloudron/box/-/issues/737 for 6.2, let's see.

Hi @girish, I have done a complete reinstallation of the server and now I don't have any issue. I think I've done something wrong while I've completed the restoration informations the first time. Thank's a lot for your support, the subject can be marked as solved.

@girish I don’t think I’ve tampered with anything there, no. Very good, as long as there’s some mechanism to reliably start over I’m happy to do that. Thanks! In the longer term maybe some kind of ”Start over” mechanism doing this same thing can be exposed to the backup page…

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.

@ultraviolet Very clear explanation and a big thanks for the advice in this. I'm going to try this out very soon, if I'll have some time left in the weekend. Never done the part with lvm before, so I want to take the time for it.

@girish wrote: Are you able to open a request [for this]? Done, thanks: https://forum.cloudron.io/topic/4306/provide-ui-support-for-choosing-app-package-version-during-installation

Usually, "Killed" means it ran out of memory when importing. Can you try to restore again and see "dmesg -w" output in parallel to see if that is indeed the case? You can bump the memory limit for the restore logic as indicate here - https://cloudron.io/documentation/troubleshooting/#backups

Yes that is correct, follow the instructions at https://cloudron.io/documentation/backups/#move-cloudron-to-another-server Please not to not destroy the old server until the new works, you can just shut it down temporarily as mentioned in the docs.

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

@scooke This was indeed a bug in our restore UI. I have fixed this for 4.1.5

@CarbonBee Did I understand correctly that the DNS of cloudron A and Cloudron B are different above? If so, the behavior is expected (not saying it is correct or even good). Currently, there is no easy way to easily 'migrate' domains - it is only easy to migrate a Cloudron from one server to another provided that all the DNS remains the same. Can you explain your use case a bit more so we can try to come up with a solution together? I guess you are trying to test your backups? How can we make this work when Cloudron has multiple domains? Once you restore to another server, Cloudron will do the DNS setup of apps automatically and it will end up re-configuring the DNS of the apps to point to this new server.

Thank you @girish for the refund! Much, much appreciated!