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)
|
[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.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue