Cloudron Forum

@eddowding said in What's the fastest backup and restore method?:

I have 175GB and it takes about 12h 😞 I guess something is very wrong.

Yeah, my backup of about 350GB takes about 2 hours (from a Hetzner Dedicated Server in Finland Helsinki (HEL1) to a Heztner Storage Box in Falkenstein (FSN1))

IMHO your issue is very likely due to those "too good to be true" iDrive offer pricing they had which I guess you went for.

@3246 said in [💡 Guide] How to install Cloudron/Nextcloud with LUKS full disk encryption on Hetzner cloud server:

@Stardenver yes it is. I also have it running on baremetal at home/office.

My new set up has a main drive that's encrypted and another for local backups, which is also encrypted but unlocks after decrypting the main boot/data drive.

Happy to expand on this if folks find it useful 🙂

Thanks again for your setup guide. Just got a new server and its up and running. May I ask how you'd setup your system, so that additional drives are also encrypted and unlock after decrypting the main drive?

@girish to be honest RC4 is horrible but yeah... thanks 🙂

Edit: fixed. I found docker.service inside /etc/systemd/system/multi-user.target.wants/

I didn't get this to happen: "Then, systemctl start my-disk-mounter would automatically start docker and box." But that's ok. I run a manual startup script that prompts for the encryption password, mounts the disk, then starts all the systemd services. Instead of my-disk-mounter.service, I have check-that-all-disks-are-properly-mounted.service which is Required by box and docker. Thanks again.

For future reference i managed to clear it up by using a slightly modified version of Girish's search command. It seems like the length limit applies to path length not just the filename length

find . -type f -print|awk '{print length($0), $0}' | sort -n

Went into the web interface and deleted / renamed files longer than 156 bytes and finally cleared trashbin/versioned files

(wipes all deleted / old versions of files - careful):

sudo -u www-data php -f /app/code/occ versions:cleanup sudo -u www-data php -f /app/code/occ trashbin:cleanup

@robi @girish agreed it would be awesome if there was an automated way to handle this in the future

@girish Thanks! This ended up being a combination of issues I believe. So throttling on the backups due to using rsync, encryption, and file names ended up being too long (only a few) So I've changed some settings around and it seems to have been resolved. I appreciate the help from both @robi and yourself.

@robi @nebulon Thank you. I will try the recipe I found at Stack Exchange and then report back. In my situation it is for a home server. So I can easily connect a keyboard and monitor to enter the encryption password on the drive in the wake of a server reboot.

I do want to be able to do it remotely though if I'm not home. But the situation is not urgent for me. That explains my delay in following through. But I will.

Instead of spending more time to find a solution for my non responsive nc-instance, I did a restore of my last backup. To add my findings from the last hours, I cloned the backup first. Then I deactivated the encryption app within nc.
The stupid user feedback no longer appears.

For the record. My setting in nc19 was:

Default encryption module enabled Server-side encryption disabled

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

@lucidfox rsync + encryption has file path length limitations i.e if your app has a file which has long path (not just the file name, maybe it is some 10 folders deep) the backup will error. The limitations are documented here https://docs.cloudron.io/backups/#encryption .

@Robin opened a feature request here to improve this - https://forum.cloudron.io/topic/3057/consider-improvements-to-the-backup-experience-to-support-long-filenames-directory-names

@Jan-Macenka OK, I have made filename encryption optional in 7.3.

fbb205df-5917-403b-92c5-9084a856c656-image.png

@murgero Yeah, makes sense.