feat: add backups info on hosted instances

This commit is contained in:
Iain Learmonth 2025-11-12 12:04:51 +00:00
parent d4f38578bb
commit 414e1394ab

View file

@ -27,3 +27,30 @@ All CDR Link helpdesk data is stored on a
[LUKS-encrypted](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/encrypting-block-devices-using-luks_security-hardening) [LUKS-encrypted](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/encrypting-block-devices-using-luks_security-hardening)
volume with a per-instance key to protect the data at rest. volume with a per-instance key to protect the data at rest.
Hetzner staff have physical server access, but strict controls are in place to prevent unauthorised access. Hetzner staff have physical server access, but strict controls are in place to prevent unauthorised access.
## Is my data backed up?
SR2 manages daily backups of your data and retains the backups for 7 days after creation.
As your helpdesk will constantly be updating with new tickets and replies we have not ever had a reason to retain
backups for longer than this, and we always try to minimise the amount of sensitive data we keep in "hot" storage.
The backups take the form of a full disk snapshot so we are not able to restore individual tickets if they are
deleted accidentally, for example, we can only roll back the state of the whole helpdesk.
The backups are stored on a physical server hosted in Hetzner's datacenter separate from your helpdesk's primary
storage. As the backups are a snapshot of the disk, the data is encrypted there with the same per-instance key that is
used to encrypt the primary storage (it's a byte-for-byte copy of the same encrypted data).
## Can I get a copy of my data?
This is possible, however it is a manual process so we require adequate notice and may refuse if requests are too
frequent.
We would provision a small virtual machine with disk encryption and export a database dump to the virtual machine.
Optionally we can encrypt the database dump to a GPG key.
We would then ask for your SSH public key, preferably over a channel like Signal where we are able to confirm the
contact's authorisation, and then allow that SSH key access to download the backup.
Once you have confirmed that you have the backup we would delete the virtual machine, delete the encryption key,
and the underlying storage it was using would be encrypted with no possibility of decryption.