1
I have the following material with my laptop :
- 20GiB SSD
- 500GiB HDD (Disk A)
- External HDD (Disk B)
What I want :
- My Linux (Debian 9) encrypted at the partition level (that I manage), with classic separation (root-var-home-tmp-boot) on the SSD.
- A backup of it. I'm not so sure about how I want it, ideally with some versionning but with the encrypted partition that would mean synchronize at the file system level, and then encrypt the backup.
For now, the best solutions I saw was either implementing RAID 1 (mdadm --> LUKS --> LVM --> ext4) or using rsync or dd.
It feels like mdadm is the best way to achieve what I want because of the encryption, and that using dd on a live partition might cause issues. But that means that I have to use continuously Disk A with a 120GiB volume, and Disk B as an optional disk being my real backup.
So is there any better way to go? I feel like there should be, in the end what I'd really like is some dd-like of the full disk, that could be done in boot before decryption or at shutdown. That would even be better for restoration, because I want to protect most against system corruption.
Is using a solution like rsync or dd better for performance, even if that means re-encrypting? Would there be an easy way to restore from a clean backup if the whole system is corrupted?
Any suggestions are welcome.
Thanks!
Zumado
Posted 2018-04-03T17:12:35.303
Reputation: 13
Thanks, I'm setting up that solution right now. I'll see how much time it takes to make snapshots (once the first is done). About ssh, unless you mean I can control it remotely, or adding a layer of encryption, I wouldn't transfer the data over it - it doesn't provide the same security as the full encrypted disk. – Zumado – 2018-04-05T18:52:33.977
You are confusing 2 things here - ssh encrypts data in flight/on the wire - and prevents interception of it - and it's ubiquitous so easy to add. This is entirely different to encryption at rest - which is how data is stored on disk. As encryption always has some cost - which you have deamed worthwhile - if you are not backing up to a physically attached disk, you really want both - ssh overhead is trivial compared to the cost of disk IO. – davidgo – 2018-04-05T19:02:46.013
"prevents interception of it" : No, that's what I meant, it doesn't. Maybe I'm too paranoid, but from the moment when it is disclosed that someone can break it, I do not consider it secure. See https://en.wikipedia.org/wiki/Secure_Shell#US_government_hack_of_SSH_protocols_confirmed
– Zumado – 2018-04-05T20:57:32.510Huh? AFAIK, SSH is not known to be insecure (except for a specific implementation which was corrected many years ago). Please advise how it can be broken? – davidgo – 2018-04-05T20:59:52.327
Well I gave you a link. It's not broken per se, clients implementations are, and for years (CIA Gyrfalcon tool for OpenSSH on Linux). Anyway, it's just a general guideline I follow, unless I have to, I try not to communicate sensitive data over Internet (even encrypted). – Zumado – 2018-04-06T12:51:27.780
You do realise that Gyrfalcon requires the system already be uterly compromised - ie the person installing it already needs to have root? ( https://www.ssh.com/ssh/cia-bothanspy-gyrfalcon ) At that point they could just as easily replace the opens binary with a malicious one. Of-course, you also will have access to the private keys and mounted +ie unencrypted) data.
– davidgo – 2018-04-06T18:40:52.590