Posted: 2026-01-12
I have been in the VPS hosting industry for a fairly long time and have first hand experience with the potential, and reality, of VPS instances being able to see old customer data.
This is/was a huge deal, and it's something to absolutely be aware of. However, it's not a problem everywhere, and probably not at most hosts. And it should never happen at SlowServers, and I'll explain one reason why.
That was the title of a blog post I stumbled across, close to a year ago. I hadn't thought about these disk issues in quite a while. Naturally, I was interested as Incognet is a competitor in the space.
At the time, the blog post hadn't been fully updated or fleshed out to where it is now. So from what I saw, what was described looked plausible, even real.
But what happened is that the user deleted some stuff, then used photorec to discover files from his prior OS install. He thought he was seeing other customers' data.
It turns out that the post, as it sits now, is pretty misleading and jumps around a lot, making it feel like no mistakes were made by the author. Fortunately, Incognet has a blog post which shares some details and explains the actual ticket log back and forth.
At first, I was disappointed with Incognet, but then I saw the rebuttal and saw that they took it seriously. It seemed like the "digdeeper" author wrote in a very misleading, and perhaps at times untruthful manner. The digdeeper author ought to link to Incognet's rebuttal, in my opinion.
Thus, it seems like Incognet had no such security issue and the whole digdeeper post was either bad judgement or a PR smear.
Now, this can and did happen. It was a very, very big deal.
At a previous employer, working in a support role, it was discovered that customer VPS data could be leaked into newer VPSs.
The VPS disk layer was LVM. The logical volumes for VPSs were scrubbed between tenants. However, if I remember correctly, swap logical volumes and snapshots were not.
So swapped memory contents (and maybe not, it's been a long time!) and data written during a snapshot could be leaked.
Most servers were migrated to a different environment that used qcow2, as a file on disk. By using effectively a sparse file, eliminated the scrubbing step or necessity altogether. There was no raw disk allocation to worry about.
The rest were rsynced to partitions on cleaned or new hosts. The rsynced files were fine, just the disk underneath, in unallocated space, that might've held old customer data.
(For the curious, we eventually realized that a `dd` in place, in the filesystem, that was allowed to entirely fill the partition, would've probablyt done the job as well.)
Number one, I'm pretty particular about security and having spent about three months of my life dealing with the aftermath of this exact problem, I actively think to avoid the problem.
Number two is that VMM (OpenBSD's hypervisor, which is what SlowServers uses) only supports raw or qcow disk images on a filesystem -- no partitions. Thus, it's pretty hard to cross-contaminate in the same manner.
There's actually three ways you can allocate disk for VMM. With vmctl create, you can make a sparse raw file or qcow2. qcow2 is also raw, and support snapshotting. Snapshots can be a great feature, but VMM doesn't support live snapshotting. For most people making VMs on their local systems, either option is good. I'd probably lean slightly towards qcow2 in that instance.
However, the most performant/consistent option is to actually write out a file the size of the disk image. Something like dd bs=1G if=/dev/zero of=customervps.raw. Preferably, VPS images exist on their own dedicated partition. The drawback to this is that it's very slow, but you only do it once per VPS.
For one, this habit zeroes out customer data which still often ends up on host disk after the VPS has been deleted. The other is that there's much less fragmentation. If you slowly fill up a sparse or qcow disk image, if there's any writes on the host in between, the VPS disk image will become fragmented. Now it's quite possible to eventually end up with some fragmentation anyway, but it's much less severe. More likely to be two fragments in the entire virtual disk, rather than hundreds or thousands.
This matters less if you use SSDs, admittedly, but probably doesn't help either way. You might end up with a file, in the VPS' filesystem, that's fairly small (say a 1MB sqlite database) that spans two or three fragments. With a spinning disk, it'll have to jump around. To the VPS, the file may not be fragmented at all, but block 1000 and block 1001 (just to explain) are actually far apart. Some of your reads/writes will be fast, and some will have a seek or two between them which can be pretty significant under the right circumstances.
Any VPS provider that you choose should *know* that there's no chance of this happening. Back in 2012 when VPS hosting was somewhat new (less than 10 years old), it was a little more understandable, (and many large hosts were impacted) but still serious.
I appreciate Incognet and Kyun both addressing this. I hope that digdeeper will update his post and link to Incognet's rebuttal.