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.
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.
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.
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?
The catastrophic data loss you describe almost certainly resulted from you doing something horribly wrong, and not encryption.
Good reminder to set up FDE and not give your host logins for your servers. Unexpected reboots are rare enough that they're worth switching hosts over.