Cloudron Forum

@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 Ah okay, that makes sense on the tgz part. Unfortunately I haven't had much success at all in any quicker times (in fact it's often closer to double the time than tgz, taking between 1-2 hours) when using rsync in my tests for OVH Object Storage. But maybe I just haven't found that 'sweet spot' yet. I'll keep testing. Thanks Girish.

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

@timmeh let us know if @NCKNE's workaround works or not.

@girish thanks for the info!

The issue here was that @minhbaop imported a box backup (i.e a backup with box_ prefix) into an app. Cloudron clearly has a bug that importing an unknown format makes it put the app in some indeterminate state. We will get this fixed in some future release.

@beenmeckel said in Is data stored in a Custom Data Directory included in Cloudron backups?: So I feel fine about getting set up with Nextcloud on a server I'm renting from Hertzner. I'm just stressing about how much of the time it is likely to crash or go wrong I've got all my Cloudron stuff running on Hetzner and so far nothing had ever crashed nor gone wrong. Also the data on their volumes is triple replicated too. But yes, also looking into how to backup me backups elsewhere too...

@d19dotca said in Backup to ext4 disk mount, using rsync, fails on first full backup but succeeds in all future ones.: Setup a new public cloud instance at OVH Create a block storage disk and attach it to the public instance created in step 1 Format the block storage disk and mount it according to this article: https://docs.ovh.com/ca/en/public-cloud/create_and_configure_an_additional_disk_on_an_instance/#using-linux Install and restore Cloudron from old server via DigitalOcean Spaces latest Cloudron backup ID Once Cloudron is running off latest backup, change backup configuration to file system using rsync non-encrypted with hardlinks, then initiate the first backup to the new location. This is where it failed for me. Hey, I know this is quite old, but I just had this issue too (v7.4.3), and I think I know what the issue is. So the Backup type is 'Filesystem (Mountpoint). Cloudron tries to hardlink between one device (primary boot, or one particular mountpoint) and the other (another mountpoint). Hardlinking isn't supported between devices sometimes though, so the hardlink fails. This issue seems to occur even with encryption though. Just a heads up in case anybody runs into this issue. Solution in the main time is to just not use hardlinks.

@robi only the retention policy - https://docs.cloudron.io/backups/#retention-policy

Maybe one specific file name/path which just happens to be produced by rainloop causes CIFS to fail?

@girish Unfortunately I have a different issue when running non-encrypted, which is posted here: https://forum.cloudron.io/topic/2270/backup-issue-in-rsync-non-encrypted-filesystem-type-never-moves-past-status-of-removing-directory-for-one-particular-app

Yes, I did remount the shares.

@NCKNE Which app did you use the sieve filters in. Often, the filter in one app is not visible in another! The sieve filters are located at /home/yellowtent/boxdata/mail/vmail/<mailbox>/sieve. Can you check if they are there on the filesystem atleast?