Cloudron Forum

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

I think part of the issue here is that disk size data is actually just collected periodically and not at that instant. This is because du can take a long time complete and so we don't do it too often. The initial use case for the sizes was just pretty graphs. Let me look into if we can somehow add 'Last Updated' into the graphs. @jdaviescoates I have also made sure that logs are not there on our forum anymore.

@nebulon said in App snapshot created but backup progress still pending: The tooltip should be shown in the progressbar in the apps grid. By now the progress status in the app configure view is directly displayed. I guess the UI has changed a bit since this topic was created few years ago. Aha it's shown in the apps grid, not the app page itself. [image: 1692197427840-f809cbef-c66c-45d7-9054-0369eb0ea542-image.png] OK, thats still helpful. Thanks @nebulon.

@smilebasti Possibly because the destination file system does not support hard links. In the Backup -> Configure, there is a checkbox to disable hard links.

Thanks, I have added both to 4.5 roadmap

To know the backup scope, you can sum up all the apps listed there + email data + box data. Then you would have to multiple that by the number of backups which are stored (eg. once every day for 1 week or so) This would be the maximum of storage required using the tarball method. For rsync, it would be much less since it would do incremental backups.

Warning for Backblaze region selection! Especially if EU GDPR laws or just US privacy is a concern. If (like me) you have an account that's been open since before they added the EU-Central (Amsterdam) region - there's no way to set any other region than the one you selected (defaulted) when creating your account. The only way to have a different region with Backblaze is with separate accounts. Wasabi is my other alternative and costs less if you have a lot of ingress or are in the hundreds of Gigabytes bracket, and want region-selection in one account, but Backblaze is the cheapest and trusted option I know up to say half a terabyte. No harm in having an account with both though if you like having options. I like to keep backup object storage away from the main host, although if you were backing up hourly or something else bandwidth heavy then same provider attached storage is pretty safe and usually held in triplicate across hardware.

@girish yep. minio backend

@timmeh Your assessment is correct. If you switched the backups to rsync mode, you can remove the .tar.gz files. They are left overs from your previous backup. Maybe we can add an option to remove the old backup files (of previous configs). But of course, that will require cloudron to remember previous config as well. Also, to be 100% clear, only remove the .tar.gz files. Do not remove any other files in the snapshot directory. The snapshot directory is the "working directory" of the backup system and stores the previous state.

@dsp76 multi part copy is a different API call from multi part upload

@d19dotca That is strange, we will do a bit more testing here (I think atleast one thing to help us narrow this down is you use encrypted backups)