@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 Thank you for re-opening that. In my particular use-case, I was trying to follow the steps from my VPS provider for extending my disk size (it isn't quite as straightforward as DigitalOcean for example where I can just hit a button and it's done), it's a bit more "old school" with lots of stuff to do in their UI and also at the command line level, but it's certainly do-able. So I wanted to test this out on a new VPS to make sure Cloudron would see the new disk size, etc and walk through the full process that I intended to do at a scheduled time later on where I'd then make a floating IP switch and be done with it. However this test wasn't really completed because of the "Waiting on DNS" stuff in the restore process.
So one thing I could do as a workaround is actually create a VM snapshot of my current one, then use that on a new volume and then make it the boot disk of a new VPS. However, this takes a long time to do and I'd be worried what I'd do for emails and such that arrive at the old Cloudron until the time I've switched it all over to the new one, because there'd be an inconsistency then after an hour or so has passed until I can get it all setup and done.
It's okay though, we can take up that last part in the other forum post I made for it, but that was just my use-case and reason why I was expecting not to have to wait for DNS to propagate so I could actually complete my test and get into the dashboard and verify it sees the extended disk size, etc.
@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…
As far as I can tell, as an operator I need to keep track of what was the UUID of the container I deleted, in order to restore it.
Sorry for much confusion. Let me first try to explain how to import.
Finding the App's ID
Each Cloudron app has a unique ID. This is separate from the internal docker container id and you should never have to use any docker container id related stuff,
Now the question is how to figure out this unique ID of an uninstalled app. One way is to look into the event log. Select the uninstalled apps as the filter:
Then when you click on the event, you will see the app id:
Locating the backup
The backups are stored with the filename timestamp/app_<id>_v<packageversion>.tar.gz (for tgz backups) or timestamp/app_<id>_v<packageversion> (for rsync backups). The package version is needed in the case where you have a old version of an app and you want to restore to that old version.
Install an empty app
We have to next install the app for appstore. For this go to the appstore and install the app.
Notice the package version in the URL bar. Above, I am trying to install package v2.0.5 of wordpress. This version must match the version in the backup we located above.
Finally, go to app -> configure -> import
OK, all that said, what can be improved here. I see that the way to locate an uninstalled app's id is missing from the docs. I can add that part. Is there anything else we can fix on our side? Maybe we can keep the app's fqdn -> uuid listing alongside the backups?
@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.