@3246 They should add a way to add 2 backup jobs setup however you like:

For Me:

Job 1 - Backup to Local external disk for fast access in case of emergency

Job 2 - Offsite backup for long-storage.

Both encrypted, and this offers a quick restore (in the event of just needing a quick restore) and one for proper emergencies

Not that you even need to set it up like this, but more backups == better backups even if one is local for emergency "non-natural-disaster" restore.

@JOduMonT said in How to install Cloudron/Nextcloud with LUKS full disk encryption on Hetzner cloud server:

Maybe I miss read, but, do we have the same understanding that LUKS and full-disk encryption is only useful when the system is not running; aka the drive is not mounted ?

Yep, this is covering only against scenarios where actors might gain access to the drive or volume your data resides on when the machine is offline.

Think of security as layers of an onion and this is just one layer for one(ish) attack vector.

As part of my information security policy, I need to protect data at rest (e.g. hard drives of servers, laptops, phones and backup media) and prevent unauthorised access when machines are running. So full disk encryption satisfies that requirement nicely and being able to do it from afar on a virtualised or bare-metal system like at Hetzner makes it pretty convenient too.

My concern with home/office is theft and with hosters or data centres in general, that drives may end up being replaced or recycled. Hetzer and hosters like them will have easy physical access, so LUKS protects against someone going to the machine, turning it off and passing the drive on to someone else for whatever reason.

Happy to expand and try to answer any questions, with the caveat that I am not offering professional advice nor does it come with any guarantees 😉

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

@girish it does, yes. They also have a KVM style one for their "elastic metal" service. I'll give this a try and report back. My main question is whether I can install the OS from an image or if I have to use one of theirs. Otherwise, I may have to find another host 🙂

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.