@yusf Are backups failing by any chance. I wonder why there are multiple backups in a day. How often do you create backups? If it's one week backups from 17th Npv are expected. the ones which are slightly older are probably preserved for various reasons. One thing you can do is Backups -> Cleanup backup. Then in the same view, click on logs and it will tell you why each and every backup is preserved. If you paste the log, I can explain in a bit more detail.

@savity Worked Perfekt Thanks

What is the output of ls -l /media/bernat/owncloud ?

drwx------ 20 www-data www-data 4096 Nov 8 09:18 owncloud

Thanks @girish I thought it was permissions.

@jagan said in Google Drive for Backup & as binded Local Storage:

Bind Google Drive or a folder as a drive

If you mount Google Drive via FUSE, then you can just set that path as the backup folder under Backups view. You don't need the 6.0 feature, that one is for mounting host paths into apps.

@carbonbee So, you are saying that there are backups in S3 that are not listed in the Cloudron dashboard? And those backups are not getting removed?

@girish I have reports that this just happened again.

@girish Sounds good, thanks.

@girish Cool, I sent them a link to this page, so hopefully they'll find the same enthusiasm I have for what Cloudron makes possible thanks to you guys!

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

Thanks, fixed.

@girish In my case I was trying to mirror the content of a remote DO object storage to a local Minio instance. I can't recall the exact error but I remember it had to do with the handling of filenames.

@mehdi Very much interested in this topic. I love my American friends, but the EU certainly isn't without capability to respond to the data-mining free-for-all antics of the last decade. I share occasional posts on Twitter on these subjects if anyone's interested.

Yeah, there’s an area for it and if you’re saying there’s a way through the CLI. Then there’s a way through the website since both the CLI and web interface exclusively use Cloudron’s REST API.

I can see the user value of this when templating app setups

@thibaud I replied to you on support@ but the issue is that there is some long file name. The current rsync+encryption backup has some file name length limitation - https://docs.cloudron.io/backups/#encryption . There is a feature request at https://forum.cloudron.io/topic/3057/consider-improvements-to-the-backup-experience-to-support-long-filenames-directory-names .

Run the following command in /home/yellowtent/appsdata to find the large filenames:

find . -type f -printf "%f\n" | awk '{ print length(), $0 | "sort -rn" }' | less

@girish Interesting, and not something I'd considered. That pigs option is similarly interesting, though seems to have gone silent since 2017. Curiously, it's a similar story with pbzip2 (the same idea for bzip2) as far as I can tell. Decent roundup of options for Ubuntu at https://askubuntu.com/questions/258202/multi-core-compression-tools in case you want to review. It will be interesting to see the GCP results for sure. I'll pull some metrics after the migration/restore as well as after the manual backup and see how it does across CPU/Disk/Network in the process.

glad to have helped

@girish
Oh, I had the URL copied in the paste buffer but got distracted. It's much simpler - https://odrive.com

I've updated the post with the link.