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