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

@kk_cloudron that is correct, Cloudron requires IPv4 and does not work on IPv6 only servers (yet).

Ah, thanks for reporting. I have opened https://git.cloudron.io/cloudron/box/-/issues/808 internally .

@girish
I tried this exact same setup. I was able to connect to the storage via SFTP and my SSH key and I copied my private SSH key as instructed to Cloudron.

When I now try to save the backup settings using SSHFS it keeps working and never finishes. The log says

Jan 14 11:40:33 box:shell addMount spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/addmount.sh [Unit]\nDescription=backup\n\nRequires=unbound.service\nAfter=unbound.service\nBefore=docker.service\n\n\n[Mount]\nWhat=uxxxxx@uxxxxx.your-storagebox.de:/\nWhere=/mnt/cloudronbackup\nOptions=allow_other,port=23,IdentityFile=/home/yellowtent/platformdata/sshfs/id_rsa_uxxxxx.your-storagebox.de,StrictHostKeyChecking=no,reconnect\nType=fuse.sshfs\n\n[Install]\nWantedBy=multi-user.target\n\n 10 Jan 14 11:40:44 box:shell addMount (stdout): Failed to mount Jan 14 11:40:44 box:shell addMount code: 3, signal: null Jan 14 11:42:04 box:shell removeMount spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/rmmount.sh /mnt/cloudronbackup

Not sure what else I can try.

Edit: magically and waiting one night it works now.

I would recommend you to use WebDAV instead of CIFS
it will be faster as WebDAV is more modern and appropriate for extended network (non LAN).

Ok, I solved it. I had to delete all my DNS settings that previously existed and then reset them. Once I did this within milliseconds Cloudron started working.

Whew, I was sweating bullets there for a minute.

@nebulon I find the solution taking infos from this forum .

In fact, I opened port 53 TCP and UDP and Cloudron can resolve domain names.

Configuration now is:

firewall template.png

All seems to working fine... I marked this thread as "Solved" 🙂

@nebulon Yes before rebooting I tried to umount-remount but it seems it has been impossible due to an error... So I decided to restart.

About auto-remounting it will be an amazing feature

This will be part of 7.2.1

@mehdi Not sure I know enough yet about handling updates, patches & security so just running in good faith on all that at the mo.

Happy? Yes.

Confident? Sure - until something goes wrong 🙂

Just always thinking about prevention being better than cure.

Ok I gotcha myself because anyway I create my own pain 😉

so from what I understand
to being able to restore Cloudron verify the DNS first than app/data

I forgot to authorize my new IP in my Cloudflare API

code 9109 is probably related to the fact it was unable to edit the DNS.

correct in your case this should not be any issue as this is mounted like a regular ext4 which supports hardlinks just fine.

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.