Hello,
I'm having the following setup(simplified):
- Proxmox host with several disks mounted as regular EXT4 data directories
- A few big(4tb) storage images(qcow2)
- A VM(let's say stock Ubuntu server) that mounts them
- The data volumes themselves contain luks-encrypted ext4 partitions where the actual data is.
- The VM autostarts, but to access the encrypted partitions I have to manually go in and unlock them.
My goal is that if someone steals the hardware, they can't access those partitions - the luks keys are not stored anywhere, so the data should be safe.
Now for the backup - I have a separate (offsite) machine running PBS and it's working excellent keeping backups of my proxmox VMs and a few other hosts.
I'm now thinking of an elegant way to backup the data storage on schedule IF/WHEN the vm is already running and I've manually unlocked the luks partitions.
What I'm wondering is how to do the encryption part so that in case any of the hardware is taken off, the data - both on the backup side and on the host is safe(inaccessible).
Approaches I've thought about:
1. I couldn't find anywhere in the documentation support for using asymmetric key - to encrypt the backup with the public key, but the private key for decrypting stays offline or at least is password protected so that the backup can be encrypted without password, but can't be decrypted without the private key or the password. If PBS offers that and I've missed it in the docs - that would be the best solution.
2. One hackjob way I thought of is having the backup encryption passphrase as a file on the encrypted partition itself - this way it could be read and the backup can proceed if the volume is unlocked, but not be exposed anymore after a shutdown/locking the partition. My concern here is the sole existence of the file with the password anywhere on the same system which makes it prone to leaking.
3. Having a separate device available only on the same network that contains a gpg-encrypted password, where the backup script gets the encrypted password and decrypts it in memory(where the priv. key could be stored on the encrypted storage) and passes it to the pbs client agent for backing up. This approach I like because it can also cover unlocking the luks partitions remotely, so I can use that third device to control the whole process.
4. Just do a regular proxmox backup, snapshotting the big data qcow2 images. My concerns here: 1) compression and deduplication will not work at all and 2) don't know if it's a good approach to just snapshot so large images, wrapped in a luks container inside. To me it starts to sound fragile.
5. Better ideas?
I'm having the following setup(simplified):
- Proxmox host with several disks mounted as regular EXT4 data directories
- A few big(4tb) storage images(qcow2)
- A VM(let's say stock Ubuntu server) that mounts them
- The data volumes themselves contain luks-encrypted ext4 partitions where the actual data is.
- The VM autostarts, but to access the encrypted partitions I have to manually go in and unlock them.
My goal is that if someone steals the hardware, they can't access those partitions - the luks keys are not stored anywhere, so the data should be safe.
Now for the backup - I have a separate (offsite) machine running PBS and it's working excellent keeping backups of my proxmox VMs and a few other hosts.
I'm now thinking of an elegant way to backup the data storage on schedule IF/WHEN the vm is already running and I've manually unlocked the luks partitions.
What I'm wondering is how to do the encryption part so that in case any of the hardware is taken off, the data - both on the backup side and on the host is safe(inaccessible).
Approaches I've thought about:
1. I couldn't find anywhere in the documentation support for using asymmetric key - to encrypt the backup with the public key, but the private key for decrypting stays offline or at least is password protected so that the backup can be encrypted without password, but can't be decrypted without the private key or the password. If PBS offers that and I've missed it in the docs - that would be the best solution.
2. One hackjob way I thought of is having the backup encryption passphrase as a file on the encrypted partition itself - this way it could be read and the backup can proceed if the volume is unlocked, but not be exposed anymore after a shutdown/locking the partition. My concern here is the sole existence of the file with the password anywhere on the same system which makes it prone to leaking.
3. Having a separate device available only on the same network that contains a gpg-encrypted password, where the backup script gets the encrypted password and decrypts it in memory(where the priv. key could be stored on the encrypted storage) and passes it to the pbs client agent for backing up. This approach I like because it can also cover unlocking the luks partitions remotely, so I can use that third device to control the whole process.
4. Just do a regular proxmox backup, snapshotting the big data qcow2 images. My concerns here: 1) compression and deduplication will not work at all and 2) don't know if it's a good approach to just snapshot so large images, wrapped in a luks container inside. To me it starts to sound fragile.
5. Better ideas?