@ultraviolet I had similiar issues and here is what helped me. As a summary: Ensure that the local mount point is owned by yellowtent:yellowtent Before creating the fstab entry, please try to mount on the command line. sudo sshfs -o port=23 -o allow_other,default_permissions,uid=1001,gid=1001,IdentityFile=/home/yellowtent/.ssh/id_rsa user@host /backup_sshfs/ I have used sudo because I am assuming that you are not logged in as user yellowtent.

@girish Yes, it is, I switched 3. also to every 12 hours + 1 week, and also that one is backing up once a day. I'll ping you.

@makemrproper said in Disaster recovery - Restoring a backup: 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. Import app 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?

If you have a floating IP (in DigitalOcean lingo), elastic IP (AWS) or equivalent, you can make Cloudron use the floating IP (Network -> Interface -> Enter the floating IP). Then you can restore Cloudron to another server, and then when restoring is done, you can switch the floating IP to this new server.

@scooke said in App or Full backup fails with reference to 'layout'?: If it hangs again should I just email you directly with the logs? Yes!

Quick update: I just manually ran another system-wide backup and it was successful, so it seems it may have just been a one-off and probably won't happen again anytime soon, was likely just coincidental I was making a bunch of changes to it yesterday considering other system backups proceeded without issue since the time I made those changes. But I'd love to get a second-set of eyes for insight into if this is something I should fix to prevent it in the future or just a one-off type of thing that can safely be ignored.

@thibaud Are you able to generate credentials for me to test your minio instance? Maybe just create a test bucket for us. Just send them to support@cloudron.io. I just tried to setup backups to a minio installed on Cloudron and that works fine.

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

@girish They are unusual I would say, yes. It's a file that is being updated on a daily basis so it has a file history of 30 different versions in NextCloud. They are .db.crypt12 files, which is a database backup of WhatsApp about 120MB in size.

Can you check with docker ps -a if that container is in fact there and then restart it with docker restart <containerid>?

@girish Ah interesting, yes that definitely seems like an OVH-specific issue then. At least they're heading in the right direction I guess towards the end of this year. Thanks for shedding some light on that one for me.

@girish Good to know. That option being configurable in the future would be great too, rather than just increasing it in code.

@Mallewax I think this depends on the webmail app, more than on the platform itself. Not totally sure though, I am not particularly familiar with the inner workings of the email protocols

Good morning, that sounds acceptable for me. Have a nice day!

correct in your case this should not be any issue as this is mounted like a regular ext4 which supports hardlinks just fine.

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.

@girish Yeah I was starting to think that as well. I'll give it a shot and report back. Thanks!

@d19dotca Just wanted to leave a note that there are some discrepancies in code. I will get it sorted out and give a concrete reply - https://git.cloudron.io/cloudron/box/-/issues/692

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

@stantropics One thing worth looking into is https://cloudron.io/documentation/apps/nextcloud/#managing-deleted-files (especially, those deleted nextcloud files hang around indefinitely).