feat: add backups info on hosted instances
This commit is contained in:
parent
d4f38578bb
commit
414e1394ab
1 changed files with 27 additions and 0 deletions
|
|
@ -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)
|
||||
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.
|
||||
|
||||
## 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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue