>For dedicated servers this would work, especially for VPN where data-loss is "acceptable".
FWIW there's no need for data loss when you ditch the server, just download the encrypted data and decrypt using a clean environment elsewhere.
>But if it where based on containers like LXC or OpenVZ, then the host can force root access via a command without even changing the root password of the container.
You should never do this, unless you truly don't give a shit about whatever you have on the server.
I mean that encryption puts the entire data-store at risk, I've seen it happen more than twice due to RAM being faulty (In one incident it was using ECC RAM) and a power-failure.
Even the backups where corrupt due to being backed up in encrypted images. When encrypted volumes and images are corrupted by RAM or power-failure, they are locked forever.
Of course one should never force root access, I'm saying that you can't keep out the hosting from access the server in that case.
> Even the backups where corrupt due to being backed up in encrypted images. When encrypted volumes and images are corrupted by RAM or power-failure, they are locked forever.
That sounds more like issue with backup procedure (and testing of backups), even if it was amplified by encryption.
> Of course one should never force root access, I'm saying that you can't keep out the hosting from access the server in that case.
LXC and especially OpenVZ containers seems to be replaced by KVM in hosting/cloud. Of course, it's still possible to attack VM as host has control over VM's memory. Even dedicated servers are potentially vulnerable to attacks like cold boot.
> In one incident it was using ECC RAM
Did it at least warn about issues or was it ignored?
> I mean that encryption puts the entire data-store at risk, I've seen it happen more than twice due to RAM being faulty (In one incident it was using ECC RAM) and a power-failure.
How can this cause data loss? Header containing encryption key should not change during normal work. Did it just corrupt writes?
Yeah this sounds so weird. Data loss due to bad RAM will be extremely similar with or without encryption, it's not going to corrupt the header of the disk.
The catastrophic data loss you describe almost certainly resulted from you doing something horribly wrong, and not encryption.
FWIW there's no need for data loss when you ditch the server, just download the encrypted data and decrypt using a clean environment elsewhere.
>But if it where based on containers like LXC or OpenVZ, then the host can force root access via a command without even changing the root password of the container.
You should never do this, unless you truly don't give a shit about whatever you have on the server.