Cloudron Forum

Thank you @james I could not get it to work. After several attempts, I ultimately deleted the backup files and started with a new configuration. As advised, I also set the retention period to "unlimited" (it was previously set to two days). Everything is working well now, and I was able to back up and clone the app without any issues. Thanks again, and keep up the good work!

Cloudron 9 has pretty much the same flow here. Maybe we have to revisit what the main app cloning use-case is, to figure out a better flow there.

Hello @Shai The second level domain, also known as @ in most DNS providers e.g cloudron.io has a different propagation time then third level domains aka. example.cloudron.io. This could take up to 24 hours or more, depending on the hosters default TTL for the domain or what you've set. Might even be resolved now when you retry it after 7 hours.

@Beardmancer said in Restore one app's backup to another existing app?: I'm curious to know what plugin you prefer? I'll put it on my list for next time. You found it then. Only other I've used is Updraft Plus export -> import.

The process is described at https://docs.cloudron.io/backups/#clone-app

This is not possible, no. The structure of data of both the apps are quite different. Also, when you backup Cloudron apps, the code is not part of the backup. LAMP app is sort of a special case here since the code is part of the "data" and part of backup . You should be able to migrate it manually though. Import database and copy over the needed files.

There's two DSN: CIVICRM_UF_DSN and right below the above screenshot CIVICRM_DSN . Both have to be updated after a clone.

@girish Okay, that is super easy, thank you very much!

I will mark this as solved for now but I suspect this will come back some day.

@marcusquinn Yeah, I have another idea once differential backups become available.. Have the template App be backed up locally, while others remotely, keep things fast. Let's see which we get first.

Just to follow up, here's a sample of normal backups followed by a Cloudron upgrade, which itself triggered another backup run, and the corresponding relevant network and disk graphs: [image: Network Traffic.png] [image: Disk I_O.png] All in all, it's definitely fast-er but not insanely performant. CPU utilization vs load hints that it may in fact be down to inefficient utilization of cores to some extent, but there is definitely a fair bit more bottleneck coming from the network still. [image: CPU Utilization.png] [image: CPU Load.png] Nothing earth-shattering either way, and gains were more mild than I would have guessed, but all in all, not a bad outcome.

I think git link / image registry link is the most flexible. Essentially it could run the code that Cloudron CLI runs anyway.